The underlying issue with web applications is that it’s like a square peg going in a round hole. Remember, HTTP is designed traditionally as a stateless protocol delivering static web pages, more or less.

But here we are, with stacks-on-stacks-on-stacks of layers emulating what truly should be a native application. “Web Application” should not be a thing. HTML/CSS were supposed to be for content and presentation; JavaScript was for sprinkles of functionality.

So no matter how you spin it—each framework is a workaround making the browser do something it wasn’t designed for.

When I say that I don’t mean “abandon all APIs”—I’m just stating why things are so complicated in the web space.

Moral of the story—give us more static content please. “Dynamic” means ads and wasted CPU cycles.

Things change. Just because it was originally made for documents doesn’t mean that it hasn’t undergone such huge changes that it can literally drive FPS games at 60fps without a sweat. And I say that as someone who really doesn’t like many of the underlying abstractions, imo CSS+HTML are just thoroughly badly designed, none of them would be whole without the other resulting in extreme close coupling (layouting for example cannot be done without the other).

Also, should I really download a random exe to order a pizza? Plus, especially because the protocol is stateless a web app makes so much more sense (then replicating the state at the backend side).

Ordering a pizza can be done with static pages and some forms.

You want to make photoshop or a CAD program? That is an app. You want to order a pizza? Just use html and forms, maybe javascript to reload the progress page once per minute. (You don't need websockets or SSE or anything to check pizza progress)

The browser is a sandbox. It requires no install or approval from IT to install a web page. You don't have to go through and app store.

It has huge value as a delivery platform.

Gah, it's too late for an edit. That should read "an app store".

Sorry.

> maybe javascript to reload the progress page once per minute

Not even that, as there is meta refresh :)

> Also, should I really download a random exe to order a pizza?

That's where mobile seems to be heading, McDonalds would like you to download their app to order a burger

Not everyone is a fan of throwing away secure sandboxed environment easily accessible apps run on to native applications that might not even be built for your OS.

None of what you have outlined is actually a problem.

If your requirement is to deliver an application to users on multiple platforms then a web application is a great target.

People complain about HTML, mean while new platforms (Swift, MAUI, Flutter) still design tree like documents. It's insanely fast, optimised, accessible and the tools are fantastic.

Frameworks don't change browser behaviour, they allow you to go up a layer of abstraction. Static content is great for static content. It would be a terrible fit for a rich text editor, a dynamic chart or anything that requires interactivity.

The ecosystem is great. Native applications can get you a more optimised experience at a cost. That cost is not worth it for many solutions.

Ads are on native compiled apps too, it has nothing to do with HTTP/HTML.

I’ve always been in favor of an entirely different file type, specifically for applications. Imagine if we’d just had something like .aml (application markup language). Then html could have stayed as a document format and we could have avoided all this nonsense.

What even is a good DSL for applications?

I liked that react/jsx was born out of the web, and then influenced swiftui, jetpack compose, and flutter for a new way of writing application markup. I wonder: if not for the web and its pain points, would we have landed on similar patterns? Maybe.

Yes! This is the core problem due to the historical trajectory (browser invented for static documents, now being used to build applications) -- one that's no longer possible to sidestep at this point.

I believe there is a phrase "path dependence" to describe such situations.

It's like ORMs and game engines.

Many times when people try to forgo them, they end up making their own poorly specified and half-baked version of it that only some people (who may leave the company) understand.

I don’t think ORM is the same since it’s more of an API than a framework (in my mind). ORM also falls into the platform-abstraction arena because it typically has multiple backends which provides other benefits. It also is served as a wrapper library converting from one language to another (SQL).

Web frameworks are more like… clever hacks to HTML to wedge in a “new way to do it” more clever than the last attempt.

Game engines are also somewhat different because the level of abstracted complexity there is vast and heavily domain-specific. It targets multiple platforms like ORMS and multiple GPU backends as well. It provides physics APIs and other heavy maths capabilities too.

But the browser standards-bodies provide that for us now. HTML5/CSS3/JavaScript will run well across all modern browsers.

I've only used laraval and knexjs over the last 10 years and have no idea which ORMs people are complaining about because the ones I used do not have the issues they talk about.

I agree. They are in general easily net-positive for most traditional applications.

I agree. I like pure JS, but it just does not scale by default. You need to have awesome architecture skills and you need to constantly observe your codebase, you need to write half of framework if you want to avoid frameworks. Of course it's possible, but it's not possible for vast majority of developers, including myself.

May be we need some education: how to write 100 kLoC pureJS WebApp and keep sanity. I didn't see that kind of articles. I know that my pureJS web apps can survive few hundreds LoC. Then it becomes a mess. With React it's much easier to structure an app so it's maintainable, different parts are separated, etc.

