The case for frameworks

Product market fit is generally achieved when you can’t keep up with demand for your product. “Can’t keep up” is generally an operational problem first, then a technical problem (the Do Things That Don’t Scale stuff catches up to you basically).

Scaling is a GOOD problem…as long as you actually have a business model. If you’re selling stuff but getting crunched by demand and your tech is cracking at the seams…hell yes! Pay people to fix the tech/replace the janky or slow stuff/automate manual things.

If you don’t have a business model, you can scale the shit out of some idea but not be able to afford to fix the issues coming from breaking out of your frameworks. Not to say you can’t eventually make this model work, you just have to raise a shit ton of money to do it usually.

Use frameworks. It’s not a debate. Don’t reinvent wheels when you’re trying to invent some new product idea.

Only work on the product.

He wasn't wrong in his assessment of complexity, but the fact he refused to acknowledge the business priorities were the same between Google and companies he called out, absolutely baffled me. The gist from my perspective was that companies external to his own should bend over backwards for performance, while his should not, because his personal goals were tied to improving the performance of the web. Hopefully that's an over-simplification and I've missed something, but that's what I can recall.

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

jQuery allows for websites to be interactive with minimal latency, but it's pretty low level so it leads to a lot of common problems. Like locking the main thread, undisciplined architectures, and a ton of issues with back/forward navigation.

SPA frameworks are developed to solve jQuery problems, but they introduce some new ones. Everything being JS is a big win, compared to split apps. But you have to deal with the up front cost of loading all the JS and a higher memory footprint.

And we iterate. SSR frameworks tone down the up front cost of SPAs in favor of more complex infrastructure. Frameworks that deploy to edge networks take another bite out of latency, but it isn't entirely clear what that will mean long term.

It feels so iterative that blaming framework popularity on malice is wild. There are real benefits to businesses, developers, and customers at every step along the path. Of course developers are going to follow along.

As someone who wants to advocate for standards instead of frameworks in my org, the problem I have is that the standards process is moving too slowly to address very basic and obvious developer needs. For example, the fact that Web Components are registered in a global namespace is really inconvenient in a large organization where you have many different teams making a large number of components. Sure, you can work around this with a BEM-like naming scheme, but you shouldn't have to. There's a great proposal for scoped custom element registries by one of the Lit developers that would actually address this issue, but it's been sitting in a repo for years without any meaningful activity and there doesn't appear to be any momentum around implementing it. Meanwhile, this is a thoroughly solved problem in the React and Vue ecosystems. That's just one small example, there are a ton of other papercuts and annoyances that there's no hope of fixing in the foreseeable future if solving them is going to involve a years-long slog through the standards process.

The DOM part spec that emerged from Apple's template instantiation proposal has the potential to provide an extremely efficient standards-based target for React-like frameworks that would solve a lot of the performance problems, especially if it's used judiciously for just the dynamic parts of the page in conjunction with server rendering and declarative shadow DOM. But nobody seems to be working on making that a reality, activity on that spec is pretty much dormant. React is going to keep winning until the standards furnish comparable ergonomics.

And it shows the same upsides and downsides as evolution vs e.g. gradient descent - you avoid getting stuck in local optima as people will always try out new stuff just to create something interesting (in business without clear evidence this will bring money it's hard) but finding an optimal solution is slow.

It is much easier to attain certain goals by having a well managed team who report to you directly or indirectly and you can order them basically what to do and create a coherent vision for what they produce.

Whilst I strongly agree SPAs are overused, let's take a moment to consider this sorry state of affairs. It's 2023 and when you ship some 50-200KB of executable code, you're in the red.

This is like 1/7th of a damn floppy disk, which I've lived through. Mobile apps are hundreds of MB in size, and we're supposed to compete with that using sticks and stones. Recently my Razor mouse had a driver update, it was 2GB in size. We learn about Unity on desktop, now able to render 17 trillion polygons per second yet we struggle to render some state and squares on the mobile web.

That's the real issue. Big parts of the mobile web are severely underpowered yet we still want to ship the "rich application" paradigm to them. Worse, without web standards offering anything remotely useful for this model.

That said, the idea that SPAs offer a superior experience that users are somehow demanding is bullshit when you consider how a typical SPA works. Consider a simple navigation action (route change) where the standard argument in favor of SPAs is that these are much faster compared to a traditional server-side page reload.

First, the SPA might need to load a new bundle, as tree shaking is the best practice where you lazily load per route code. This client code needs to be downloaded, parsed and executed, before anything even starts to happen. Next, the route-specific components mount. Many will require remote data, so at this point the page change may feel fast, it's useless and will remain useless until all remote network calls are resolved.

Compare this to a traditional, well-optimized MPA. You navigate to another route. The server will come back with ALL data/state resolved as well as all rendering (HTML) already done. And as this server response comes in, the browser is already working on the DOM layout/paint process, which is not true for a REST call. Plus, back/forward works reliably, scroll position works, memory leaks are no issue nor are stale tabs.

It's really debatable whether the SPA has the better experience or that users demand it. The point is to deliver meaningful content and interactions, that's the true value of whatever you are building. As such, I think the new wave of SSR/hybrid frameworks are a step in the right direction.

I'm sure React is great, Angular as well, and VueJS, but they have grown to be all encompassing, so a developer is never stuck and need to rewrite everything. Many frameworks starts up being small, so people can understand them and easily learn. Then as time goes by the frameworks grown until they become to big and someone once again feel the need for a lighter framework and the cycle repeats.

Currently I'm trying to build a VERY small web app. It does need a tiny bit of JavaScript to pull in new data every minute or so. It's much much easier to just forget about using a framework. It would take more time learning how you start a React or Angular project, than just learning the bits of modern JavaScript I need. Then I also don't need to bother with npm, webpack or any other packaging and build non-sense a framework would try to impose on me. That save even more time.

The article is correct that something like React will save developer time, if the project is large enough. If not, simply figurering out which framework to pick and learn how to set it up is going to constitute the majority of the time spend on the project.

In the end it is a problem of multiple, near equivalent, solutions with no sharp-enough success criteria. This makes the traditional approach of using "the right tool for the right job" lose its edge.

Why dont we have good enough filters to select technologies and designs? Ultimately it must be that people's expectations are low. Why is it so? One reason might be because the predominant value proposition is still dominated by the novelty introduced by global (mobile) connectivity. That is exemplified by minimalistic interfaces: the value is in the connectivity, not the information post-processing.

Once people get used to that basic fact they will start being more demanding and that might give rise to more differentiated criteria. In a sense right now there is much latent potential with existing tech that does not yet express fully because the conditions are not conducive.

Try to convince modern developers who build Gutenberg blocks to use React-free libraries or frameworks for their component libraries or front-end.

frameworks are all low-effort fun until you need to do some Hard Problem that they can't handle well, then suddenly the effort shoots up massively, because now you're trying to figure out how to do your hard problem within the structure and using the primitives of the framework.

bespoke solutions start off high-effort because you have to reinvent the proverbial wheel, but then as you keep rolling, it gets easier, and you have something that is better-architected for your exact problem. when the same kind of Hard Problem arises, you can solve it much more easily, because you're unburdened by trying to shoehorn the solution into the structure and primitives of someone else's framework.

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).