11 ms·

The case for frameworks

154 points by jacobr 4y ago

onlypositive 4y ago
Half of those example sites he says should be SPAs should not be SPAs at all. They can be, and are, but certainly don't need to be by any stretch.
- the_gastropod 4y ago
  Yea. I didn’t understand the criteria given: long running sessions and authenticated content. Why do those necessitate a SPA?!
  - chrsjxn 4y ago
    Long running sessions seems pretty straightforward. The cost of an SPA is heavily front-loaded, so the longer you have the app open, the more that cost can be spread. Authenticated content is likely for a mix of reasons. It can't be indexed, so doesn't need to optimize for SEO. Users that log in are higher intention, so they're less likely to bounce if the page loads slowly. It's definitely more complex than just these things, but the inverse (an app that requires SEO and minimal upfront costs) are often used as justifications for moving away from modern frameworks.
    - onlypositive 4y ago
      Not needing to be indexed is what allows SPA, it doesn't justify it. Similarly, page speed should matter regardless and tbh what I've seen in the wild people restricting themselves to serverside renders have far superior load times due to cachability and lightweight page designs. I think the article hits the nail on the head, were opting for devex over UX. I don't think it's really a problem, I use react in a large org (one of the spa examples funnily enough) and it does enable workflows and org structures that would not work without the site being a spa. Whether that trade off is worth it I'm not sure. While it enables org structures that work for us Im not convinced the resulting empire building and feature spam was worth it for users.
    - fleddr 4y ago
      Those sound like reasons that allow you to get away with a SPA, as their downsides are minimized. They are not objective reasons to necessitate SPA.
baguettefurnace 4y ago
I agree that we overestimate the need for singlepage apps. the only thing that really needs singlepage is something that plays music or video content - so you can nav without stopping the music
tabtab 4y ago
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_or_defective_gui_idioms_in_htmldom/ 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 https://news.ycombinator.com/item?id=34696635
- nicoburns 4y ago
  Web frameworks are complicated. But frameworks like QT are no less complicated.
  - Ambolia 4y ago
    I have never seen a QT application making chunks of text disappear somewhere between my keyboard and my screen, but the front page of google keeps randomly doing it to this day. If google can't get basic text input right on the web, there's something very broken there.
    - tabtab 4y ago
      It indeed amazes me how screwed up the big dogs' web apps are. The web & phone version of MS-Outlook was notorious for about 2 years. They did gradually mostly fix it, but it was a painful journey. The limits of current web standards have to be part of the cause for this gap; otherwise having a mound of money to throw at a site would work. There are many other corporate apps I could make similar complaints about.
dchuk 4y ago
Until you’ve hit product market fit, you shouldn’t build anything other than what is unique to your product. If you are spending time on authentication or forms or worker queue architecture, you’re wasting time. Frameworks and plug-ins exist to allow this to be all plug and play, so you can focus on building something potentially useful enough for people to pay for it. 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.
- tabtab 4y ago
  > Frameworks and plug-ins exist to allow this to be all plug and play Too many are buggy and/or poorly documented and take lots of trial and error to get working as intended. And you create a dependency mess by including lots of pluggins/libraries. It may be quick up front, but can jack maintenance after say 5-ish years. Multi-K-lines-of-code libraries "rot" as environments change. If you can write a shop-tuned version in say 300 lines, do it, because it's easier to fix later. Select vendor libraries/pluggins judiciously.
  - dchuk 4y ago
    Right, so pick old boring frameworks. Rails, Django, Phoenix, etc.
  - ian0 4y ago
    This is true and in experience happens far quicker than 5 years for JS frameworks. Most of the frameworks I learned 5-10 years ago are already effectively dead too. But I think OPs main point stands, your far more likely to die by not shipping things early than by having to refactor occasionally. After 5 years 50% of businesses have failed [0] and this is far far higher for startups & side projects. [0] https://www.bls.gov/bdm/entrepreneurship/entrepreneurship.htm https://www.bls.gov/bdm/entrepreneurship/entrepreneurship.ht...
