The definition of "stack" has changed over the years from a holistic technology view, to a developer centric view, it seems. When people said they were a "full stack developer", what that used to...
The definition of "stack" has changed over the years from a holistic technology view, to a developer centric view, it seems.
When people said they were a "full stack developer", what that used to mean was someone who was capable of administering actual server the software ran on, the web server runtime that serves it, the database that stored its data, and the actual code that produced the site. LAMP was the first thing coloqually known as a "stack" and only one component of it is a programming language. They were describing themselves as someone who had a very broad set of skills between systems administration, network engineering, database administration, and software development. It didn't mean they were just experienced with multiple web frameworks.
I think over time, we've stated calling frameworks "stacks", but those really only touch the very highest layers of abstraction.
It's not feasible at all to have a "stackless" site for virtually anyone. You're not going to build hardware, develop an OS from scratch, develop a database from scratch, and then finally write the site. Thus, you're running the site on something, and that's your stack.
I don't think the definition has changed, the author is just ignorant. I mean that in a literal rather than insulting way. OS/web server/server side language/javascript/HTML/CSS is definitely...
I don't think the definition has changed, the author is just ignorant. I mean that in a literal rather than insulting way. OS/web server/server side language/javascript/HTML/CSS is definitely still a stack.
I'm a little surprised that the author calls React a "legacy framework". We've been using it at my workplace for the last couple years, and its presence in our codebase is only going up as we try...
I'm a little surprised that the author calls React a "legacy framework". We've been using it at my workplace for the last couple years, and its presence in our codebase is only going up as we try to migrate away from (what I would call legacy) cshtml pages.
Yeah, I wouldn't call it a legacy framework at all. It's still being actively developed and is by far the most used web framework. The author also totally dismisses React as an option without...
Yeah, I wouldn't call it a legacy framework at all. It's still being actively developed and is by far the most used web framework.
The author also totally dismisses React as an option without providing any real justification or alternative solutions. The fact that they call out Facebook makes it feel more like a personal issue with Meta than actual technical advice.
I did not get that impression whatsoever. The rest of the post seems in earnest, and they called this out as their "only absolute advice", implying that they're pretty serious about it.
I did not get that impression whatsoever. The rest of the post seems in earnest, and they called this out as their "only absolute advice", implying that they're pretty serious about it.
It is 12 years since the initial release (according to Wikipedia) so I think there is a legitimate argument that it is legacy software. If you were writing react back then and are still using it...
It is 12 years since the initial release (according to Wikipedia) so I think there is a legitimate argument that it is legacy software. If you were writing react back then and are still using it then your software will likely look very different and have accumulated a bunch of legacy cruft over the years.
That's a pretty silly framing imo. If you define legacy as time between initial release and today, basically every bit of software is legacy. The legacy browser Chrome is 18 years old. And stay...
That's a pretty silly framing imo. If you define legacy as time between initial release and today, basically every bit of software is legacy. The legacy browser Chrome is 18 years old. And stay away from the legacy Firefox at 32 years old. The newest operating system, iOS, is legacy at 19 years old. The most used server operating system, Linux, is legacy at 35 years old.
Well, arguably Firefox and chrome are both legacy systems. There are a bunch of hidden quirks and obscure settings in Firefox at least dating back many years! Now, are legacy systems automatically...
Well, arguably Firefox and chrome are both legacy systems. There are a bunch of hidden quirks and obscure settings in Firefox at least dating back many years! Now, are legacy systems automatically bad? No, I don't think so. Are they harder to maintain than greenfield projects? Definitely!
Yes. If you are working on java I would argue you are working on a legacy system. If you are writing something new with java, then you would just be using a fairly solid and battle tested tool for...
Yes. If you are working on java I would argue you are working on a legacy system. If you are writing something new with java, then you would just be using a fairly solid and battle tested tool for solving your problem.
I believe you are talking about a legacy "codebase", not framework. Otherwise is Java legacy? Is C or C++ legacy? Is every modern video game legacy as it uses C in some shape or form? To me,...
I believe you are talking about a legacy "codebase", not framework.
Otherwise is Java legacy? Is C or C++ legacy? Is every modern video game legacy as it uses C in some shape or form?
To me, that's a misuse of the word legacy "framework". The framework is actively maintained and still a go-to for many. Once it ends up similar to Cobalt or perhaps a more modern example of say Ruby that has no expanding market share and is not chosen for new projects... Then you could call it a legacy framework.
Fair point! The age of the he framework (or language for that matter) doesn't automatically imply it is a legacy framework. In the case of react the framework itself has a bunch of "cruft" in it...
Fair point! The age of the he framework (or language for that matter) doesn't automatically imply it is a legacy framework. In the case of react the framework itself has a bunch of "cruft" in it though. It is kind of inevitable for all but the smallest codebases if they are continuously being developed.
All my web projects are/were small and hand-made. I imagine the appeal for “go-to stacks” are bigger on enterprise, but other than that I have a hard time understanding the advantages of them for...
All my web projects are/were small and hand-made. I imagine the appeal for “go-to stacks” are bigger on enterprise, but other than that I have a hard time understanding the advantages of them for the end-user.
Something I will always argue for- stacks get products out of the door quicker, at the expense of both the users and the maintainers. Everything I make and host personally requires only HTML5,...
Something I will always argue for- stacks get products out of the door quicker, at the expense of both the users and the maintainers.
Everything I make and host personally requires only HTML5, CSS, and vanilla JS. Tens of kilobytes, not multiple megabytes (unless serving large amounts of visual media, of course).
I’ll do the thing I usually do here, and blame this on the corporations. They are building web apps on stacks, and usually for good reason. So if you want to have a steady, well paying, and...
I’ll do the thing I usually do here, and blame this on the corporations. They are building web apps on stacks, and usually for good reason. So if you want to have a steady, well paying, and long-lasting job, you better know the past half dozen stacks du jour inside and out. Its always struck me as unreasonable that they will hire people who exclusively know their specific situation rather than spend a few weeks of training. I would imagine that will get you “stack smart” people who are great at answering questions about it but will eventually end up introducing a bunch of bugs because they don’t know the fundamentals or how those stacks actually work. But as someone who has never worked at one of these companies, this is pure conjecture.
I’ve also never really understood the value of tailwind and other CSS frameworks. Why bother learning a hundred classes when they are all just a few attributes you could just as easily learn directly? Class-spamming just serves to make HTML more difficult to read than it already is.
Because CSS is global by default and that makes thing very hard to reason about when you work on a component level. That doesn't even have to involve react, or the new WebComponents API, it...
Why bother learning a hundred classes when they are all just a few attributes you could just as easily learn directly?
Because CSS is global by default and that makes thing very hard to reason about when you work on a component level. That doesn't even have to involve react, or the new WebComponents API, it applies to just having buttons in a templated HTML sent by the server.
With vanilla CSS, it's ultimately incredibly difficult to tell what anything would look like without actually rendering it. Any HTML element will be under the jurisdiction of hundreds of layers of CSS that override each other. Every parent element can override its parent elements CSS.
With tailwind, the idea is that every element's CSS is scoped to the "thing" that produces it. You have a function in your django python app that returns a button HTML template - if you want to change how that button looks, you know where to go, that method. If you want to make every button look different, you still know where to go.
Frankly that all strikes me as something someone who doesn’t understand the overarching logic of CSS. “Global by default” is arguably mischaracterization of CSS selectors. Literally the first...
Frankly that all strikes me as something someone who doesn’t understand the overarching logic of CSS. “Global by default” is arguably mischaracterization of CSS selectors. Literally the first thing I learned when I started CSS is to add a class to an element to style it specifically, and that is exactly what tailwind is doing, no? Dev tools have made dealing with scope creep issues very easy for decades now because they can tell us exactly which file and line the problem is in.
Tailwind also doesn’t solve the problem of not knowing what a given rule will look like until rendered. You can get an idea of it with enough experience, but the same is true of vanilla CSS.
No, it's the opposite, it's understanding that like vanilla JS, CSS was made in a world where websites were less than what they were today. Yes and no. Tailscale in the end is just a collection of...
something someone who doesn’t understand the overarching logic of CSS.
No, it's the opposite, it's understanding that like vanilla JS, CSS was made in a world where websites were less than what they were today.
that is exactly what tailwind is doing, no?
Yes and no. Tailscale in the end is just a collection of utility classes, so you can think of it like that, but the existence of the utility classes changes how you'd do styling.
For example, if you wanted a blue centered button, the classic way would be to make a "blue button" class, that has the properties of being a particular hue and centered.
The tailwind-centered way would be to use the centered and "bg-sky-500/70" class. The difference is that the styling of the button is tightly scoped to the code that defines the HTML structure of the button. You know when you change that to bg-sky-700/70 that it will only change the HTML returned there. You could, of course, make these yourself, but making thousands of permutations of every color is not something that people are reasonably going to do.
Is it wasteful? Not really. The post-processing omits any classes you didn't use, and in practice the amount of CSS you send to the end user will be the same.
That frankly doesn’t even make sense. Both JS and CSS have made some very dramatic changes since they first came out. The use of utility classes in the way you describe also has some pretty...
No, it's the opposite, it's understanding that like vanilla JS, CSS was made in a world where websites were less than what they were today.
That frankly doesn’t even make sense. Both JS and CSS have made some very dramatic changes since they first came out.
The use of utility classes in the way you describe also has some pretty obvious downsides to me. If you have a website with 500 blue buttons strewn across it and a designer decides they should actually be burnt sienna, you now have to search for every single instance of those blue buttons and change them manually. If you wrote your own class you would simply change a single line and be done with it.
It’s usually combined with some kind of JavaScript component (such as React widgets), so in the source code, the duplication is removed in a different way.
It’s usually combined with some kind of JavaScript component (such as React widgets), so in the source code, the duplication is removed in a different way.
It's a feature, not a bug. HTML and CSS were originally made for static documents. And in that context, tailwind is not a good solution. If you're handwriting all of your HTML, it is convenient to...
It's a feature, not a bug. HTML and CSS were originally made for static documents. And in that context, tailwind is not a good solution. If you're handwriting all of your HTML, it is convenient to be able to change the CSS to change everything at once.
Tailwind is for dynamic websites, whether that be client-side like React or server-side like good ol' Django or Flask + mako or whatever. Let's take Django as the example.
If you wanted every blue button to look the same, you would define that in the application. Your server code would have a function that takes in a label and returns the HTML shell with the label inside. To change the color of every button, you would just change that function.
And that's a benefit, because you know that 100% of the button is defined by that function. There's no hidden global CSS you also need to update. There wouldn't be 500 blue buttons strewn about - every inch of a Django website is spawned by a function that renders an HTML template.
...i'm old and my beard's pretty grey so my interactivity sensibilities lean vanilla, but i've never used more than a basic text editor, image editor, and FTP...
...i'm old and my beard's pretty grey so my interactivity sensibilities lean vanilla, but i've never used more than a basic text editor, image editor, and FTP...
Eh, I like react and I'll keep using it :) I build small apps at work (typical "we need an interface for tracking data" sort of thing, tables, forms, reports, etc.). React is great for this. I'm...
Eh, I like react and I'll keep using it :)
I build small apps at work (typical "we need an interface for tracking data" sort of thing, tables, forms, reports, etc.). React is great for this. I'm working on a site right now, it can dynamically load data without page refresh, it supports Excel data exports, has all sorts of merge/filter features, supports login via MS Entra. The frontend project has 5 packages it depends on, really just react, react router, and some Azure MSAL libraries. The whole build, uncompressed, is just over 800KB. Compressed, it comes down to 200KB. I don't think it's fair to call that "bloated". Obviously it's a small project, but if you're smart with bigger projects and are chunking accordingly, you can make sure users don't ever have to download more than 200KB at a time. Maybe if you're on 3G, my site will take an extra minute to load, but this is a site with under 10 users all accessing from an office, so who cares if they have to download 200KB, they won't even notice. It's also a 1 time download that can be cached. Don't get me wrong, 10 years ago react was a bloated mess, but it's become so much better over the years.
I just don't get the NPM hate nowadays. Yes, there are security concerns that I don't take lightly, as is obvious from the recent axios attack, but there are practices to follow to ensure you are unlikely to fall victim to such an attack. The most obvious being: pinning your dependencies to specific version numbers, avoiding dependencies from untrusted third parties, and auditing the dependencies you do use. And of course there are real benefits to using a framework like react, the biggest being code maintainability. And you can say: well code maintainability benefits the developer, not the end user. But easier to maintain code > less bugs > faster feature development > end user saves money (at least that's the theory, of course in practice other organizational issues can stand in the way).
True enough, I tend to work on the "friendly view of database content" side of things. But usually these small businesses have slightly different needs despite the similarities.
True enough, I tend to work on the "friendly view of database content" side of things. But usually these small businesses have slightly different needs despite the similarities.
Seems like this is an argument against full-featured webapps. Static HTML documents with CSS and JS are great. You can create really beautiful, fast, dynamic sites with modern native JS APIs and...
Seems like this is an argument against full-featured webapps.
Static HTML documents with CSS and JS are great. You can create really beautiful, fast, dynamic sites with modern native JS APIs and CSS techniques. I'm not pooh-poohing that choice at all! But if your project calls for a complex, stateful SPA with a mature design system and robust data handling, I'd argue that the basics aren't going to get you there. That's what React is for. It's not for pages or sites, it's for applications. Not every project is going to have those requirements — most really won't — but for those that do we shouldn't be so quick to dismiss it. Unless you've got a worthy successor in mind that solves the same problems as React, I don't think you should label it "legacy" or say that there's never a use for it.
I think I'm nitpicking when I really largely agree with the post, I just took issue with the wholesale rejection of React being labeled "my only absolute advice" so quickly after pointing out that stacks are fine when they suit the project.
On an unrelated note, I love the retro W3C-style badges in the site footer!
I love this and strive to often build the same way or at least adjacent to it. I rarely have a "stack" but I also have sometimes used CSS frameworks though increasingly find them unnecessary for...
I love this and strive to often build the same way or at least adjacent to it. I rarely have a "stack" but I also have sometimes used CSS frameworks though increasingly find them unnecessary for my own small projects- I was just using them as a shortcut for speed.
That said, I am not in a position where I am required to use stacks for a job or anything so it's easy for me to eschew it all. I abandoned web dev as a pursuit even after doing some focus on it in college in the early-mid 2000s because I just lost all desire to do it with the "application" direction it was going and the speed at which it was doing so.
Honestly, though I am sure there are cool things I wouldn't be able to do on websites without SPAs and the modern web, I almost wish we never went that far. I sometimes, whether rationally or not, long for a world where the web was still just mostly HTML and CSS. So I build for that world and for keeping a lot of that alive.
I think this blog post was level-headed enough- they aren't even saying to never use stacks but to understand the problems you're solving and if you're using the right tool for the job and I think that's fair because stacks and frameworks often become shortcuts rather than reasoned-through solutions and you could be introducing a ton of unnecessary downsides into what you're building
I think there is this "tool-ism" (in this case stack-ism) or adherence to a way of doing things that becomes a (subconscious?) cultural assumption or expectation and it's good to hear voices countering that from time to time
I tried to do something similar, I even wrote a no-config static site generator that takes a directory full of Markdown files and outputs a website, with optional templating. But at the end, I...
I tried to do something similar, I even wrote a no-config static site generator that takes a directory full of Markdown files and outputs a website, with optional templating. But at the end, I think running your website as a server that can handle tasks in the background, gives you more liberty to experiment in the future.
I still kept the stack small. Right now I'm only using Wagtail, HTMX and a Markdown editor, but I'm planning on adding TailwindCSS in the future.
I’m a bit out of my depth here since I don’t know how to code, and so I guess my stack is entirely Google Workspace and having an LLM write what I explain to it in English for Google App Script....
I’m a bit out of my depth here since I don’t know how to code, and so I guess my stack is entirely Google Workspace and having an LLM write what I explain to it in English for Google App Script. Which means spaghetti sheets doing all sorts of things linked up to each other and integrated with Gmail, AppSheet and an API or two. If I had a larger business, I suppose these practises would fall apart at a larger scale. But it works and I can still manage to fix any bugs that pop up.
On the one hand I don’t need to maintain a backend, on the other hand I’m pretty much locked in.
You're not really locked in. If you hired someone to manage it in a different way they'd probably either copy the front end or rewrite the whole thing.
You're not really locked in. If you hired someone to manage it in a different way they'd probably either copy the front end or rewrite the whole thing.
I do at least agree with this author that NextJS is a hot mess. I suspect it's been ruined by Vercel engineers' desires to get promoted. 4-5 years ago I felt like I understood what NextJS did and...
I do at least agree with this author that NextJS is a hot mess. I suspect it's been ruined by Vercel engineers' desires to get promoted. 4-5 years ago I felt like I understood what NextJS did and how to use it. These days they've changed everything around so many times, we have server components, client components (indicated with "use server"; and "use client;"??? someone needs to go to prison for this). You can run server-side code in your components (what even is the lifecycle of a component now?). You can call server-side code from your components and it will build a "transparent" (except doing this perfectly is not possible) API client at build time which will make it look like everything is magically unified, even though I disagree that is a good goal in the first place. If you want SSR you can't use useEffect anymore unless you hack through a dynamic import with a fallback? I thought the whole point with NextJS was that you SSR and then rehydrate and get the best of both worlds (except correct hydration has no static analyzer so you get all of these subtle bugs).
I have spent some time with these newer versions of Next professionally and I don't feel like learning all of this new complexity to the point where I understand it is worth my time. Because I don't think anyone at Vercel really understands the direction they're headed in. They need to start removing things. They have two different router implementations with slightly different feature sets. Just pick one! Remove the old one - or the new one I don't give a fuck.
The last app I built from scratch, which I started a few months ago, does not use React or Next at all. It uses fastify and SSRs JSX, but using JSX purely as a string templating system so that you can get all of the benefits of TypeScript in your templates. Front-end JS is JSDoc-annotated (for TypeScript) .mjs files that can import each other. There are 0 lines of npm code on the front end.
The definition of "stack" has changed over the years from a holistic technology view, to a developer centric view, it seems.
When people said they were a "full stack developer", what that used to mean was someone who was capable of administering actual server the software ran on, the web server runtime that serves it, the database that stored its data, and the actual code that produced the site. LAMP was the first thing coloqually known as a "stack" and only one component of it is a programming language. They were describing themselves as someone who had a very broad set of skills between systems administration, network engineering, database administration, and software development. It didn't mean they were just experienced with multiple web frameworks.
I think over time, we've stated calling frameworks "stacks", but those really only touch the very highest layers of abstraction.
It's not feasible at all to have a "stackless" site for virtually anyone. You're not going to build hardware, develop an OS from scratch, develop a database from scratch, and then finally write the site. Thus, you're running the site on something, and that's your stack.
I don't think the definition has changed, the author is just ignorant. I mean that in a literal rather than insulting way. OS/web server/server side language/javascript/HTML/CSS is definitely still a stack.
I'm a little surprised that the author calls React a "legacy framework". We've been using it at my workplace for the last couple years, and its presence in our codebase is only going up as we try to migrate away from (what I would call legacy) cshtml pages.
Yeah, I wouldn't call it a legacy framework at all. It's still being actively developed and is by far the most used web framework.
The author also totally dismisses React as an option without providing any real justification or alternative solutions. The fact that they call out Facebook makes it feel more like a personal issue with Meta than actual technical advice.
I think they were just trying to be facetious, guys.
I did not get that impression whatsoever. The rest of the post seems in earnest, and they called this out as their "only absolute advice", implying that they're pretty serious about it.
It is 12 years since the initial release (according to Wikipedia) so I think there is a legitimate argument that it is legacy software. If you were writing react back then and are still using it then your software will likely look very different and have accumulated a bunch of legacy cruft over the years.
That's a pretty silly framing imo. If you define legacy as time between initial release and today, basically every bit of software is legacy. The legacy browser Chrome is 18 years old. And stay away from the legacy Firefox at 32 years old. The newest operating system, iOS, is legacy at 19 years old. The most used server operating system, Linux, is legacy at 35 years old.
Well, arguably Firefox and chrome are both legacy systems. There are a bunch of hidden quirks and obscure settings in Firefox at least dating back many years! Now, are legacy systems automatically bad? No, I don't think so. Are they harder to maintain than greenfield projects? Definitely!
By that definition, Java would be legacy software. I think it's more accurate to say some legacy software is written in React.
Yes. If you are working on java I would argue you are working on a legacy system. If you are writing something new with java, then you would just be using a fairly solid and battle tested tool for solving your problem.
I believe you are talking about a legacy "codebase", not framework.
Otherwise is Java legacy? Is C or C++ legacy? Is every modern video game legacy as it uses C in some shape or form?
To me, that's a misuse of the word legacy "framework". The framework is actively maintained and still a go-to for many. Once it ends up similar to Cobalt or perhaps a more modern example of say Ruby that has no expanding market share and is not chosen for new projects... Then you could call it a legacy framework.
Fair point! The age of the he framework (or language for that matter) doesn't automatically imply it is a legacy framework. In the case of react the framework itself has a bunch of "cruft" in it though. It is kind of inevitable for all but the smallest codebases if they are continuously being developed.
All my web projects are/were small and hand-made. I imagine the appeal for “go-to stacks” are bigger on enterprise, but other than that I have a hard time understanding the advantages of them for the end-user.
Something I will always argue for- stacks get products out of the door quicker, at the expense of both the users and the maintainers.
Everything I make and host personally requires only HTML5, CSS, and vanilla JS. Tens of kilobytes, not multiple megabytes (unless serving large amounts of visual media, of course).
I’ll do the thing I usually do here, and blame this on the corporations. They are building web apps on stacks, and usually for good reason. So if you want to have a steady, well paying, and long-lasting job, you better know the past half dozen stacks du jour inside and out. Its always struck me as unreasonable that they will hire people who exclusively know their specific situation rather than spend a few weeks of training. I would imagine that will get you “stack smart” people who are great at answering questions about it but will eventually end up introducing a bunch of bugs because they don’t know the fundamentals or how those stacks actually work. But as someone who has never worked at one of these companies, this is pure conjecture.
I’ve also never really understood the value of tailwind and other CSS frameworks. Why bother learning a hundred classes when they are all just a few attributes you could just as easily learn directly? Class-spamming just serves to make HTML more difficult to read than it already is.
Because CSS is global by default and that makes thing very hard to reason about when you work on a component level. That doesn't even have to involve react, or the new WebComponents API, it applies to just having buttons in a templated HTML sent by the server.
With vanilla CSS, it's ultimately incredibly difficult to tell what anything would look like without actually rendering it. Any HTML element will be under the jurisdiction of hundreds of layers of CSS that override each other. Every parent element can override its parent elements CSS.
With tailwind, the idea is that every element's CSS is scoped to the "thing" that produces it. You have a function in your django python app that returns a button HTML template - if you want to change how that button looks, you know where to go, that method. If you want to make every button look different, you still know where to go.
Frankly that all strikes me as something someone who doesn’t understand the overarching logic of CSS. “Global by default” is arguably mischaracterization of CSS selectors. Literally the first thing I learned when I started CSS is to add a class to an element to style it specifically, and that is exactly what tailwind is doing, no? Dev tools have made dealing with scope creep issues very easy for decades now because they can tell us exactly which file and line the problem is in.
Tailwind also doesn’t solve the problem of not knowing what a given rule will look like until rendered. You can get an idea of it with enough experience, but the same is true of vanilla CSS.
No, it's the opposite, it's understanding that like vanilla JS, CSS was made in a world where websites were less than what they were today.
Yes and no. Tailscale in the end is just a collection of utility classes, so you can think of it like that, but the existence of the utility classes changes how you'd do styling.
For example, if you wanted a blue centered button, the classic way would be to make a "blue button" class, that has the properties of being a particular hue and centered.
The tailwind-centered way would be to use the centered and "bg-sky-500/70" class. The difference is that the styling of the button is tightly scoped to the code that defines the HTML structure of the button. You know when you change that to bg-sky-700/70 that it will only change the HTML returned there. You could, of course, make these yourself, but making thousands of permutations of every color is not something that people are reasonably going to do.
Is it wasteful? Not really. The post-processing omits any classes you didn't use, and in practice the amount of CSS you send to the end user will be the same.
That frankly doesn’t even make sense. Both JS and CSS have made some very dramatic changes since they first came out.
The use of utility classes in the way you describe also has some pretty obvious downsides to me. If you have a website with 500 blue buttons strewn across it and a designer decides they should actually be burnt sienna, you now have to search for every single instance of those blue buttons and change them manually. If you wrote your own class you would simply change a single line and be done with it.
It’s usually combined with some kind of JavaScript component (such as React widgets), so in the source code, the duplication is removed in a different way.
That makes sense.
It's a feature, not a bug. HTML and CSS were originally made for static documents. And in that context, tailwind is not a good solution. If you're handwriting all of your HTML, it is convenient to be able to change the CSS to change everything at once.
Tailwind is for dynamic websites, whether that be client-side like React or server-side like good ol' Django or Flask + mako or whatever. Let's take Django as the example.
If you wanted every blue button to look the same, you would define that in the application. Your server code would have a function that takes in a label and returns the HTML shell with the label inside. To change the color of every button, you would just change that function.
And that's a benefit, because you know that 100% of the button is defined by that function. There's no hidden global CSS you also need to update. There wouldn't be 500 blue buttons strewn about - every inch of a Django website is spawned by a function that renders an HTML template.
This is how desktop GUI frameworks work as well.
...i'm old and my beard's pretty grey so my interactivity sensibilities lean vanilla, but i've never used more than a basic text editor, image editor, and FTP...
Eh, I like react and I'll keep using it :)
I build small apps at work (typical "we need an interface for tracking data" sort of thing, tables, forms, reports, etc.). React is great for this. I'm working on a site right now, it can dynamically load data without page refresh, it supports Excel data exports, has all sorts of merge/filter features, supports login via MS Entra. The frontend project has 5 packages it depends on, really just react, react router, and some Azure MSAL libraries. The whole build, uncompressed, is just over 800KB. Compressed, it comes down to 200KB. I don't think it's fair to call that "bloated". Obviously it's a small project, but if you're smart with bigger projects and are chunking accordingly, you can make sure users don't ever have to download more than 200KB at a time. Maybe if you're on 3G, my site will take an extra minute to load, but this is a site with under 10 users all accessing from an office, so who cares if they have to download 200KB, they won't even notice. It's also a 1 time download that can be cached. Don't get me wrong, 10 years ago react was a bloated mess, but it's become so much better over the years.
I just don't get the NPM hate nowadays. Yes, there are security concerns that I don't take lightly, as is obvious from the recent axios attack, but there are practices to follow to ensure you are unlikely to fall victim to such an attack. The most obvious being: pinning your dependencies to specific version numbers, avoiding dependencies from untrusted third parties, and auditing the dependencies you do use. And of course there are real benefits to using a framework like react, the biggest being code maintainability. And you can say: well code maintainability benefits the developer, not the end user. But easier to maintain code > less bugs > faster feature development > end user saves money (at least that's the theory, of course in practice other organizational issues can stand in the way).
I feel like more business websites are either a bunch of photos and marketing-speak or a (hopefully) user friendly view of database content.
True enough, I tend to work on the "friendly view of database content" side of things. But usually these small businesses have slightly different needs despite the similarities.
Seems like this is an argument against full-featured webapps.
Static HTML documents with CSS and JS are great. You can create really beautiful, fast, dynamic sites with modern native JS APIs and CSS techniques. I'm not pooh-poohing that choice at all! But if your project calls for a complex, stateful SPA with a mature design system and robust data handling, I'd argue that the basics aren't going to get you there. That's what React is for. It's not for pages or sites, it's for applications. Not every project is going to have those requirements — most really won't — but for those that do we shouldn't be so quick to dismiss it. Unless you've got a worthy successor in mind that solves the same problems as React, I don't think you should label it "legacy" or say that there's never a use for it.
I think I'm nitpicking when I really largely agree with the post, I just took issue with the wholesale rejection of React being labeled "my only absolute advice" so quickly after pointing out that stacks are fine when they suit the project.
On an unrelated note, I love the retro W3C-style badges in the site footer!
I love this and strive to often build the same way or at least adjacent to it. I rarely have a "stack" but I also have sometimes used CSS frameworks though increasingly find them unnecessary for my own small projects- I was just using them as a shortcut for speed.
That said, I am not in a position where I am required to use stacks for a job or anything so it's easy for me to eschew it all. I abandoned web dev as a pursuit even after doing some focus on it in college in the early-mid 2000s because I just lost all desire to do it with the "application" direction it was going and the speed at which it was doing so.
Honestly, though I am sure there are cool things I wouldn't be able to do on websites without SPAs and the modern web, I almost wish we never went that far. I sometimes, whether rationally or not, long for a world where the web was still just mostly HTML and CSS. So I build for that world and for keeping a lot of that alive.
I think this blog post was level-headed enough- they aren't even saying to never use stacks but to understand the problems you're solving and if you're using the right tool for the job and I think that's fair because stacks and frameworks often become shortcuts rather than reasoned-through solutions and you could be introducing a ton of unnecessary downsides into what you're building
I think there is this "tool-ism" (in this case stack-ism) or adherence to a way of doing things that becomes a (subconscious?) cultural assumption or expectation and it's good to hear voices countering that from time to time
I tried to do something similar, I even wrote a no-config static site generator that takes a directory full of Markdown files and outputs a website, with optional templating. But at the end, I think running your website as a server that can handle tasks in the background, gives you more liberty to experiment in the future.
I still kept the stack small. Right now I'm only using Wagtail, HTMX and a Markdown editor, but I'm planning on adding TailwindCSS in the future.
I’m a bit out of my depth here since I don’t know how to code, and so I guess my stack is entirely Google Workspace and having an LLM write what I explain to it in English for Google App Script. Which means spaghetti sheets doing all sorts of things linked up to each other and integrated with Gmail, AppSheet and an API or two. If I had a larger business, I suppose these practises would fall apart at a larger scale. But it works and I can still manage to fix any bugs that pop up.
On the one hand I don’t need to maintain a backend, on the other hand I’m pretty much locked in.
You're not really locked in. If you hired someone to manage it in a different way they'd probably either copy the front end or rewrite the whole thing.
I do at least agree with this author that NextJS is a hot mess. I suspect it's been ruined by Vercel engineers' desires to get promoted. 4-5 years ago I felt like I understood what NextJS did and how to use it. These days they've changed everything around so many times, we have server components, client components (indicated with
"use server";and"use client;"??? someone needs to go to prison for this). You can run server-side code in your components (what even is the lifecycle of a component now?). You can call server-side code from your components and it will build a "transparent" (except doing this perfectly is not possible) API client at build time which will make it look like everything is magically unified, even though I disagree that is a good goal in the first place. If you want SSR you can't useuseEffectanymore unless you hack through a dynamic import with a fallback? I thought the whole point with NextJS was that you SSR and then rehydrate and get the best of both worlds (except correct hydration has no static analyzer so you get all of these subtle bugs).I have spent some time with these newer versions of Next professionally and I don't feel like learning all of this new complexity to the point where I understand it is worth my time. Because I don't think anyone at Vercel really understands the direction they're headed in. They need to start removing things. They have two different router implementations with slightly different feature sets. Just pick one! Remove the old one - or the new one I don't give a fuck.
The last app I built from scratch, which I started a few months ago, does not use React or Next at all. It uses fastify and SSRs JSX, but using JSX purely as a string templating system so that you can get all of the benefits of TypeScript in your templates. Front-end JS is JSDoc-annotated (for TypeScript) .mjs files that can import each other. There are 0 lines of npm code on the front end.