Our great sponsors
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
Woah I had never connected the dots - I had used https://github.com/evanw/glfx.js for a realtime photo editor and then wrote https://github.com/inssein/jsfx to render the same without WebGL for printing.
Woah I had never connected the dots - I had used https://github.com/evanw/glfx.js for a realtime photo editor and then wrote https://github.com/inssein/jsfx to render the same without WebGL for printing.
Thank you for your comment!
WASM gave Figma a lot of speed by default for a lot of perf-sensitive code like rendering, layouts, applying styles and materializing component instances, our GUI code is mostly React and CSS.
WASM engine performance has not been a problem for us, instead we are constantly looking forward improvements in the devex department: debugging, profiling and modularization.
One of the largest challenges of the platform we face today is the heap size limit. While Chrome supports up to 4GB today, that's not yet the case for all browsers. And even with that, we are still discovering bugs in the toolchain (see this recent issue filed by one of our engineers) https://github.com/emscripten-core/emscripten/issues/20137
The challenge of the perf-testing at scale in our company is helping developers to detect perf regressions when they don't expect them - accidental algorithmic errors, misused caches, over-rendering React components, dangerously inefficient CSS directives, etc.
I want to write only: https://penpot.app/
https://blog.jetbrains.com/kotlin/2023/08/compose-multiplatf...
They don't really mention Wasm there as this mostly focuses on the IOS support. They had a lot of presentations about that at kotlin conf and the compose web channel in the kotlin slack is very active.
Basically, anyone currently doing mobile development that is used to modern UI frameworks for that, will soon be able to target browsers effortlessly without compromising on their UI frameworks. Compose is one of the frameworks. But there are others. I've seen some nice kotlin-js frameworks targeting canvas and vector graphics. Doodle is a nice example: https://nacular.github.io/doodle/. I have not used that yet but it looks quite slick. A lot of kotlin-js stuff will transition to wasm once the compiler stabilizes.
Web developers seem to be mostly unable to see beyond their comfort zone of DOM/CSS/JS. There are alternative ways of doing UI/UX that are common outside of browsers. Applying that in a browser is transitioning from impossible (a few years ago) to being hard but very feasible (the last few years) to being easy, very common, and widely supported across different developer ecosystems (the next few years). Not a matter of if but when.