rektide 4y ago
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).
margorczynski 4y ago
Open source is really interesting in the regard that for many projects it starts being optimized not by top-down design but by evolution. You get many variations on the same idea that live, die, merge into one or mutate step by step into something else. Similar thing with Linux distros. 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.
AWebOfBrown 4y ago
Everything I needed to know about Russell's performance war was answered when, whilst he was working at Google, folk started asking him why he was naming and shaming companies for poor performance when his exact critiques were swiftly applied to Google's apps (calendar, maps, gmail). I wish I could find the twitter thread from back then, but the gist of his response was that what Google was doing was incredibly complicated, far more than anything the targets of his ire were working on, and as such it was reasonable not to have fixed those issues. 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.
- dmitriid 4y ago
  Don't forget that he's also shaming everyone for complexity while his own work brings untold complexity to the web platform through dozens of Javascript-only standards around Web Components.
- mattgreenrocks 4y ago
  Ah yes, the classic "our problems are the hardest" perspective. These are usually the narratives we tell ourselves to let ourselves off the hook.
- swyx 4y ago
  “it is difficult to get a man to understand something, when his salary depends on his not understanding it.” - Upton Sinclair.
bentlegen 4y ago
I thought this was an interesting, alternative lens at looking at the economic balance between supporting long-tail customers with higher performance needs vs. developer time/cost. I suspect internationalization efforts operate similarly; it’s not often worthwhile to translate your software into many languages, many of which are rarely read/spoken by users of your software.
segphault 4y ago
I am deeply sympathetic to Alex Russell's position on frameworks, but the reality is that he's never going to move the needle by badgering developers to prioritize performance over developer experience. The ecosystem won't move on from React to more performant and standards-based alternatives until those alternatives provide a competitive developer experience. 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.
- dmitriid 4y ago
  > The ecosystem won't move on from React to more performant and standards-based alternatives until those alternatives provide a competitive developer experience. Meanwhile frameworks and libs (even those who originally were very supportive of the idea of web components) have moved past WCs and are exploring approaches that WCs will never ever be able to provide such as granular reactivity, seamless frontend-backend integration, or even eschewing components as a rendering primitive entirely. > React is going to keep winning until the standards furnish comparable ergonomics. In all honesty, Scoped CSS + Nested CSS proposals coupled with https://open-ui.org https://open-ui.org would've solved 99% of what web components are trying to be. Meanwhile we're about 20 years away from WCs as a finished thing: https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html
technojunkie 4y ago
As long as WordPress fully embraces React as its future for Gutenberg, the case for frameworks still continue to be made for React. ~43% of all websites run WordPress, and those on version 5 or newer include React. Try to convince modern developers who build Gutenberg blocks to use React-free libraries or frameworks for their component libraries or front-end.
chrsjxn 4y ago
It's fun to look back on the success of SPAs from the perspective of someone who learned to build websites pre-jQuery. 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.
- crabbone 4y ago
  Let's look at it from a different perspective. Web wasn't meant to be an application platform. It accidentally became one, due to events that had nothing to do with technological merit, but were social in nature. For instance, technologically, Flash is a much better platform for applications than HTML+JavaScript combo will ever be. But, it failed due to Adobe's bad market strategy. But Flash, too, was a band-aid on top of broken tech. It was obvious that Web was not meant for what Flash was trying to do, Flash was just better at overcoming the problems than HTML+JavaScript is. Web frameworks aren't here to add value, they are here to patch bad foundations. To deal with "defects" (or, rather the consequences of unintended use) of HTML and JavaScript. So, they will inevitably be bad, because they are trying to fix the problem they didn't create and that is beyond their power to fix. And as long as Web stays the application platform of choice, Web frameworks will cause a lot of resentment amongst their users.
  - mejutoco 4y ago
    > For instance, technologically, Flash is a much better platform for applications than HTML+JavaScript combo will ever be Flash was very nice for some use-cases, but it leaked memory. It is not a good fit for long-running apps (probably why Flex/Adobe Air failed, too).
