I mean, if you're not ready to dive deep into Rust, TypeScript is an acceptable compromise for now. JavaScript is a pretty awful experience once you've been developing in Rust long enough, though. Frameworks like Percy, Iced, and Yew are amazing.
Iced lets you write GUI without needing HTML, CSS, and JS. It uses low-level GPU draw calls to WebGPU, Vulkan, and Metal graphics APIs. You can have desktop, web, and mobile builds all from the same codebase. The binaries are highly optimized and 10-100x smaller than Electron.
Percy should be familiar to React and Next.js users. The HTML macros are great, and it can run your application on the server, giving you the best of both worlds. Serverside rendering is one thing, but you can also hydrate and introduce state from your database using context from the request itself, just like the good old days.
WebAssembly is happening right now, and JS and compiled-to-JS languages will never be able to compete due to their reliance on JIT and GC alone.
There becomes a point where it's not realistic to expect your users to have a machine of limitless power to compensate for the deficiencies of your own technical decisions.
The industry is already adopting TypeScript for most new projects. It won't be long until we abandon JS completely.
Looks neat, but I have concerns. One is, it's not usually necessary to need to install additional Node dependencies for WASM projects. Percy and Iced don't need this. I also don't see an isomorphic (frontend and backend rendering) example. Percy has this. Also, does it support Browser History API routing? I just saw the hashes in the routing file for the todomvc example.
Which dependencies are you talking about?
Just like github.com/ryansolid/solid, there is no support for SSR "yet".
My unpopular opinion for this article is that SSR is overrated.
You can use any router you want, the example uses hashes so that you can try it out with any static file server.
One thing that project desperately needs is better public relations/documentation, such as examples that serve out of the box with one command.
In hopes of which I am raising awareness :v
I recommend checking out Percy and Iced, also. SSR is important because it allows you to be more flexible with your infrastructure. It also helps you support more dynamic values in OG tags, and I'm not sure if Google and others support SSR with WASM apps. Additionally, starting with SSR in mind is just nice because SPAs shouldn't be the prescriptive solution to every problem.
OG is an interesting usecase. I currently spend more of my time thinking about deep web.
Injecting OG tags + standard payload as an alternative to SSR would be fun.
My mind immediately jumps to also injecting an "initial data" bundle at the end of the payload though, and I have to remind myself that that's overengineering.
SSR is a nice-to-have when it's completely free. But it's never free, is it? Even if you are forced to run servers for some other reason, it's all the development effort to keep your data sources isomorphic.
I am not (yet) in the camp of "oh my god, why are you sending that poor person with the metered connection all that markup that they could render themselves", just the "SSR is hard, and there are other, more 'organic' optimizations that you could spend your time on".
The project is early on, but there's actually been efforts to make it Native. Also, Expo (Fancy React Native) is a terrible compromise, similar to those made by Electron, but exacerbated by the limitations of mobile hardware.
I mean, if you're not ready to dive deep into Rust, TypeScript is an acceptable compromise for now. JavaScript is a pretty awful experience once you've been developing in Rust long enough, though. Frameworks like Percy, Iced, and Yew are amazing.
Iced lets you write GUI without needing HTML, CSS, and JS. It uses low-level GPU draw calls to WebGPU, Vulkan, and Metal graphics APIs. You can have desktop, web, and mobile builds all from the same codebase. The binaries are highly optimized and 10-100x smaller than Electron.
Percy should be familiar to React and Next.js users. The HTML macros are great, and it can run your application on the server, giving you the best of both worlds. Serverside rendering is one thing, but you can also hydrate and introduce state from your database using context from the request itself, just like the good old days.
WebAssembly is happening right now, and JS and compiled-to-JS languages will never be able to compete due to their reliance on JIT and GC alone.
There becomes a point where it's not realistic to expect your users to have a machine of limitless power to compensate for the deficiencies of your own technical decisions.
The industry is already adopting TypeScript for most new projects. It won't be long until we abandon JS completely.
github.com/Pauan/rust-dominator/ tho.
Looks neat, but I have concerns. One is, it's not usually necessary to need to install additional Node dependencies for WASM projects. Percy and Iced don't need this. I also don't see an isomorphic (frontend and backend rendering) example. Percy has this. Also, does it support Browser History API routing? I just saw the hashes in the routing file for the todomvc example.
Which dependencies are you talking about?
Just like github.com/ryansolid/solid, there is no support for SSR "yet".
My unpopular opinion for this article is that SSR is overrated.
You can use any router you want, the example uses hashes so that you can try it out with any static file server.
One thing that project desperately needs is better public relations/documentation, such as examples that serve out of the box with one command.
In hopes of which I am raising awareness :v
I recommend checking out Percy and Iced, also. SSR is important because it allows you to be more flexible with your infrastructure. It also helps you support more dynamic values in OG tags, and I'm not sure if Google and others support SSR with WASM apps. Additionally, starting with SSR in mind is just nice because SPAs shouldn't be the prescriptive solution to every problem.
OG is an interesting usecase. I currently spend more of my time thinking about deep web.
Injecting OG tags + standard payload as an alternative to SSR would be fun.
My mind immediately jumps to also injecting an "initial data" bundle at the end of the payload though, and I have to remind myself that that's overengineering.
SSR is a nice-to-have when it's completely free. But it's never free, is it? Even if you are forced to run servers for some other reason, it's all the development effort to keep your data sources isomorphic.
I am not (yet) in the camp of "oh my god, why are you sending that poor person with the metered connection all that markup that they could render themselves", just the "SSR is hard, and there are other, more 'organic' optimizations that you could spend your time on".
This is clearly the darkest timeline.
When will the time come?
I personally don't really care about JavaScript, although I do care about WORA for both desktop, tablet and mobile; and no-installation needed.
The future is now:
github.com/hecrj/iced
It seems to use WASM for mobile.
I am also looking for web browser alternatives, like Expo, actually. But Expo seems not to target desktop apps.
Cordova can integrates with Electron and also mobile, but it seems to reset every time mobile app is updated.
The project is early on, but there's actually been efforts to make it Native. Also, Expo (Fancy React Native) is a terrible compromise, similar to those made by Electron, but exacerbated by the limitations of mobile hardware.
Check it out:
github.com/iced-rs/ios-examples
Notice the build target:
github.com/iced-rs/ios-examples/bl...