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.
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
The issue described relates more to any dependency with the more core and critical the dependency the worse the problem can be. A ‘framework’ is just part of the rough taxonomy of dependencies and happens to often be core and critical.
Yeah, but you're still likely reinventing capabilities that exist in react or a plugin. Even if you re-use it, you still have to build it the first time instead of iterating on your product.
> 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.
IMO, aggressive npm install is the superset of the framework problem. We code review every line written by other developers at our company with a fine toothed comb, but will add a dependency from a massive advertising company or some dude in Russia without a second thought. It’s wild.
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.
I just pulled in a class-based component into a modern React project. It just worked with no adjustment.
Now that's commitment to backward compatibility (and they can't have it any other way, they won't rewrite half of facebook just because their own framework changed).
> your far more likely to die by not shipping things early than by having to refactor occasionally.
Know your org. A startup has very different priorities than a bank, for example.
Small projects need different conventions than big projects, internal need diff than external, 200 user apps need diff than "web scale", etc. I'm more careful now to state the assumed environment because one size doesn't fit all. And fit your org, not your resume. Buzzword oriented programming is selfish; I've seen it make screwball messes.
But if that was the case, you would do that, resorting to other tools for something that tiny is silly and only really done by beginners. Something that tiny would also unlikely have bug or documentation issues.
There are some great tools that are poorly documented/buggy, yes, but they are quite rare and it's much easier to use them and fork the repo (if inactive) than to build from scratch.
This idea that you avoid creating a dependency mess by writing more of your own work, isn't the entire truth. The dependency is just internal, and far more likely to have poor documentation than open source plugin #4159. So you really haven't solved or avoided the problem at all.
It's pretty easy to find that the example I gave isn't gamed... A cursory search on GitHub can find a couple examples like dotenv [1] and npm's cli [2] both use it via an older version of nodejs/readable-stream [3].
> This idea that you avoid creating a dependency mess by writing more of your own work, isn't the entire truth. The dependency is just internal
The point is that it's better to depend on something simple and quickly fixable than something convoluted. Vendors/sponsors can and do go away.
If you have a skilled API builder, they know how to do KISS. If a specific need requires something that's not KISS-able, such builders will be honest about it and recommend a pluggin. But every shop and domain is different such there are indeed cases where throwing libraries at the problem is the right tool for that particular job.
This argument reminds me of people who confuse market success with product quality. I.e. some people believe that if the product sells well, then it must be a good product.
You don't need to try hard to convince yourself that there's no causal link between the two (eg. fast food sells well, but isn't good food, high-end goods usually don't sell well because buyers aren't willing to pay extra for marginal improvements).
And so does your argument. The post OP was the reaction to was talking about quality and how misguided the whole field is in terms of using existing, concrete pieces of software s.a. React. And that is, unfortunately, the reality. Web is awful, especially because of how it's been developed, especially due to things like React. But it also sells well. But this wasn't the point.
> Pay people to fix the tech/replace the janky or slow stuff/automate manual things.
Sometimes? When circumstances allow that? This is not a given. And with the way Web is, and the way it's going, it's only getting worse. HTML is a bloated standard. JavaScript is an idiotic language. The GUI toolkit that browser offer is a combo of bloat and idiocy. The whole idea of making "single page applications" is idiotic because Web was never meant for that. It was meant to be an interface to what today we'd call a distributed document database. But is this going to change because individual programmers or individual companies recognize the problem? Are they going to fix / automate it? -- well, there's no way a single company, not even a mega international corporation at this point, which could do that.
The argument the OP was the counter-argument to was saying that Web needs a different foundation and that no modern frameworks are any good. It didn't go as far (as I did) in claiming that the whole stack is garbage. Still, you are missing the point when you are making an abstract argument about using frameworks. The point was: "we have garbage frameworks in Web, and things are getting worse, let's take action to do things differently".
Exactly, the point of frameworks like React is to patch over issues with html, css, javascript and the DOM. Dropping React (the framework) will just make you deal with those issues in particular ways that only you understand, but it won't make them disappear.
That’s strange, I thought the point of React was to make websites slow and laggy so you can save on server costs by just serving json after the initial payload.
Some of us still remember the golden years of doing the same but with jQuery snippets spread through hundreds of files with zero logical connection between them except in the developer's mind.
I have no issues with frameworks and libs but the fact I know I’m on site built with react because everything gets laggy and my laptops fans start spinning is not a great selling point.
Yes, the web is a terrible platform for applications. Anything on the web that goes beyond the equivalent of linked PDFs will be wonky.
There's nothing on the web even approaching 1990s desktop applications. Specially if you care about latency, precision, and text inputs not randomly eating what you type.
Even with the wonkiness, the web is usually worth using because of the access you get to big amounts of data and backend servers providing nice services.
Aaaand... this doesn't make React good. It makes HTML+CSS+JavaScript bad. Here's the problem. These three need fixing. Or, rather, replacing altogether if you want a platform for distributing applications. While any strategy for replacement right now seems impractical, the opposite of it is not good either. Not being able to do the right thing doesn't make the least wrong thing the right thing.
Yes, but as you said the web is a broken platform for applications. Painting a picture where we lived in a perfect world until React introduced some problems is a wrong analysis. React solved some (not all) problems of the web as a platform for GUIs, and introduced a new set of problems. People make their choice and choose which set of problems they prefer to work with.
The web works well for displaying static pages with links between them (if you are ok with some ugly things while the page loads), but once you introduce Forms or any sort of interactivity with the user all hell breaks loose and you will have to choose what you patch over, and what sacrifices you make.
Agreed. I posted this comment a few years ago, but it looks like it's relevant as here as well:
A potential acquisition came our way that seemed to be exactly what we were looking for. Customer traction and revenues, the features exactly what we were looking to overhaul. There was very high internal interest in acquiring the technology and the company.
The need for this set of features was so high and the internal development estimated to be so costly (in developer time and delays in other projects) we were willing to overlook that this app was not built on our primary stack and only a few of our developers were familiar with. The language choice made by the company didn’t cool our appetite. However, technological choices made us pass on the acquisition.
They didn’t use a framework.
This means that our developers would have a very long learning curve. We also saw a lot of code that did what a framework would have taken care off and this means that we would have had to learn, maintain and expand that code instead of working on the revenue generating features.
We found close coupling of code all over the place. This meant we couldn’t quickly extend and modify the features as we wanted without first paying back the technical debt accumulated by the developers.
It wouldn’t have mattered which framework they would have chosen as most of them have good documentation and force some sort of standard development practices. However, we couldn’t take a chance that all the behind the scenes stuff would need a rewrite if we wanted to expand and scale the platform. We passed.
> 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.
A decent rule of thumb I follow: If there's a gem/plugin/package that could do something I want in my product...use it. Don't write the code yourself, unless it actually straight up can't provide the UX or capability you need for your product.
It's hard to argue with a rule of thumb that broad, but I think it's too broad to be useful in practice. You will still always need to make case-by-case decisions at your own discretion, and the rule of thumb will be unnecessary in uncontroversial cases (you probably won't even consider writing your own code to format a number as a string on your website) and will easily be ignored in other cases ("yes, we could just build our homepage and merch page in Squarespace, but we're going to want total control over that entire product so we're going to build it ourselves").
You don't need frameworks to do that though. You can just libraries for authentication that do all the work for you.
The difference is important though. With libraries, you have to connect them to each other. With a framework you don't. But with a framework, if the predefined connection isn't working for your case, you spend way more time to change it. That is, if the framework is good.
That’s good advice for people working at startups, but I work for a huge non-tech Fortune 50 company that employs tens of thousands of people who work on the products. I’m basically paid to spend time on “authentication or forms or worker queues”.
This is how you end up with massive tech debt though right? Replacing a dependency is going to be more expensive than writing something yourself, especially if it’s been around a long time.
Possibly you will end up with tech debt. But similarly to how most start ups begin with financial debt until their product generates enough revenue, it can also be a perfectly good strategy to allow for tech debt in the beginning. If this enables you to bring a MVP to the market faster than your competitors, you're good.
I think there's a problem of what we actually mean when we call something a "framework." Is an ORM a "framework" for interfacing with persistent data stores (usually SQL databases)? Common parlance says it is--and I tend to agree--but, it's also "just" a library to get in between your app and your data, which feels different than, say, a web framework that dictates how your whole project is structured, what auth methods are "supported", what interfaces your handler code is allowed to implement, etc.
But, I also I think your sentiment is somewhere between a generally wise piece of advice/wisdom and a vacuously true statement of fact. The latter because of course you should not reinvent the wheel if there's a perfectly fine wheel already out there.
Frankly, a lot of these things we call frameworks are actually fairly low quality. And I say that with the humility of knowing I couldn't do any better, but that doesn't make it less true. One of my "favorites" to shit on is the Java ecosystem. In particular, JDBC/Hibernate for ORM/SQL stuff, and JacksonXML for (de)serialization. Both are absolutely awful for various reasons, but my go-to example is that JDBC literally doesn't have an API for getting a nullable integer column value out of a ResultSet; instead, you have to get a non-nullable int primitive which will be `0` if the database value was `NULL`, THEN you have to call a second method to ask "Was the previously returned value from this ResultSet actually a NULL instead of whatever I got?". This manifests in Hibernate as requiring an easy-to-forget-or-misuse annotation on your DTO class.
My point is that some of these frameworks are a total nightmare for reliability and robustness, and I'm not convinced that just reflexively opting in to all of the "de facto" frameworks at the beginning of a software project is always the right move.
Prior to product market fit you should take the shortest possible path to delivering your essential feature set. You have a short runway and if you hit the end, it's game over.
That path may or may not involve a framework. One common developer mistake is to use a framework not because it will save time, but because it's a brand name and they think it'll save them from having to learn about a particular problem space.
For example, any developer should be able to build a simple task queue in a couple of days. You can read about how they work, find a simple example or two, and code one. Will it have lots of features? No. Will it scale? No. Does any of this matter before you have product market fit? No.
Along the way you make sure you have good separation of concerns in your overall architecture, so that _if_ it turns out there are many actual humans who want to pay for this idea, you can swap out what you wrote and replace it with something better.
As a bonus, by the time this happens you'll understand task queues (and in particular what your product needs one for) very well. So picking and implementing the right framework will be easy.
If a framework is the easiest way to get to something the market can validate, use it! If it's not, don't.
It's really not that hard to understand how any of the common building blocks of a modern web app works. To understand it deeply, sure, that may take 20 years, but at PMF that depth is not critical yet.
Let's be honest - 80% of the time when we talk about doing things "right" we are really talking about concurrency and scale. Premature optimization is the root of all evil and so on...
> Along the way you make sure you have good separation of concerns in your overall architecture, so that _if_ it turns out there are many actual humans who want to pay for this idea, you can swap out what you wrote and replace it with something better.
This is the key right here. Very little else matters. Where a lot of companies get this wrong is they either go the route of picking a minimal framework and writing everything in-house only to have created a very unique monster that took a lot of time at the end or they go all in on frameworks without identifying the bottlenecks as they go along and they wait until its too late to make an easy transition.
> 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.
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.
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.
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.
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.)
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.
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.
The proliferation of frameworks and confusion as to which one I should take the time to learn has pushed me towards dart/flutter as a solution for a cross platform GUI language.
Having said that I have been looking at htmx recently.
Excellent, I'm not alone in feeling something is missing from the industry.
I'm in the early stages of a proof-of-concept using MS-WinForms to write a GUI browser. Nothing special about WinForms, I'm just somewhat more familiar it and C#, and there's a lot of web help for MS tooling. The demo wouldn't be feature rich; just enough to get a feel for possibilities.
But in parallel, we can kick around what the "ideal" markup language could look like here:
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.
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.
Yeah, that's true. Flex, however, dedicated some efforts to accessibility. But, developers didn't want the components Flex had to offer. Custom stuff almost never implemented accessibility interfaces.
This also impacted how search worked. At the time of the sale of Flash to Adobe, either Macromedia before the sale, or Adobe right after the sale donated a "headless" version of Flash player to Google in hopes that they'll make something of it, something that'd help with searching within Flash applets... I don't know the details, but I know that the project essentially failed to even start. That player never received any updates, and Google wouldn't search inside Flash. I think, the real reason was that it was just way too hard to search inside Flash due to the very dynamic nature of these applets. Pieces of text would often appear in very small chunks, random order, impossible to tell if visible or not etc.
With HTML and JavaScript, eventually Google faced the same problem, and that's how they came up with Chrome. For some reason they decided not to make their own player.
That's a very bold claim about technology in general... Did every version of Flash player ever leak memory? -- I seriously doubt that. For practical purposes, even if there were leaks, Flash applications weren't supposed to run for more than few days on end, at least not until AIR came along and Flash expanded into the desktop world. The longest-running applications were browser MMO games which some gamer fanatics would play for several weeks in a single session. Even in this context, some other problems would prevent users from experiencing the adverse effects of memory leaks (usually, the game would crash due to some programming errors of the game developers, not because of the player).
Anyways, suppose for a moment that every Flash player since ever had a leak... well, Adobe's Flash is a relatively small C program, so more Valgrind tooling and more work would eventually had that fixed. It's not a flaw of technology in general, just a particular implementation. (There used to be GNash, and there's still Lightspark implementing the same technology).
> long-running apps (probably why Flex/Adobe Air failed, too).
I happen to have a bit of an insider insight here. I was on Adobe's CAB for about a year before they handed Flex over to Apache.
Long-running apps weren't a problem. Not enough to be ever mentioned in that context. The problem was in how the product was managed, in the misunderstanding of how to derive value from it.
Adobe wanted to sell two things:
1. Development environment (Flex Builder later renamed Flash Builder).
2. Services in development of Flash-based applications to enterprise users. (Think of VSphere Web console or some hospital interface etc.)
In both instances they made a bet on Flex. This was also the biggest argument in favor of buying Macromedia when Adobe bought it. Flash was hugely popular and growing and especially due to Flex which was a lot more appealing to developers than previous authoring tools.
What Adobe failed to realize is that the thing that made the technology popular ware these characteristics:
1. A tool for creating hand-made animations.
2. Very light-weight baseline components.
3. Video streaming.
The first two enabled indie game developers and small-scale e-commerce developers to create appealing products. And these were the absolute majority of the users of technology.
Adobe didn't do anything for their largest user group. They were working on a framework that grew slower and heavier by the day, and was, in its core, designed to mimic WindowsForms. They, essentially, were making a Web version of WindowsForms. The tool that they were trying to sell didn't support direct editing of animation, didn't even have a concept of timeline, no drawing tools etc. You were supposed to make your animations elsewhere and bring them pre-compiled into this tool. The code editing was so-so... an Eclipse-based heavy-weight plugin very much constrained by the abilities of the host. They tried to make "designer" view, similar to one that exist in MSVS, but that project failed due to lack of demand on the user side and lack of attention on the developers' side...
Adobe didn't allocate enough efforts to maintain the open-source code they had. At some point there was literally no one maintaining the MXMLC code. And then they made repository read-only and stopped accepting merge requests from community (there weren't many anyways). On the community part there was a growing disappointment that part of the toolchain always remained proprietary and that cheaper automation that could be run on Linux was always broken.
And then Adobe decided to dedicate the remaining development effort to the product you probably never heard of: Flash Catalyst. It was supposed to be a kind of an extension to Flash Builder, more geared towards animations and... mobile :D At that point, Flash was already on its last legs, and Apple dealt it final blow by completely disallowing it on its devices. Catalyst was scrapped. Adobe allocated the bare minimum of development effort to keep patching the player with security patches and hastily arranged for Flex to be handed to Apache.
I don't think that even after all that happened they learned about the reasons of the failure. Guess, most were bitter about Apple, but that's about it. They never realized that they failed to understand who their community was and how much it was important to support their community if they wanted their technology to live. They took the community for granted and tried to capitalize on popularity, but popularity disappeared because they took their community for granted.
> at least not until AIR came along and Flash expanded into the desktop world.
Sorry if it sounded arrogant. At the time I was developing a display application for hospitals (showing what is in each floor, etc. on screens), and our prototype was running 2 instances of it, and killing one and switching to the other to keep this memory leaks in check (horrible hack, I know). It was nothing too fancy, and it was still causing memory leaks when run for a long time.
I believe these were already the Air times.
Maybe it was not on each Flash player version. I found a couple here as an example:
I worked on a browser MMO game TimeZero. It used to be the second most popular game in Russia in early 2000's. Had about 5000 online users and ten times that much of active accounts. We had a lot of different problems with Flash player, but memory leaks weren't a thing.
Grant Skinner was a... popular person in Flash community... but, you also need to understand that Flash community, almost entirely, was amateur programmers. Looking back at those days, I feel the same kind of light embarrassment like when I thought I'd discovered some new fundamental theorem in algebra when I was in mid school only to later learn that it's something we'd learn about a year later.
So, what he discovered can be summed up as "works as intended". It's not a memory leak. His mistake was literally:
> function variables are transitory – they should only exist during execution of the function.
He's both confused between variables and values, and believes that common behavior is the only possible one. It's easy to make this mistake if you never work with entities like, eg. sockets or threads and similar system resources that have to be explicitly released by the program because the system that created them doesn't track their lifetime.
In other words, that's not a memory leak. A memory leak would be something like if BitmapData.dispose() didn't actually free memory.
I believe that the reason for this kind of behavior was that BitmapData would be also implicitly used by the player's own rendering layer which had to be explicitly instructed to remove it, if the program no longer needed it.
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.
> 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 would've solved 99% of what web components are trying to be.
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.
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.
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.
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.
>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.
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.
> 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?
> 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.
It is true in context. They will be faster than if they did not use a framework for anything that has even a tiny amount of repetition or interaction. That is why we have frameworks in the first place. There is no right way. React itself is not much of a framework anyway. It is a fairly small library for reactive UI. You do not need to be an expert to be productive in it.
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
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.
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.
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.
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.
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.
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).
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
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.