This is totally true. We've recently started to discover this paradox ourselves: when styling and layout is all done via CSS, and JS + other assets are cached, HTML is just as light weight as JSON over the wire. As ashamed as I am to admit it, our newest innovation appears to be "multi-page apps"!
A JavaScript-Free Front End
21–30 of 215 posts
Re: A JavaScript-Free Front End
#22100 percent agree. Use as little JS as possible on front end. And then definitely use zero JS on backend.
Definitely...only use C on the backend, any other language is just a hack.
Re: A JavaScript-Free Front End
#23wow this is excellent, / are good tricks
Except for the "works everywhere" suggestion... https://caniuse.com/#feat=details And here I thought Edge was a modern browser.
Re: A JavaScript-Free Front End
#24wow this is excellent, / are good tricks
Except for the "works everywhere" suggestion... https://caniuse.com/#feat=details And here I thought Edge was a modern browser.
If anything, this is the works everywheriest of things that "work everywhere" in post-2010 web development. Some other stuff actually breaks accessibility by default.
Re: A JavaScript-Free Front End
#25The key is to represent your data and UI state via sane HTML. This article demonstrates this well with the modal popup example. Once you represent popup's state with a checkbox, you can manipulate that checkbox in any way you want and you can style it in any way you want and your styling will not have any dependencies on the methods of manipulation.
Re: A JavaScript-Free Front End
#26Re: A JavaScript-Free Front End
#27100 percent agree. Use as little JS as possible on front end. And then definitely use zero JS on backend.
Definitely...only use C on the backend, any other language is just a hack.
Re: A JavaScript-Free Front End
#28I don't mind projects which use a tiny bit of hand-coded, vanilla ES6. Would be nice if there were a slogan that included these.
Looks like it actually does use JavaScript for the "select2" case. This is exactly the case I'd be happy to special case.
edit: added paragraph
Re: A JavaScript-Free Front End
#29Since I'm caching and gzipping everything, each subsequent pageview is around 6 KB; far smaller than the SPAs I've seen with equivalent functionality. That's ace. But my internet connection has a 2 second latency so I still have to wait an annoyingly long time every time I interact with your app. My connection is terrible too, so it drops every 10th request, and now I'm seeing a lot of broken pages. If only you'd wri…
> it drops every 10th request
If the app saves data to a server, that's gonna happen regardless anyways (and one could argue that techniques like optimistic updates might make the experience even worse)
Also remember that HTML can be streamed and partially rendered even if it's not fully downloaded, and the investment required to enable this is minimal. The same cannot be said about a SPA's data fetching/rendering strategies.
Having worked on bloated apps before, I despise when people throw around the word "prefetching" as if it's some sort of magic spell. At best it eats my battery and bandwidth needlessly, and at worst, it's weasel wording for slowing down time-to-first-pixel :(
Re: A JavaScript-Free Front End
#30Earlier quoted context omitted.
Except for the "works everywhere" suggestion... https://caniuse.com/#feat=details And here I thought Edge was a modern browser.
It's a basic DOM element — a block of content. Without native support, it's simply shown by default, instead of hidden by default, so nothing is broken, and even the default on non-supporting browsers can be changed with JS and CSS. If anything, this is the works everywheriest of things that "work everywhere" in post-2010 web development. Some other stuff actually breaks accessibility by default.