Hacker News new | ask | show | jobs
by ericwooley 1391 days ago
The entire concept of fronted frameworks is an anti pattern?

This might be the oldest, grumpiest man on the front lawn yelling at childreniest take we on web dev, that I’ve ever heard

2 comments

You have to at least admit that there's an awful lot of stuff done these days to render what used to be done with html.
It's not what used to be done with HTML. It's what used to be done with desktop GUI toolkits.

Web apps were never this complex before the creation of frontend web frameworks.

Webpages were designed to avoid complex state management. URLs, HTML and forms, i.e the original REST, is a model with a lot of power and flexibility, and almost none of the complexity of desktop UI toolkits.

Frontend web frameworks have their use in rich apps, but using them for general web pages is just complicating things for no good reason.

Yes, that's the point I'm trying to make. At the end of the incredibly complex and long modern road, you end up looking at text, images, etc, in a browser.
At the end of an incredibly complex and long modern road, I end up looking at text and images in any application, but I wouldn't wish upon the developers of, say, IntelliJ that they render the user interface by making their own JNI calls directly to "draw a rectangle" APIs...
I agree that would be ridiculous, but I'm talking about people using some huge front end library, react, k8s, etc, to make a form. With a logo. Obviously do whatever you want, but it's a lot.
A form with a logo... that looks consistent across most browsers, scales automatically between mobile and desktop user-agents, and already has all its sticky a11y metadata sorted properly, if they've picked a good framework. The gap between modern expectations and the bare-bones AJAX page is pretty wide these days.

It would definitely be better if there were a way to side-load those libraries as a standardized strata underneath the main browser content to save resources. So if someone uses React to do their form, yes it seems costly but the cost only needs to be paid once, and then the relevant framework is cached more statically than the transient web cache (and with an alternative to domain-based cache, such as checksums or signed binaries, to determine if two domains are using the same framework and save the download cost for all sites you visit using that framework).

... but only better if the tricky engineering questions around caching were sorted. There's plenty of risk that you'd end up with gigabytes of cached frameworks, because the current solution means I don't have to care if one site is using React 12 and another is using React 12.1.

Yep. Duplicating the data model on the client and server is just one example of the insanity. I could go on, but that’s for another day.