3 ms·

That’s a great write up. I’ve been using SolidJS and hadn’t taken the time to soak in the compiler information, so this was a great time saver. Although it’s n

That’s a great write up. I’ve been using SolidJS and hadn’t taken the time to soak in the compiler information, so this was a great time saver. Although it’s nice not to worry as much about these optimizations (and I’m certainly not trying to put down the work that went into this compiler), something rubs me the wrong way about so much code generation sitting between the code I wrote and the state management I intended it to do. I guess it’s because react has bitten me so much in this department in the past. I’m sure it’s smarter than I am, I doubt it’s wrong as often as I am, but it feels like it could potentially obfuscate issues or cause slight quirks that would be really, really difficult to debug. Of course it’s just an initial reaction rather than a rational concern based on an intimate understanding of the compiler. Having said that, what the compiler does is different from what I expected but much simpler too. It’s easy enough to follow what it’s doing. I’d like to see performance comparisons between apps with good state management practices without the compiler vs the same apps with no special state management and using the compiler. Is it worth this added complexity if you’re already familiar with React’s foot guns?

pzo 2y ago
I worry about this too but I guess it all depends on tooling/debugger - in native land this days you trust compiler and debugger and even code is in ASM everything just works so in react land this still should be possible to deliver similar experience. Similar trends is in other declarative frameworks even on native such as SwiftUI - its easy to write complex gui but harder to debug and easier to shoot yourself in the foot. Its just harder to reason how declerative code will be executed in all corner cases and you have to trust compiler will do its magic. Overall for me it seems a lot of SwiftUI app feels much slower and even Apple developer from time to time shoot themself in the foot. We are just trading developer experience with performance and debugging.
bastawhiz 2y ago
Maybe I'm more risk tolerant, but I'm not so concerned about the compiler doing things that I didn't tell it to do. GCC and LLVM heavily rewrite code and it's generally rare to experience compiler bugs. Uglify/Terser very heavily rewrites JS, but you can still step through it with the help of source maps—sometimes without even noticing it's been compiled. Babel and others rewrite async functions into code that looks almost nothing like the original code (but runs in older browsers) and introduces a whole runtime library for executing them, but we don't even think about that.

pzo 2y ago

I worry about this too but I guess it all depends on tooling/debugger - in native land this days you trust compiler and debugger and even code is in ASM everything just works so in react land this still should be possible to deliver similar experience. Similar trends is in other declarative frameworks even on native such as SwiftUI - its easy to write complex gui but harder to debug and easier to shoot yourself in the foot. Its just harder to reason how declerative code will be executed in all corner cases and you have to trust compiler will do its magic. Overall for me it seems a lot of SwiftUI app feels much slower and even Apple developer from time to time shoot themself in the foot. We are just trading developer experience with performance and debugging.

bastawhiz 2y ago

Maybe I'm more risk tolerant, but I'm not so concerned about the compiler doing things that I didn't tell it to do. GCC and LLVM heavily rewrite code and it's generally rare to experience compiler bugs. Uglify/Terser very heavily rewrites JS, but you can still step through it with the help of source maps—sometimes without even noticing it's been compiled. Babel and others rewrite async functions into code that looks almost nothing like the original code (but runs in older browsers) and introduces a whole runtime library for executing them, but we don't even think about that.