pictur 4y ago
What was said for the SSR now, was said then for the SPA. People generally like to talk nonsense. I always see a comment like this under every post like this; - SPA doesn't work + why? - because it doesn't work
college_physics 4y ago
The debate seems only to get even more convoluted with the browser slowly opening up to things beyond javascript and interactions with servers getting richer too (eg htmx, websockets) 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.
- 7sidedmarble 4y ago
  Not sure I understand how htmx fits into that. It is in essence a JavaScript project: one that lets you do JavaScript things from html. And to do that it's written in JavaScript. I think it's very wrong to think of it as some kind of real aspect of the html.
mrweasel 4y ago
There's certainly value in frameworks, but like with so many things we build today, most of them are build for a scale that most people don't need. 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.
- incrudible 4y ago
  > It would take more time learning how you start a React or Angular project… That time has has already been spent, because you hired React developers. They will be fastest by pulling in React. Really, the argument could end here. Yes, there is overhead in using it, things can get out of hand, but they do not have to. If they do get out of hand, would vanilla web technology have prevented that?
  - ragnese 4y ago
    > That time has has already been spent, because you hired React developers. They will be fastest by pulling in React. I'm not entirely convinced that this is true, either. At least not in some general, a priori, way. Doing stuff "the right way" with React or any other framework probably still involves a fair amount of ceremony, boilerplate, and testing. Would your hypothetical React dev be faster with React than some other framework? Probably--if that other framework is similar in scope and complexity. But, otherwise, I just wouldn't assume that an expert in FrameworkX will always do better using FrameworkX without regard to the specifics of the project.
fleddr 4y ago
I think the original point of the discussion is somewhat lost, which is not frameworks, it's shipping too much JS to the client which in particular hurts on Android. 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.
- Ambolia 4y ago
  >Compare this to a traditional, well-optimized MPA. You navigate to another route. I think the issue here is that on an MPA you may get a white page for a while, or a page with missing pieces in unexpected ways, even if the overall loading is faster it looks more broken.
ravagat 4y ago
Interesting. I want to know for anyone: do you think frameworks are boilerplate and vice versa?
adamrezich 4y ago
the framework/bespoke complexity/effort graph in this article is one of the most brazenly untrue graphs I've ever seen. 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.

154 points by jacobr 4y ago

Half of those example sites he says should be SPAs should not be SPAs at all. They can be, and are, but certainly don't need to be by any stretch.

the_gastropod 4y ago
Yea. I didn’t understand the criteria given: long running sessions and authenticated content. Why do those necessitate a SPA?!
- chrsjxn 4y ago
  Long running sessions seems pretty straightforward. The cost of an SPA is heavily front-loaded, so the longer you have the app open, the more that cost can be spread. Authenticated content is likely for a mix of reasons. It can't be indexed, so doesn't need to optimize for SEO. Users that log in are higher intention, so they're less likely to bounce if the page loads slowly. It's definitely more complex than just these things, but the inverse (an app that requires SEO and minimal upfront costs) are often used as justifications for moving away from modern frameworks.
  - onlypositive 4y ago
    Not needing to be indexed is what allows SPA, it doesn't justify it. Similarly, page speed should matter regardless and tbh what I've seen in the wild people restricting themselves to serverside renders have far superior load times due to cachability and lightweight page designs. I think the article hits the nail on the head, were opting for devex over UX. I don't think it's really a problem, I use react in a large org (one of the spa examples funnily enough) and it does enable workflows and org structures that would not work without the site being a spa. Whether that trade off is worth it I'm not sure. While it enables org structures that work for us Im not convinced the resulting empire building and feature spam was worth it for users.
  - fleddr 4y ago
    Those sound like reasons that allow you to get away with a SPA, as their downsides are minimized. They are not objective reasons to necessitate SPA.

baguettefurnace 4y ago

I agree that we overestimate the need for singlepage apps. the only thing that really needs singlepage is something that plays music or video content - so you can nav without stopping the music

tabtab 4y ago

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_or_defective_gui_idioms_in_htmldom/ 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 https://news.ycombinator.com/item?id=34696635

