The "JavaScript-based web app" starter pack.
Build web sites, not web "apps".
JavaScript is an enhancement, not a replacement for HTML.

@devRancid Read my post again.

JavaScript is an enhancement, not a replacement.

This means the initial page load is via HTML, but enhancements such as posting comments without reloading the page are done via JavaScript.

Only js vs enhancements vs static html isn't gonna get rid of network/loading issues so what's the point of the image

@exerceo every place I’ve worked we use JS frameworks. I can’t say I really have much control over the "initial loading" phase.

This is the type of stuff you should be addressing to JS framework developers, not run of the mill devs on devRant

@black-kite A lightweight static version could be displayed instead of an error message if the JS framework fails.

The JS framework just needs to hide itself if it detects it failed.

where do I sign?

It depends on the level of interactivity the page requires. There are some legitimate web apps. Though the tech is overused. YouTube is a great example. The only reason YT needs to be a web app is because their premium version supports offline video. Which is neat, but is it worth making the whole thing a slow, glitchy experience on desktop browsers? I don’t think so.

@kiki In the comments :-)

@devRancid With progressive enhancement (HTML first, then JavaScript), the useful content loads first.

With a JavaScript app, the useful content loads last. Only after all those megabyte-sized JavaScript files.

🍿

what OP says is unequivocally right in any scenario I can imagine. Always start with HTML. Even if I'm making a camera app, I would still start with HTML. HTML and CSS are my mockup tools. It's only when every screen is ready and looks production level that I can start making it dynamic with JS. This is even true for apps that work offline. I see no case in the browser where this approach wouldn't work, but “let's do everything in JS” would

Javascript is more than a programming language. Javascript is a mindset. Not everybody gets it. Once you understood the superiority of Javascript, then your whole life become Javascript. Your friends become Javascript. I talk javascript with my parents. I talk Javascript with the policeman in the street. I talk Javascript to my banker. I breathe JAVASCRIPT.

@kiki client side routing. If your application maintains a state across “pages” - including running processes such as timers etc, you’ll want to remove the browser navigation and do client side routing instead, so the document itself never actually reloads. This will actually improve the performance and responsiveness of the application compared to one which contacts the server to render a page, then loads the JavaScript, which de-serializes the state, restarts running processes, and runs any task that should have executed in the interim (load time)

It’s a niche application. But I’ve run into it. It’s not always evil. Just usually.

@AlgoRythm I usually just swap HTML blocks around…

@kiki another thing SPAs do well is after a slower initial page load, client side cache kicks in and navigation around the site after that can be virtually instant. How frameworks like Angular fuck this up so badly and make my experience seem laggy as hell is beyond me.

nah, let the man cook, op is not wrong.

Progressive enhancement makes sense in that regard. You use JavaScript for the things that make sense to use it, not just dump an entire stack of it for no other reason than to be trendy.

Consider this, each tab runs essentially on its own instance of everything, including the JS interpreter, if you have a massive Javascript based app on each tab you will end up with using 5gbs of ram just on a fkn browser. Sandboxing is great, and it makes sense all the way from dev to a security point of view, but geeeeeeezus man, that is a full ass JS interpreter working on each tab for massive shit that didn't need to be massive to begin with.

Oh, and this is coming from someone that loves JS

@AlgoRythm I can do all of that without trying to replace html with js

I honestly don’t see what you’re fussing about here.
You say with progressive enhancement, the useful content gets loaded first. If your useful content depends on the network, what are you to show if the network fails?
Oh great, a super fast html page telling me the content isn’t available!

Jquery is cancer and htmx is brainfuck for any non trivial use. Htmx also use js to swap html.

Once I get used to reactive frameworks I will never go back. All updates can be tracked by dependency graph. No more imperative bs.

Angular is abomination. Angular sites load ton of trash without providing any dx benefits. The shit can't even do hydration lol

@h3rp1d3v jQuery is not cancer and htmx is perfectly fine in complex situations. However there are perfectly documented cases where pure htmx is not useful.
The same goes for all the render by js stuff. There are actually situations where it makes sense to do so. Even though I find react horribly backwards and inefficient.

It's a tradeoff gene not a one size fits all.