Yeah the frameworks do force a disciplined approach. It still boils down to separation of concerns like presentation from business logic etc. Historically the front-end computation existed on the backend but with NodeJS everything sort of mushed together (creating more complexity and possible architecture mistakes). Template libraries are great way to Split View from Model—but even that is taken care of in languages now like Golang templates and JavaScript template literals etc.

I suppose the question is: how much time does it take to master stock HTML5/CSS/JavaScript versus mastering a framework, through-and-through.

Frameworks are constantly in flux but the foundation they are built upon is a more lasting skill set. But the more we spend learning framework X we are spending time away from foundations.

Did you have a look at Elm? Even more easy to structure maintainable apps.

> Menus are constantly broken, back button is a game of roulette, caching is constantly a problem showing stale data, xss and other vulnerabilities are ubiquitous.

So… what’s the difference between this and SPAs using frameworks again? Because it sure seems to me I see many of these in sites that are apparently using frameworks. Hell, Facebook — presumably the poster child for the react ecosystem and certainly with the resources to do everything right — is still introducing nav-state related bugs.

Frameworks might focus people’s attention on what needs to be done, but the fundamental capabilities aren’t in the framework, they’re in the browser and the heads of the devs.

And of course, the other possible point the parent is making is not that people should be doing SPAs from scratch (which probably wouldn’t be wise in many cases) but that it’s not wise to start from the assumption that you should be making an SPA.

I agree with the sentiment of your post, but:

> Hell, Facebook — presumably the poster child for the react ecosystem and certainly with the resources to do everything right — is still introducing nav-state related bugs.

This doesn't necessarily disprove the framework's value proposition. Bugs like this are hard to squash and at great scale (like Facebook) they're a huge challenge. Frameworks propose trade-offs to manage them, but can't eliminate all classes of bugs. We don't know how much worse it'd be without the framework approach.

If browsers could agree on a themable UI component framework - it would solve so many things for so many people. The jazzy designers can still have their complicated CSS/JS animations and cool layouts. But having a standard solution for normal developers would be so good.

As someone trying to create a frontend with plain HTML/CSS for quite a complex backend, I can attest to the fact that's impossible to maintain consistency between browsers.

It's not even about how each block's styling behaves, but how different combinations of tags, blocks and widgets are able to exhibit very specific issues in each one of the 3 main rendering engines around. In very different ways, that require incompatible solutions.

It's quite egregious.

I'm primarily a backend but I've dabbled in frontend at times where needed, and I've always kinda felt there's value in polyfills if nothing else. Maybe you don't go full Angular/React but JQuery adds a lot of value for not much effort.

I realize JQuery is terribly unfashionable these days and maybe people would rather use some smaller niche polyfill library, but with how quickly the javascript world churns and deprecates, that is kind of a virtue tbh. JQuery is 16 years old and that's ancient in the javascript world, the Lindy effect says it will likely continue to be a pillar going forward as well. You're probably just better off using the standard even if you're not using all its capabilities.

https://en.wikipedia.org/wiki/Lindy_effect

The problem was choosing an SPA

Precisely. There was someone here bemoaning how difficult it was to follow generic advice of using profilers to optimise hotspots in the application code.

He started off with something like: "Why don't you try your 'simple' techniques in a tangled web of hundreds of microservices written in different languages and running on different platforms?"

It's like some people can't see the forest for the trees.

In the last few years, I've come across about half a dozen existing web sites with hideous performance problems, all of which should have been vanilla HTML but were written as Angular monstrosities. The same teams -- against repeated advice -- have started new Angular projects for sites showing static data, anonymously, to the general public.

They start off conversations with "We'll need a web app, an API app, a mid-tier, a service bus, and then this, and then that..."

It's madness.

Choosing a framework for that is bad enough, but you could make the case depending on how complex the rendering is. Still…to go with Angular sounds like the literal worst choice. Like at least React is just a UI library and can just be used server side.

That group there…really liked to waste time.

I was looking for this response because I was going to post it if I didn't find it.

So many people don't get that their design decisions have consequences and using a SPA is absolutely a design decision.

Everyone's a "pure html/css/js" gangster until they have to maintain state.

Put your state in your urls, or in the user's session model, that's the only place state should be allowed to live :p

Unrelated to the debate at hand, my front-end team's junior members' only known design pattern is drop-all-state-on-refresh-driven-design and it pisses me off.

Basically every part of the website written before their time functions correctly.

I thought it's the other way 'round. Everyone loves their cool new reactive framework, until they have to tackle the state library/library helpers/library alternative/other library alternative/library helper maintainer social media posts.

That sounds like a training problem more than anything else.