nicoburns 4y ago
Web frameworks are complicated. But frameworks like QT are no less complicated.
- Ambolia 4y ago
  I have never seen a QT application making chunks of text disappear somewhere between my keyboard and my screen, but the front page of google keeps randomly doing it to this day. If google can't get basic text input right on the web, there's something very broken there.
  - tabtab 4y ago
    It indeed amazes me how screwed up the big dogs' web apps are. The web & phone version of MS-Outlook was notorious for about 2 years. They did gradually mostly fix it, but it was a painful journey. The limits of current web standards have to be part of the cause for this gap; otherwise having a mound of money to throw at a site would work. There are many other corporate apps I could make similar complaints about.

dchuk 4y ago

Until you’ve hit product market fit, you shouldn’t build anything other than what is unique to your product. If you are spending time on authentication or forms or worker queue architecture, you’re wasting time. Frameworks and plug-ins exist to allow this to be all plug and play, so you can focus on building something potentially useful enough for people to pay for it. 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.

tabtab 4y ago
> Frameworks and plug-ins exist to allow this to be all plug and play Too many are buggy and/or poorly documented and take lots of trial and error to get working as intended. And you create a dependency mess by including lots of pluggins/libraries. It may be quick up front, but can jack maintenance after say 5-ish years. Multi-K-lines-of-code libraries "rot" as environments change. If you can write a shop-tuned version in say 300 lines, do it, because it's easier to fix later. Select vendor libraries/pluggins judiciously.
- dchuk 4y ago
  Right, so pick old boring frameworks. Rails, Django, Phoenix, etc.
- ian0 4y ago
  This is true and in experience happens far quicker than 5 years for JS frameworks. Most of the frameworks I learned 5-10 years ago are already effectively dead too. But I think OPs main point stands, your far more likely to die by not shipping things early than by having to refactor occasionally. After 5 years 50% of businesses have failed [0] and this is far far higher for startups & side projects. [0] https://www.bls.gov/bdm/entrepreneurship/entrepreneurship.htm https://www.bls.gov/bdm/entrepreneurship/entrepreneurship.ht...

rektide 4y ago

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

margorczynski 4y ago

Open source is really interesting in the regard that for many projects it starts being optimized not by top-down design but by evolution. You get many variations on the same idea that live, die, merge into one or mutate step by step into something else. Similar thing with Linux distros. 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.

AWebOfBrown 4y ago

Everything I needed to know about Russell's performance war was answered when, whilst he was working at Google, folk started asking him why he was naming and shaming companies for poor performance when his exact critiques were swiftly applied to Google's apps (calendar, maps, gmail). I wish I could find the twitter thread from back then, but the gist of his response was that what Google was doing was incredibly complicated, far more than anything the targets of his ire were working on, and as such it was reasonable not to have fixed those issues. 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.

dmitriid 4y ago
Don't forget that he's also shaming everyone for complexity while his own work brings untold complexity to the web platform through dozens of Javascript-only standards around Web Components.
mattgreenrocks 4y ago
Ah yes, the classic "our problems are the hardest" perspective. These are usually the narratives we tell ourselves to let ourselves off the hook.
swyx 4y ago
“it is difficult to get a man to understand something, when his salary depends on his not understanding it.” - Upton Sinclair.

bentlegen 4y ago

I thought this was an interesting, alternative lens at looking at the economic balance between supporting long-tail customers with higher performance needs vs. developer time/cost. I suspect internationalization efforts operate similarly; it’s not often worthwhile to translate your software into many languages, many of which are rarely read/spoken by users of your software.

segphault 4y ago

I am deeply sympathetic to Alex Russell's position on frameworks, but the reality is that he's never going to move the needle by badgering developers to prioritize performance over developer experience. The ecosystem won't move on from React to more performant and standards-based alternatives until those alternatives provide a competitive developer experience. 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.

dmitriid 4y ago
> The ecosystem won't move on from React to more performant and standards-based alternatives until those alternatives provide a competitive developer experience. Meanwhile frameworks and libs (even those who originally were very supportive of the idea of web components) have moved past WCs and are exploring approaches that WCs will never ever be able to provide such as granular reactivity, seamless frontend-backend integration, or even eschewing components as a rendering primitive entirely. > React is going to keep winning until the standards furnish comparable ergonomics. In all honesty, Scoped CSS + Nested CSS proposals coupled with https://open-ui.org https://open-ui.org would've solved 99% of what web components are trying to be. Meanwhile we're about 20 years away from WCs as a finished thing: https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html

