The case for frameworks

I've said it before and I'll say it again. The main reason we need bloated convoluted web frameworks with giant learning curves and a jillion gotcha's is because businesses want desktop-like GUI's and HTML/DOM/CSS/JS is ill-suited to emulate such, and perhaps stuck that way because fixing it will likely break backward compatibility.

Web is either missing or has screwed up too many common and expected GUI idioms: https://www.reddit.com/r/CRUDology/comments/10ze9hu/missing_...

We need a state-ful GUI markup standard. It perhaps should piggy-back off the Tk or Qt GUI kits to avoid starting from scratch. Let's practice industry-wide KISS, DRY, and YAGNI. Past attempts are YAML (too static & convoluted), XUL (too convoluted), and QML (too proprietary).

With such a standard, developing GUI/CRUD apps could be more like using Delphi/Lazarus or WinForms, which are faaar more pleasant than webshit, at least for smallish projects. ("Enterprise" may need different tooling. One size doesn't fit all.)

Recent related HN story: https://news.ycombinator.com/item?id=34696635

There's been shockingly little mainstream change in how we write apps in the browser. Not a lot of frameworks have stepped up to present interesting new compelling capabilities. To Alex's point: it's not just that the customer doesn't know what they're buying, it's that there's not much significant difference between the goods (frameworks) and most get us to similar ends.

Mainly I think this boils down to there not being much actual innovation. Usually whatever framework you pick is fine: so long as it has sticking power/can survive, it probably won't get too far in the way, and it probably won't really provide a major boost other than giving you some frame of reference to adhere to, some theme to riff off of. Sometimes frameworks overreach, promise to much, and collapse, sometimes they whither, but a huge amount stick around & just keep doing what they're doing, and few have real differentiating power. Although they are all written in their own distinct opinionated styles, they're usually not very important.

Here's some topics we could be making head-way on to make webapps better: incremental loading, early hints, url based routing, service-worker services, off-main thread services. There's more experimental areas: custom elements, p2p data-channels, offline capable apps. Web Share & Web Share Target and protocol handler capable apps. Multi-window placement apps, PIP apps. Reactive systems (mobx). IoC/Dependency Injection. WebBundles/WebPackage, Signed Exchanges, Http Signatures. Some of these wander far from the central core of what a framework might need, but others could be compelling dynamic parts. But the current position of frameworks, what they consider their purview, is very narrow. Personally I think the modern client stack should look a lot more like a web-server than it presently does.

Right now we still write code like it's a process, but the web browser is really a multi-process environment. We have yet to see frameworks that really take that possibility & aim for it. One of wasm's most interesting possibilities is that we end up not with big processes ported to wasm, but lots of smaller littler independent processes communicating: I think the server-side people have thought about that, are excited for those very lightweight virtual machines, but I don't see the front end as thinking about how to decouple & unbundle & un-monolithize their front-end. There's ideas of portals and front-end microservices, but these are still often talking about fair conventional webapp architectures, just having many at once: they don't tackle or think about interconnection & shared services, about a network of front end microservices/microapps.

The whole SSR thing is interesting & good work is happening to reshuffle & re-explore, but again, I just think interest arose here in part because the client-side failed to keep pioneering & failed to be exciting, so this was just an open/available other place to go explore. And while it has lots of virtues, I don't think it's actually that exciting or important, not nearly as much as improving the client-side, where the user agency is actually seated. The frameworks need to expand, especially client side. We all got safe & conservative, started to apply the industrialized tools that work, and the hotbed of exploration & innovation got demolished, was squelched. And we all had our energy sapped figuring out how to build & bundle our stuff, via endless tooling, which we still are only so so ok at (still nothing would be a nice/easy as an EcmaScript Modules that would just work with source-as-it-is-authored, which Deno seemingly sort of pulls off, but the web is still far from).

The “don’t reinvent the wheel “ argument is overstated. If you’re avoiding frameworks, you tend to build up your own libs that “plug and play”. It’s not like you rewrite a sessions lib every time you build a new backend server. You copy the file over from your last project. If it’s a more involved problem, like correctly implementing HTTP, you use a battle tested library.

I’ve worked at a startup that went all in on frameworks and the day we crossed the pain threshold with Relay, dev time slowed to a crawl. Really hindered our ability to ship product as you say, and the switching costs were high, because frameworks underpin everything you do, you can’t just swap them out like libraries

> Until you’ve hit product market fit, you shouldn’t build anything other than what is unique to your product.

How unique is your product really though? If you're a biotech company or something that also needs a website, sure, use whatever the most widely used framework is at the moment. But I feel like most of the focus of these discussions is on web-native SaaS companies whose entire business is on moving some well understood commercial activity onto the web or competing with other well-established web businesses from the huge tech companies. Stuff like e-commerce, productivity software, social networking tools, developer tools, financial tools, insurance tools, restaurant booking, hotel booking, doctor booking, etc. These companies probably feel like they need their edge to be things like development velocity and unit economics (e.g. no human customer support), and they probably feel like the only way to do that is to have a bespoke development platform.

Right, so pick old boring frameworks. Rails, Django, Phoenix, etc.