I think the HTML, CSS and even JavaScript are the most stable and future-proof components of your stack. Your Rails backend, on the other hand, will experience far more changes and API instability in the long run.
JavaScript was considered as a unstable and under-specified part of the Web in the "Dynamic HTML" era somewhere between 1997-2006, when Microsoft Internet Explorer implementation of DOM diverged from more standard Netscape/Firefox in many tricky ways. This has largely been solved by better standards, initiatives like Acid tests and (unfortunately) slowly spiraling into Blink engine monoculture.
Totally, agree. And new HTML elements (like <dialog>) and CSS features (like MPA cross-document view transitions) have made client-side JavaScript unnecessary for a loot more use-cases in recent years. This is something a lot of devs unfortunately haven't caught up on, especially if they were stuck in their framework's tiny world.
This inspired me to explore what the simplest possible framework/site generator could be, that still has great DX: https://mastrojs.github.io/
Thanks for sharing. However, this page needs code examples front and center. I read the whole page and still have no idea of the ergonomics of the framework.
Some users, like journalists and the visually impaired, disable JavaScript. If you can make a product that works for them, why not do it?
Some web clients, like TTY-based clients, ignore both JavaScript AND CSS. People using these clients rightly expect to get a worse web experience overall. But if you can make a functional web page for them, why wouldn’t you?
These both sound like relatively niche edge cases. But nobody knows how things will change in the future.
Left out of the post, but the stack is rails, turbo, and stimulus. Hosted on a 2016 MacBook Pro with a dead battery in my closet
I think the HTML, CSS and even JavaScript are the most stable and future-proof components of your stack. Your Rails backend, on the other hand, will experience far more changes and API instability in the long run.
JavaScript was considered as a unstable and under-specified part of the Web in the "Dynamic HTML" era somewhere between 1997-2006, when Microsoft Internet Explorer implementation of DOM diverged from more standard Netscape/Firefox in many tricky ways. This has largely been solved by better standards, initiatives like Acid tests and (unfortunately) slowly spiraling into Blink engine monoculture.
Totally, agree. And new HTML elements (like <dialog>) and CSS features (like MPA cross-document view transitions) have made client-side JavaScript unnecessary for a loot more use-cases in recent years. This is something a lot of devs unfortunately haven't caught up on, especially if they were stuck in their framework's tiny world.
This inspired me to explore what the simplest possible framework/site generator could be, that still has great DX: https://mastrojs.github.io/
Thanks for sharing. However, this page needs code examples front and center. I read the whole page and still have no idea of the ergonomics of the framework.
Agreed, I don't want to have to dig through documentation to get the gist of your framework/library.
Pretty dope stuff. My first thought with a finance tracker would have been “Dashboard? Interactivity? That’s a SPA.” Very pleased with your results.
I still do not see a future without javascript. If you are not using any external libraries, why not use it?
> Why not use it?
You shouldn't try and find ways to add unnecessary javascript to your page.
Some users, like journalists and the visually impaired, disable JavaScript. If you can make a product that works for them, why not do it?
Some web clients, like TTY-based clients, ignore both JavaScript AND CSS. People using these clients rightly expect to get a worse web experience overall. But if you can make a functional web page for them, why wouldn’t you?
These both sound like relatively niche edge cases. But nobody knows how things will change in the future.
Just use it when it is needed. Try don't use it when it is unnecessary.