technojunkie 4y ago

As long as WordPress fully embraces React as its future for Gutenberg, the case for frameworks still continue to be made for React. ~43% of all websites run WordPress, and those on version 5 or newer include React. Try to convince modern developers who build Gutenberg blocks to use React-free libraries or frameworks for their component libraries or front-end.

chrsjxn 4y ago

It's fun to look back on the success of SPAs from the perspective of someone who learned to build websites pre-jQuery. 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.

crabbone 4y ago
Let's look at it from a different perspective. Web wasn't meant to be an application platform. It accidentally became one, due to events that had nothing to do with technological merit, but were social in nature. For instance, technologically, Flash is a much better platform for applications than HTML+JavaScript combo will ever be. But, it failed due to Adobe's bad market strategy. But Flash, too, was a band-aid on top of broken tech. It was obvious that Web was not meant for what Flash was trying to do, Flash was just better at overcoming the problems than HTML+JavaScript is. Web frameworks aren't here to add value, they are here to patch bad foundations. To deal with "defects" (or, rather the consequences of unintended use) of HTML and JavaScript. So, they will inevitably be bad, because they are trying to fix the problem they didn't create and that is beyond their power to fix. And as long as Web stays the application platform of choice, Web frameworks will cause a lot of resentment amongst their users.
- mejutoco 4y ago
  > For instance, technologically, Flash is a much better platform for applications than HTML+JavaScript combo will ever be Flash was very nice for some use-cases, but it leaked memory. It is not a good fit for long-running apps (probably why Flex/Adobe Air failed, too).

pictur 4y ago

What was said for the SSR now, was said then for the SPA. People generally like to talk nonsense. I always see a comment like this under every post like this; - SPA doesn't work + why? - because it doesn't work

college_physics 4y ago

The debate seems only to get even more convoluted with the browser slowly opening up to things beyond javascript and interactions with servers getting richer too (eg htmx, websockets) 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.

7sidedmarble 4y ago
Not sure I understand how htmx fits into that. It is in essence a JavaScript project: one that lets you do JavaScript things from html. And to do that it's written in JavaScript. I think it's very wrong to think of it as some kind of real aspect of the html.

mrweasel 4y ago

There's certainly value in frameworks, but like with so many things we build today, most of them are build for a scale that most people don't need. 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.

incrudible 4y ago
> It would take more time learning how you start a React or Angular project… That time has has already been spent, because you hired React developers. They will be fastest by pulling in React. Really, the argument could end here. Yes, there is overhead in using it, things can get out of hand, but they do not have to. If they do get out of hand, would vanilla web technology have prevented that?
- ragnese 4y ago
  > That time has has already been spent, because you hired React developers. They will be fastest by pulling in React. I'm not entirely convinced that this is true, either. At least not in some general, a priori, way. Doing stuff "the right way" with React or any other framework probably still involves a fair amount of ceremony, boilerplate, and testing. Would your hypothetical React dev be faster with React than some other framework? Probably--if that other framework is similar in scope and complexity. But, otherwise, I just wouldn't assume that an expert in FrameworkX will always do better using FrameworkX without regard to the specifics of the project.

fleddr 4y ago

I think the original point of the discussion is somewhat lost, which is not frameworks, it's shipping too much JS to the client which in particular hurts on Android. 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.

Ambolia 4y ago
>Compare this to a traditional, well-optimized MPA. You navigate to another route. I think the issue here is that on an MPA you may get a white page for a while, or a page with missing pieces in unexpected ways, even if the overall loading is faster it looks more broken.

ravagat 4y ago

Interesting. I want to know for anyone: do you think frameworks are boilerplate and vice versa?

adamrezich 4y ago

the framework/bespoke complexity/effort graph in this article is one of the most brazenly untrue graphs I've ever seen. 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.