A Rant about Front-end Development
blog.frankmtaylor.com
blog.frankmtaylor.com
I would love to see a list of projects that do less of the front-end garbage. Someone mentioned the levels.io guy. I also like HTMX. Personally, I've seen great success using 95% server-side rendered sites with 5% Alpine JS sprinkled on top.
Do you have open source project with the 5%/95% ?
Not yet. I just use Alpine for form validation (with the awesome mask plugin), checkbox dropdowns, dialogs/modals, and toast notifications. Everything else is Go HTML templates.
I wish there was a way to do custom builds of Alpine and just include what I need, but it probably wouldn't be too hard to do it in vanilla JS.
The vast majority of websites out there probably don’t even need JS.
So actually not "100% server side rendering" at all. And probably paying all the costs of using JS more extensively, but gaining fewer of the benefits.
JS doesn’t render anything. If you turn it off the page is served anyway, some minor things might not work.
servers always send 100% of what they send.
is what is sent 100% rendered already? well, browsers do a fair amount of rendering, that's what they do with CSS and HTML. and then you're adding on JS. we differ in the language we use to describe what is happening.
perhaps you've rendered something from a database wrangled into the 100% page that gets sent, it's just not done rendering yet.
But I suspect that’s a pointless definition.
Yes you send a full, html page over the wire. It will render. script off. You can enhance it later.. You know a basic is this an email, is the pass word not empty check for a log in or some other fields if you have a basic contact form.
The web worked before all the JS frameworks... It still works that way today. It's fast, low bandwidth and easy to cache.
https://developer.mozilla.org/en-US/docs/Web/HTML/Constraint...
I love having deployment be "drop a folder of static files onto a server".
Also scaling out SPAs is a non-issue. Servers have basically unlimited throughput for delivering static files, assuming you don't inline any 24MB uncompressed images. Or just throw it on Cloudflare, whatever, again, it is just static files.
Just like your SPA, you have no server to look after, (eg) Cloudflare builds it all, hosts it all and there's no JS overhead for clients, no SEO hassle, etc, etc.
Which makes Astro the wrong tool for the job, and SPA frameworks like Svelte the right tool for the job.
Doing these things server side makes no sense, it'd just make everything harder for me to debug!
But many enthusiastic young developers start using a framework and decide to do everything with it. Same was true on server dynamic frameworks. Everyone's first project is technologically-inappropriate blog. These sites would be objectively better as SSG sites.
Btw, Astro is surprisingly excellent at using frontend components from multiple frameworks, even in the same project. If your interactivity is in-page, or you have a mixed MPA-SPA domain, it's well worth a look.
Even the DX, I prefer it to Next/Next projects where you're chained to a set of dev dependencies from the start. My last Nuxt upgrade took three weeks to unhook various deep integrations and fix things (Vue 2 to 3 too). Nightmare.
Highly interactive experiences are complex to manage full refreshes with, is it do-able? Sure. It is something I want to bother with for a project I work on 1hr a day after work? Not really!
> Everyone's first project is technologically-inappropriate blog. These sites would be objectively better as SSG sites.
I am amazed that Wordpress became the behemoth that it is for personal blogs, given that 99.99% of them would work well as statically generated pages.
Honestly the move towards SSG that then embed some discussion component seems like the best combo for most small and medium use cases.
When these companies use some marketing slogan like "Make the web faster" it is quite amusing. Ads are what slows it down and dissemination of ads is their "business model".
Parasites.
Introducing SSR and data handling on the server side to an app can be much less productive if you don’t need the performance improvements that SSR brings.
Render where the state lives. If a piece of state is stored on the server, and the server will have to be notified when it changes, rendee HTML there. For any part of the UI that really is temporary state that only lives in the client, just render that piece (or changes to that piece) in the browser and leave the server out of it.
An all or nothing solution is rarely the right answer.
A website, just like any other application, exists to solve a problem. The right ratio of hassle/efficacy/reliability definitely isn't the same for every application, and often not even the same among different user groups. What developers consider to be a hassle or too complicated is dramatically different from most other groups. Doctors and children and mechanics and mechanical engineers and artists have more in common with the way they interact with software than any of those groups do with software developers. If you have a working mental model of what's happening behind each click, your perspective is totally different.
To a developer seeing a form submit and waiting for a return is a set of actions with a story behind it. We know what's happening. To a typical user, it's a period of flickering and flashing and waiting after they clicked on a button. There's no meaning to it-- they just compare the action of button A which changes screen state instantly, to button B which seemingly dicks around for a while until something happens. What about on slow connections or devices? It depends on what problem you're solving. If you serving up nearly static content, using an SPA is absurd. If you're doing something interactive, it's way worse to have constant reloads than use a -----properly designed----- SPA that loads once, uses local storage efficiently, and only makes small API calls to the server once its loaded. If an SPA has poor architecture or is a bad solution for the problem, the problem is the developer that made those decisions, not SPAs.
A 500% reduction in technical complexity is meaningless to most end users. If it comes at the expense of having to look at a page reload in between frequent operations, it's a big annoyance. Sure, I'd much rather put together a nice clean static site than do something dynamic, but what the hell is the point if it's not the best way for users to solve the problem they need it to solve?
Beyond that, I guarantee you there are many sites that 'just work' the way you'd expect a website to work and you'd have no idea they were SPAs. Making a proper SPA requires a lot more technical design and expertise than making a traditional site, and using a poorly made SPA is a WAY worse experience than using a poorly made static site. That makes it really easy to notice when one is bad, so it makes SPAs seem bad, generally, which is just not true.
For the same reason we can't leave all technical decisions up to designers, we can't leave all interaction decisions to developers. Obviously it will make development a lot easier and smoother if we do, but that's one of many factors, and quite often not the most important one.
I never had problems with performance. React is less than 150kb, and as the backend is not a bottleneck, the website feels very snappy.
SSR is not enough if you want an interactive page, you'll need some JS. If you do, instead of dealing with a ton of scattered JS scripts, I'd rather have a single React/whatever application.
SSR does this as well. The server serves data (HTML), the client (web browser) renders it.
A bonus "feature" of this, and a very important one, is that this now also requires different specializations on your team and the personnel costs and communication overhead that comes with that. Great, now adding simple CRUD functionality to a website is a two week project syncing between backenders and frontenders, for something that someone wanting to scratch their own itch could hammer out independently in a single day back in the SSR days.
Your argument suggests that SSR requires only one type of specialization, but that's not entirely accurate. SSR developers still need full-stack knowledge, since they must write HTML, CSS, and JavaScript alongside the backend code. This means their expertise already needs to cover multiple areas and languages. While it’s true that frontend frameworks introduce additional build tooling, developers today are generally familiar with this ecosystem. The backend developers I work with do have a good understanding of React and can work with it comfortably, and I have seen junior developers picking it up within a week or two. They don't need to be specialists in order to be productive.
Yes, it is true that many backends are tailor-made for a frontend, but going exclusively HTML-first will lock you into this state, unless you are OK with revisiting it to add a JSON API later to support additional use cases. When I write an application, it usually comes with a CLI in case I need to use it from a server without access to a UI, and I hook it up with tools for integration tests using its JSON API. It's also common to see frontends that are powered by multiple backends, and in these cases, it makes sense to have a separate frontend application that uses APIs.
So yes, it does make perfect sense for me to have a layer between presentation and application.
edit: fixed a typo
What makes you think this is confined to large companies? And even large companies have small teams.
> SSR developers still need full-stack knowledge, since they must write HTML, CSS, and JavaScript alongside the backend code
It's true, but it's a smaller scope, better & more stable documentation, and overall a smaller threshold to get going to add a form in passing to a SSR than getting going with a new ecosystem.
> unless you are OK with revisiting it to add a JSON API later to support additional use cases.
Adding another output format to an existing product is not a scary problem and usually not even a time consuming one, and best of all you can wait until it's actually needed. This includes endpoints for a CLI. Now the aren't shared either, so the HTML output can be adapted according to the needs of the website along its lifetime, and the debug endpoints' JSON output can be adapted according to the needs of the CLI along its lifetime.
Adding another output format to an existing product is not a scary problem and usually not even a time consuming one, and best of all you can wait until it's actually needed.
> I could say the same about my experience with UI frameworks. It's not a scary problem, it's not particularly time-consuming
SPA UI frameworks are not particularly time-consuming? Then we have very different views on productivity.
Being "proactive" is not rational if you're paying a higher price each day in additional complexity to possibly, maybe, avoid having to small cost later. When and if you get there you've already paid 100x the cost compared to just taking the one-time cost when it actually arrived.
Being "proactive" is not rational if you're paying a higher price each day in additional complexity to possibly, maybe, avoid having to small cost later. When and if you get there you've already paid 100x the cost compared to just taking the one-time cost when it actually arrived.
Apps and websites are fundamentally different so no. Apps are by definition highly dynamic, while websites start out as static documents that some people put too much macros into to make them appear like (bad) apps.
We waited so long to improve semantic HTML that ML rushed ahead and will probably deliver semantic comprehension far in excess of whatever we can hope for with conventional means now.
Consider the tool the author mentioned, jQuery. It is on the text almost as a museum piece.
The things jQuery did (compatibility, CSS selectors, fetch) became standards or stable almost a decade ago. We don't need a 2024 version of jQuery, what that tool did we can now do vanilla.
And that's about it. Perhaps React would be useful for a large project, with lots of complexity to manage, and assuming that people involved have experience in using it to manage such complexity.
On the other hand, that React project that contains only some forms and page navigation could totally be <form and <a with some small vanilla JS snippets.
For example, I’m terrible at front end, and design. Tailwind has a React library that handles many of the UI requirements and produces a decent-looking front end with minimal effort. I know enough React that the complexity doesn’t scare me, and there’s so much documentation and training available that it’s easy to find answers. It integrates easily with other frameworks. I can reuse components I built for other projects.
React is often not the optimal choice for the project, but can yet still be the right choice.
There are many pure CSS libraries out there that meet varying degrees of UX requirements. Form controls, typography, layout, everything.
MDN has a complete documentation with complete browser support, examples, reference. It's awesome.
On React world, I often have issues with community components. I needed a dynamic table in my last job, there was simply none. You had to pay for a premium component, or use a code that barely passes 3min auditing (material-table-core). It was a nightmare.
A dynamic table qualifies as something I'd rather have a framework do for me. Jesus, YUI did that for free 15 years ago (with tests, with cross browser, with rendering and painting considerations...). However, we ended up rewriting significant portions of the original component we chose (all data handling, all export and import, all menu, all cell rendering, all style).
When people argue about whether React is right for a project, they are often trying to optimise for different non-functional requirements. Those against might be considering performance, filesize, and complexity. Those in favour may be optimising maintainability, reusability (with other projects), ease of hiring and onboarding new people. So they can both be right, and what they need to work out is which NFRs matter the most.
"And sure, maybe you don’t need jQuery, and that’s fine. Will you need more lines of code to do the same thing? Of course. But even without jQuery, your complexity doesn’t grow exponentially like it would if you brought in a framework with its build system, linters, compilers, and 700mb of Node Modules ..."
It's a community site, with lots of user generated content and interactivity, but nearly every page is rendered on the server.
There are bits that need to respond and re-layout the page on the fly (like https://bettybeta.com/bouldering/projects ), that get just enough Vue to be able to do so. But they really are Pages, which means that you don't need to download and process 14mb of javascript to look at the homepage or any content page you might land on from Google.
Roughly 100% of consumer-facing websites can be built like this.
I built something with it once. I wonder if it’s still in use.
But I used to write front end applications with MFC (Microsoft Foundation Classes, which is C++) using Visual Studio circa 2005, and it was never as complex as an SPA today. There is something wrong somewhere, and I don't think it's JavaScript or the DOM. The flaw seems to be paradigmatic.
You can still design websites like it's 2005, and they'll be damn fast. But pitch something like MFC or even PHP to a 20-something frontend developer now and watch the blood drain from their face.
It make seem trite but you just aren't going to have a good time building some of the stuff people build now using a LAMP stack
Different people work on different projects serving different needs and we have to acknowledge that otherwise we end up in these silly tech-religious arguments where people think there's one and only one way to do things and that's certianly not the case.
React is a Face Book abstraction leaking out on to the web.
It's good for them. It's a perfect framework (+ graphQL) for there every page is custom in a walled garden environment.
It isnt a good way to build a blog, or a shopping cart. But A mail client in a browser, or a B2B app with a lot of data, A CMS... great places for it!
And it's great for FB too. (as is every other open source tech from a large player). Think about all the money FB saves NOT having to ramp up front end engineers... they get them pre-trained now on their tool.
No, it's CSS. No real UI framework has anything remotely like CSS, and for good reason. But people like the author of this article keep trying to make CSS work instead of writing it off as the mistake it is, and so web development remains awful.
Let's just have a bank browser for banking and a restaurants browser for deciding where to eat. Then the banker need only indicate that the account is overdrawn and the restauranteur need only indicate that the fries are gluten free.
The number of people who need to care about how these things are presented to the user could decrease by a factor of 1000 if we just standardized a little and stopped trying to control every little thing.
you mean like native mobile apps?
Not sure how to get the banks to contribute to such a non-zero-sum endeavor, but man they could save some money if they did.
I would argue that most backends typically also deal with more than 1 user at the same time (and in real time).
There was a point in the history of front-end dev when they all started calling themselves "rock stars" and became convinced that they are the future of software development. The SPA trend gave frontend devs an excuse to write unmaintainable code, gave designers an excuse to call themselves software developers, and then they all told the world they are doing "full-stack development" when Node appeared. Meanwhile they never bothered to learn pre-SPA UI, UX, or content design principles.
Thing is, working on front end never gives you a chance to work on problems that backend has to deal with. I never let JS guys work on backend code, because they are lost if they cannot find a module online that does what they are asked to do, or is missing half of the features from the spec it promised to implement (always the hard ones). We then have to pick up the mess and rewrite it in Python or Golang, which is wast of time and money. I once quit when when the client showed me the Python code written by a JS dev. My devs refused to touch that shit and we went to work for another client.
> We then have to pick up the mess and rewrite it in Python or Golang
If you really must feel smugly superior, why go with Python or Golang? You could be using Haskell!
The JS devs I worked with in the past were competent developers who happened to do JavaScript.
Stop self-aggrandizing. A huge percentage of backend devs would be lost without their giant MVC frameworks holding their hands throughout the dev process. Many of them do nothing more than write little controller functions while they lean on their frameworks, authentication modules, routing libraries, ORMs, and templating engines to do the hard work. You're not sending rockets to Mars after learning how to spin up a Django c.r.u.d. app.
It felt like a flood of junior programmers in an echo chamber set off by an opportunistic engineers at Facebook who were more interested in creating their own job security then work to evolve an existing standard.
Seriously who honestly thinks that the authors and governing board of HTML and CSS didn’t closely consider the features in react?
What kind of arrogance does it take to say they’re fucking dumb let’s reinvent EVERY tool on front end because we know better.
But I digress…
This one really gets me. Being looked at like an alien from mars when talking to people about styling a page with a few classes here and there rather than pulling in 6 different dependencies of Tailwind et. al is maddening. We are web developers. We get paid to know these things, not to complain about them being annoying and try to find hacky workarounds. And now I get to sift through your utility soup and hope to god there's a class in whatever framework you GPT'd some boilerplate for that does exactly what the designer wants.
I think it must be because I have zero actual CSS to care about. There’s just nothing in my UI aside from React components, and there’s just enough sugar that it’s easier than using the style attribute everywhere.
React is too loose, it just enforces no abstraction or discipline. JSX ends up an ugly nightmare of angle brackets, ampersands and question marks. You often have to piece together how the component works by staring at all the event handler code for minutes hours days. Most of my colleagues writing it would stare blankly if I mentioned MVC. I think I would come down on the side of Angular, it's opinionated, but at least they attempted to separate the template from the controller, and logic in the services.
> how do we make content presentable as easily as possible, with as little duplication as possible, and with as few negative impacts to the user as possible.
Why is this the priority? If I wrote a language that was solely focused on removing duplicate code, and doing the minimum to appear decent, that would be a pretty bad language. I care a lot more about composability and readability than de-duplication and floor raising. Let’s face it. CSS comes from a fundamentally different situation than the modern web. I’m talking about optional styles that do not affect the content, that are written by one or two people, and likely total at most a few hundred lines. That is nowhere close to modern websites. Bemoan that all you like, it doesn’t change the reality.
I’ve been doing this as a hobby since 2003, writing all caps <HEAD> tags and FTPing .htm files to a web host. I know a bit about how we got here. If you’re really this pissed off you should get a new job and build everything how you want it. I’ve work on greenfield projects almost exclusively for my entire career. It can be done.
Then the web changed a bit. In 2005 to 2015 (ish) people transitioned from being consumers of web content to creators of that content. We called it "Web 2.0". Content was still king because people went to their favorite sites to create things that other people would read. But anyone with half a brain could see what was coming next.
Around 2015 people stopped making content for other people to spend time consuming and instead shifted to making content that was seen for as little time as was necessary for them to hit a 'like' button. 'Content' in any meaningful sense died. It became a sentence on Twitter, or a photo on Instagram, or a really short video on TikTok.
The entire premise that users go to websites for the content is nostalgia. That side of the internet is effectively dead (despite some noble and awesome attempts to keep it going, HN being an example). Today very few people get paid to build static content sites. If you're a web dev you're paid to build an app that enables people to do things in a browser - and yes, that means working with something like React. All web devs try to crowbar React into everything simply because that's what they're paid to do, and they're paid to do that because that's what users want to do. Railing against it is a waste of time. The Internet today is not same as the Internet of 25 years ago.
You can write a good website with React. You can write a good website with htmx. You can write a good website with HTML/CSS/vanilla JS.
The average developer who cares enough to learn and use htmx/vanilla JS is going to write a superior product simply because they care more about performance and/or because they are better than the average developer.
---
I'll plug my favorite way to build a site: Astro [0]. It allows you to write JSX that compiles to static HTML. You can use React/Vue/whatever as well for anything that actually needs to be dynamic.
I'm not affiliated in any way, but I did build my personal site [1] with it.
[0]: https://astro.build
[1]: https://sjer.red
It's really hard to appreciate it now because CSS (along with JS+HTML) has been extended and upgraded gradually over the years, but CSS is incredibly good for styling and formatting DOCUMENTS - which have a very specific definition, especially back in the 90's when it was first conceived. This is what is was originally designed for.
In that sense the complaints about CSS are perfectly reasonable: why are we using a document styling language for building arbitrarily sophisticated web applications when it was clearly not originally designed for that? You could say the same with HTML and JS really.
> Quit acting like CSS is some giant-ass mistake that needs fixing. A group of people who were collectively smarter than us wrote those specs. They didn’t make mistakes. Assume you are making the mistake, not them.
So what year again was the CSS standard was first published? Checks google quickly -- oh it was back in...1996. HTML was...1991. And JavaScript in...1995.
Yes, it's well known that people in the 1990's were much smarter than people in the 2020's! It's not like there's been decades of progress since then! CSS is utterly fit for purose and bereft of any flaw or defect! Absolutely nothing new needs to be invented or discovered about front-end web development in 2024! There's no point in trying to improve things!
OK, it's hilarious the author rails against things like SASS, and CSS is now being updated to incorporate many of the same features that SASS introduced:
- CSS nesting: https://www.w3.org/TR/css-nesting-1/
- Scoping (no more global): https://developer.chrome.com/docs/css-ui/at-scope
- Not to mention things like CSS variables, calc() etc.
Usually people whine about the status quo or things staying the same for too long and in response, try to improve things. This article almost seems like a big whinge about how things should stop changing and regress or go back in time? That's not happening. If people had the author's sensibilities or attitude back in the 2000's we'd never move past `float: left` for positioning or tables for multi-columnar layouts. Utterly bizarre.
So it's possible. What's the point of a rant without the code to back it.
> I did agency work for 11 years before making the choice to work for a very large tech company. I have worked across sectors like insurance, healthcare, retail, banking, investing, marketing, and manufacturing. I have worked with global brands which are household names.
> I have written a lot of front-end code for a lot of companies. I have also dealt with a lot of consequences created by front-end code. My criticisms come from my role as a front-end developer and as someone affected by a front-end developer.
React single-handily killed it. It encouraged, usually required, all of the awful design patterns I used to chase all the junior engineers and interns about. This has become endemic in the JS world.
Here's an example: did you know that the uuid npm used Math.random up through 2020 (v.7)? Cryptographically secure random number generation had been available in basically all browsers since 2011. 9 years. If I had an engineer submit that code, I'd rake them over the coals.
Speaking of that, I'd usually need a half-time engineer on larger projects just for the management of the complexity. All of the various frameworks and updates and breaking changes. It was a 20/hour a week job just to stay on top of things. For instance, koajs.
It's a bunch of dependency code of quality I would never let fly, but now I have to use it and grow my team, increase budget, push back deadlines - all to manage the piles. No thanks.
I left that job, quit the industry entirely about 2 1/2 years ago. Reactjs was such atrocious self-aggrandizing bullshit, it made me quit programming. It's fragile, over-engineered, mostly broken, confused poorly defined amorphous concepts that poorly solve mostly imagined problems and the entire industry of front-end is eating up that mode of design like it's some sacred text.
They'll use abstract buzzword concepts that have different conflicting definitions in basically every text you pick up, and they'll never concretely define them but continue to use them as abstract amorphous blobs.
I've got very popular front-end projects. I've been at the C-level of more than one company that sold based on front-end design. The first professional javascript based web app I did was in 1997. I deployed Server Side JavaScript (SSJS)/LiveWire in the 90s, a decade before Node ever existed. I've been at this for a long, long time.
After dealing with react, I never want to touch that stuff again.
It has affordances and design patterns that inexperienced, new, novice programmers find attractive and tempting but comes with all of the warts and issues surrounding intuitive patterns. That's why it takes over 10 years to get good at programming - counterintuitive insights are the clarifying beacons on any sufficiently complex project.
People are "react programmers" instead of actually understanding the specs, standards, javascript, protocols or how things actually work.
It's about 100 times easier to find a mediocre junior programmer than a comptent one. React allows, at a great cost of time, resources, and money, a large team of mediocre junior programmers to eventually create what once required a competent engineer and that is why it's popular.
Your offshore outsourced $15/hr programming firm can now make a half-assed website or app and you don't actually need to find someone who knows what they are doing.
If you've actually worked in the industry, actually dealt with code, been put on projects that are off the rails, you know this is true. You know this is exactly what is happening.
Then management is unwilling to pony up the $250k to attract the right talent so you get stuck with the job of making heroic efforts to prevent the house of spaghetti from collapsing.
You've been there. You've done this. You know exactly what I'm talking about.
If I had to manage the collapsing house in Rust I imagine it’d be much, much worse (though I can’t say I ever had that experience, so who knows?).
There's an extension to this - a codependency. The system imposes structure back up the chain.
These choices can become good organizational fits because they reflect the separation of concerns of a project decided by management. It's almost invariably a management that doesn't know how to code or build software.
I hear this in my circles around Python which encourages spaghetti code and reaching into private parts of other's code. Yes, you can prevent this with better libs/modules, solid leadership and a steadfast resolve with adequate tooling. Or you can use a tool that makes spaghetti harder to write and pick something like .net or Go.
Could you summarise it for me? Sort of along the lines of:
<this is what is needed>:<this is what React provides>
This article explains it using a bit of react jargon (action, store, dispatcher) which is kind of unnecessary - but that's what I got from a quick google:
https://medium.com/@asif-ali/react-architecture-vs-mvc-unidi....
React Architecture vs. MVC: Unidirectional Flow Advantage.
Just no more web pages
But in the end it’s fine. Different, sure, but there really is something to using the same language on both front and back-end, and not having to wonder about how to reconcilliate data and markup.
React and the whole ecosystem gives you a thousand extra problems to care about, but it also takes a ton of them go away. It makes the simple things annoying but the hard things also merely annoying.
I know that's forbidden on the Internet but I'm still deeply passionate about building good software and I'm just so disappointed by the precipitous decline in quality that's plagued the industry despite the increase budget and manpower dedicated to it.
It's inescapably the tools and methods. This ought to be the golden age. Things ought to be great. But they're terrible. Everything has been getting slower buggier and shittier. It's become more complicated while doing less. It's awful.
Really, FWIW, the things I need are:
1. Introspection tools to find out what's going on without having to rewrite the build system.
2. Comprehension and navigation tools (like copilot) that I can interface with and give insight into where things might be happening
3. Timeline tools like rr
4. Advanced diagnotistic tools like ebpf
And that's really it. emacs and vscode are the things I cycle around. I still think these are all open problems.
Pretend I'm a person who agrees with you about React (I might be, after all[1]).
Have you ever seen that page "You might not need Jquery"? Can you please write a similar blog post (or even put it into a comment here so that I can bookmark it) titled "You Might Not Need React"?
I want to know what it is that React gives (maybe)millions of developers that you don't need.
All those things that React is commonly used for: what are you using instead? Show snippets, please.
So, yeah, throw me a bone here, please write "You Might Not Need React", because I can guarantee you that there are numerous devs who want to read such a post.
Pretty please.
[1] I looked at the React tech stack and learning curve for someone who only knows HTML, CSS and Javascript out of the entire web-stack, and noped right out of it.
It does take longer to learn and require more intellectual rigor to do things this way but you also get 10 year solutions instead of 10-month ones and things are way easier to debug, pivot, modify, repurpose, support, All the long-term things you have to do after the act of building when people are actually using the thing. Those are now easier
What I was looking for was literally a "You Might Not Need React" equivalent to the https://youmightnotneedjquery.com/ site.
It doesn't need to be as polished as that, I just want to see <this is what react lets you do>:<this is how you'd do it without react>, even if all the "this"es in there were just patterns.
I just want to be clear here, I'm not engaging in bad faith, or trying to prove something. I truly just want to know what react code is commonly used for, and what a vanilla solution would look like.
Like what about useEffect? There's many many terse ways to implement this that in practice do the same things but in a slightly, arguably inconsequentially different kind of way.
I'm sure there's a large legion of pedants out there who would have a field day slapping their suspenders against their chests nitpicking how "not exactly!" the alternatives are.
If we can somehow avoid that trolly bullshit then I'm game.
It validates your opinion. React became an insanity.
Just note all the nuances and minefields they are adding to an already bloated tech.
https://www.youtube.com/watch?v=fXugpgknScY
For one, it's 2024 and React still has this infinite newbie trap of double rendering. [1]
But, it's perfect for job security.
"Nobody ever got fired for buying solutions from IBM" became:
"Nobody ever got fired for choosing React."
[1] https://chanduthedev.medium.com/why-react-app-rendering-twic...
I'd rather every element be a div than do one minute of editing those stupid jinja files.
20MB of inscrutable JavaScript allows you to have a) a sane structured component system where you can actually build up UIs compositionally rather than a flat glorified string substituter (i.e. not actually "just template rendering"), and b) the control and abstractions needed to make good UIs out of nested tables.
Sure, but you're still going to be using "20 MB of inscrutable JavaScript". (Unless you use Wicket, but I'm not sure that's an option for emails, and would likely trigger the same complaints anyway). I mean, I hope you're not using the component style rendering layer for Python that I published ~10 years ago, because I haven't maintained it, and as far as I know there aren't any others.
As a home assistant user, jinja in yaml files is hot steaming ass.
Every time I read the jinja manual I want to cry. And a small part of me dies in side. It's like a templating language designed to get even with the person who microwave a tuna fish sandwich in the office, for lunch, daily... That some how leaked out to the web.
While generating any moderately complex HTML on the front end is a pain in the ass for me. I prefer avoiding it. If I need to request some data from the server to dynamically update the page with, I just make that endpoint return some server-side-rendered HTML that I insert wherever it needs to go.
The rest of us will keep wondering why he implicitly assumes that backend generated with js is sooo much worse than if was generated with anything else. I've also written my fair share of PHP before AJAX was even a word, plus lots of ASP.NET, Java and Python backends. Honestly, their templating languages all suck, compared to React components that are type safe and infinitely easier to compose and refactor (jinja anyone?). While their languages and ecosystems are a lot more powerful, JS these days isn't that terrible as a language, just keep a tight grip on your package.json.
It is correct that there is something wrong with the culture of the front-end development, in that there seem to be no brakes on just piling crap on the next shiny thing and then building even more packages and abstractions around it, instead of fixing the underlying crap in the first place.
The key difference between the web and any other type of development, is that you can distribute almost any type of application with the push of a button to billions of people, without the need to install anything. This is a superpower which _ofcourse_ comes with some complexity. Sometimes when you don't need that superpower and you have to navigate the complexity anyways it will be a frustrating experience, but that doesn't mean there is something fundamentally wrong or anything.
Sure, if you are building a simple content heavy front-end, it doesn't make sense to chose a React framework or React at all. But many apps today come with heavy front-end interactions and have to sync with their back-end in real time. Good luck doing that with jQuery Ajax.
And you can't blame the bootcampers. They were promised riches after a 6 months bootcamp. They were taught React and had little interactions with HTML. So they are doing what anyone else in their position will have done. So when they were out in the market, then React is was. Suddenly, everything became a React component; and if you made a website today, you'd better off start with React.
In defense of React/NextJs: I have been blogging for 10+ years. I started by using WordPress. I have constantly failed to maintain a server up and running for more than a year. There is always something that comes up. A bad WordPress update, DB goes wrong, a failed payment, a bad WordPress plugin update, Server goes down because?, etc...
5 years ago, I switched to NextJS. It's a spaghetti of NPM modules just to build a very static website for very simple content. Sure. But 5 years later, the very same site is still up. There is no maintenance involved as the site is hosted in Github. Not sure I'd say the same about WordPress.
Sure, there's a reason. Doesn't mean it's a good one :-/
> 5 years ago, I switched to NextJS. It's a spaghetti of NPM modules just to build a very static website for very simple content. Sure. But 5 years later, the very same site is still up. There is no maintenance involved as the site is hosted in Github. Not sure I'd say the same about WordPress.
Is 5 years considered a long time? Is that the bar? Because >6 years ago I wrote an internal site/app in C# using Jquery for front-end, and that is still up, working and being used by a few thousand people daily. It's even being extended every now and then.
No NPM, no React, no Vue, no Next, no front-end build step.
I can move it to an up to date VPS and port it to a recent version of the CMS in a couple of hours and it would then be fine for probably another 6 or 7 years.
Now try actually checking out the code and building it. I’m sure there is some Node.js runtime feature that is no longer supported in the LTS version you currently have installed on your notebook.
He has some good points regarding SASS. Other bits were about ranting.
The issue with frontend dev is there is a gajillion bootcamps promoting it so we have a bell curve weighted heavily weighted towards juniors.
Add in browser compatibility issues, framework churn and other headaches, there are fewer highly experienced FE devs who understand the browser in a deep way.
FE code also tends to be highly stateful. Managing state well is one of the harder FE problems that few folks talk about.
Add in the mix that some are apps and some are websites. There is no one right answer.
NPM-Javascript is a shitshow of constant breaking changes left and right, whether it is in your runtime framework, or your build system like gulp or more prominently webpack.
Try maintaining 10 projects with these frameworks. You'll quickly look for something that is not as maintenance intensive.
Example: No, you can't stay on Webpack version X, because (real example) it turned out that version of webpack relied on md5 which wouldn't work in newer node.js versions.
Sure, yes, understand the content that you're writing your UI around, and make the UI serve the content. That just begs the question of why one would get anal about which HTML5 tags are used for headers or navs or buttons.
Only until the event handler runs :-)
I'm sure it's true for lots of other elements.
[0] https://developer.mozilla.org/en-US/docs/Web/CSS/display
It'd be a weird structural language you could really only express whether something is a block or inline.
Yeah I gave up on that fight a long, long time ago. The semantic web was an admirable dream that never had a chance.
That means that as a client I am not empowered to automatically display your content in a new way.
And why would you display a TOC differently as a client? A TOC is a list of items and should be displayed as that imo.
I want the niceness of Wikipedia generalized elsewhere but abstracted by my client or browser. The more we agree on the precise meaning of elements, the more we are empowered to programatically redesign or interact with content.
Life’s too short is a cop-out especially because it doesn’t take longer to use a semantic tag rather than a div.
With “life’s too short” you can justify pretty much everything.
Also, you have to remember whether any of them might have a different default style in the browser than what you'd get from a regular div/span.
But don't take my word on any specific examples, I don't have any real experience outside of normal web React (which does give you full control over the HTML elements, except of course for third-party components).
> Having your headings in semantic order is fantastic for screen readers, but from Google Search perspective, it doesn't matter if you're using them out of order. The web in general is not valid HTML, so Google Search can rarely depend on semantic meanings hidden in the HTML specification.
And a typical business web page likely won't have many "automated processes" it wants to accommodate except for search engine crawlers.
[0] https://developers.google.com/search/docs/fundamentals/seo-s...
It says that the order of h* tags is not relevant. Which was also part of Html5 Outline spec.
H* tags are not the only semantic tags.
So it could also mean that they work with Html5 outline spec and value semantic tags, which allows them to ignore the order of h* tags.
So them saying that they ignore the order of h doesnt necessarily means that they ignore all semantic tags.
Unless you have explicit statements or hard evidence to the contrary?
nowadays i default to htmx, alpine, sqlite and typescript, recently i’ve been working on a framework/starter using these tools: https://www.plainweb.dev/
Use the right tool for the job. HTML is a toolbox, not a bucket of <divs> and <spans>.
> Maybe it’s because Angular was no one’s first choice — even though it came first.
Actually ExtJS was the first real framework. Angular was just one of the new kids on the block.
>The number of times I’ve seen numbers written inside of a <li> that’s inside of a <ul> — instead of just using an <ol> — is deeply disturbing.
I've been reading and writing HTML since the 90s and off the top of my head can't recall ever seeing <ol>. Why is it better? For screen readers? A sentence to illustrate goes a long way.
It's better because it means it's a list of something in order, as opposed to a definition list or an unordered list. The distinctions are important.
It means, for example, that you can meaningfully skip to the middle of an ordered list of the 100 tallest buildings, and be guaranteed to be looking at the 50th tallest building.
An ordered list <ol> automatically adds a number to each list item indicating its position in the order in the list which would save developers the effort of adding code to insert numbers into ordinary list items in an unordered list.
I have to ask: is this /s? Are you really saying you never seen an ordered list in 30 years working on the web? How about <dl> ?
If you’re not joking then it’s honestly wild to me.
Somehow, even if I never used roman numerals, that example sticks in my head (esp the lowercase).
Anyway, if you cared deeply about content in the 90s, you might have focused on the semantic meaning behind tags (I've also looked a lot at other SGML and later XML based formats like TEI, DocBook...), tried to strictly decouple presentation (CSS) from the HTML (content), and be annoyed that the CSS box model never supported nice content-related flow features like TeX did since the 80s (and still doesn't).
Now, don't get me wrong, I wasn't some wizard — I was simply an easily impressed (with things having some meaning) high-schooler around that time :)
Who needs HTML
It feels like I'm building a single application not two separate frontend/backend applications; managing overhead rendering and communicating between them. Next.js, Nuxt, Remix, SvelteKit - are all part of this next generation batteries included frameworks that can seamlessly transition from server side rendering to client side interactivity.
$('.getResults').on('click', () => {
$.ajax({
url: '/api/results',
data: {
foo: 'bar'
},
success: function (result) {
$('.results').html(result);
}
});
});
Yeah, it's hard to take any arguments about code quality seriously when this is being held up as some kind of ideal..
Few things I disagree with:
- The content rant was weird. I've always worked with content designers, instructional designers, or good marketing copy people. Was that about semantics? Sure ya, SEO and a11y.
- Cascading CSS is great until you write a million+ line SaaS app and have 1000 devs working on the code. Then you need scope. The rant is specific to brochure sites.
- SSR. Weird. Do devs really think that? I guess I'm out of touch or my colleagues are better than most.
- A lot of rants seem to be ripping of jr devs. Show them the way! Very yells at cloud.
- CSS nesting I really like. Example of nesting elements inside a class is a hack that should not be done. Nesting is easier to read if done properly.
Server-side rendering (the normal kind from 1990s):
1. It is glorious. Everything that 37signals has to say about it is true.
2. However. I really miss React-style components as an abstraction. There are many ways around it that we use depending on the case (plain CSS classes, our own tiny Go/HTML component library, HTML custom tags), but we’re yet to produce something as ergonomic for more complex compositions.
3. We’ve added Hotwired Turbo for smoother page updates. I find it’s a lot more orderly than htmx, but we do miss some things that htmx would offer.
CSS:
1. We started out with just plain CSS, using BEM and CUBE to structure it and manage complexity.
2. That still got us questioning the DIY nature of the U (utilities) part of CUBE — it got increasingly complex and random, and really just like every program grows a broken LISP interpreter inside, every custom CSS utilities library grows a broken copy of Tailwind inside. So we adopted the actual Tailwind for utilities. Tailwind is truly glorious, both for sheer productivity of writing the code, but also as a language for describing styling at just the right amount of detail — more powerful than CSS properties alone (hover:color-red-700, disabled:cursor-default), but more constrained than full CSS.
3. Tailwind introduces a build step, though, which sucks (and slows down the build by the whole second! My m2 Air can probably do a 60s supercomputer-level nuclear explosion simulation during that time.) Thankfully, part of our startup is doing custom themes for each client, for which actual Tailwind sucks even more (themes are edited at runtime, and you wouldn’t want to run actual Tailwind with its million Node dependencies on your server), so we’ve implemented a subset of Tailwind in Go, just the things we actually used, and it runs at runtime, eliminating any build steps for themes.
4. Bottom line: Tailwind is absolutely glorious as a shared design vocabulary. Non-tech people were able to adopt it and handle theming thanks to it. The actual implementation of Tailwind seems unacceptably slow, but I hear a Rust compiler is coming.
JavaScript:
1. Plain old JavaScript is great, but needs some structure. We found that structure in Hotwired Stimulus, which we absolutely love.
2. But again, I do feel the desire for React-style rendering occasionally. We embed our widgets on customers’ e-commerce sites, and a chunk of HTML rendered based purely on data coming from an API with live updates is a perfect case for React.
3. Needless to say, running code on other people’s e-commerce sites is where I would never dare use a React-based stack, because I’d spend the rest of my life doing due diligence on the dependencies. (Our competitors are much less responsible about this, and it works out for them too, so this is more of a principles thing.)
4. This is probably the case where an in-house 500-line implementation of React-style rendering would be preferable to anything else. We already have a 100-line version, but it lacks many desirable features.
Bottom line: Yes, you can (and should) run a modern startup based on a pragmatic server-side rendered stack, but you definitely want to add just a few modern things: something like Hotwired, something like Tailwind, some solution for more powerful components in your templates, and something like Preact for certain use cases.
That was the first article written like that I've read in a long time, and I enjoyed it, and laughed at some of it, and the topic certainly resonates with me.
(a) less work
(b) scales from 10 items to 1,000 to 1,000,000 items effortlessly
(c) works the same no matter what number system you have localised, such as greek, chinese, icelandic and arabic.
As in any profession: use the right tools for the job, otherwise you're bashing in a nail with a screwdriver and scorning the guy using a hammer.
People who still rant about the simplicity of jQuery are of the same cloth.
By the way, on my recent visit to Europe, there still was a total in francs "for information" on the receipt from a random grocery store in Paris.
As an european: that's a problem. Why? Inflation. People who still change regularly to the old currency only do so for some of their finances AND romanticise the past.
If you actually want your life to be simpler, use React for everything, like everyone else. Stop worrying about how many dependencies you have and wasting your time reimplementing them worse.
CSS tends to be hard because (1) people insists on having a single page with a single stylesheet and (2) only divs are used, and so they use class names for everything.
If you didn’t use a SPA you’d have scoping. If you used semantic HTML you could target based on semantic structure. Both of these makes CSS easier.
JavaScript is fine to use if you have to. But using JavaScript when you don’t is just wasting time. I’ve seen people essentially re-implement default <form> behaviour too many times to count, and spend time looking for solutions to problems they only have because they insist on using technology for making interactive sites when they’re making something largely static.
If you want a simpler life, choose the simplest technology that will solve your problem.
No they don't. They were developed to work on the web as it existed at the time and handle it fine. A screenreader doesn't magically do something different and better with an <em> tag than a <b> tag, and only confused thinking and propaganda has made people think so. (And anyone who actually cared enough to test with a screenreader would know this - but people don't actually care about screenreaders, they just use them as a stick to beat technologies they don't like)
> CSS tends to be hard because (1) people insists on having a single page with a single stylesheet and (2) only divs are used, and so they use class names for everything.
> If you didn’t use a SPA you’d have scoping. If you used semantic HTML you could target based on semantic structure. Both of these makes CSS easier.
You still need class names, because you're always going to have some distinctions that matter in your domain but can't be mapped onto the fixed list of HTML tags. So either you use divs and class names for everything, or you use a mix of tags and use a mix of class names and tag names, which just ends up being less consistent and more confusing.
You have components that are shared between pages, so you either have to include all your CSS on every page, you manually figure out which components are used on which pages and make mistakes sometimes (leaving you with missing styles), or you use a Javascript UI framework.
> JavaScript is fine to use if you have to. But using JavaScript when you don’t is just wasting time.
I find the opposite. You're always going to need JavaScript eventually. Trying to do stuff with CSS and HTML tags just wastes your time and the end result ends up being more complicated because it's a mishmash of both. If you use a well-known JavaScript UI framework from day 1, it's so much easier to end up with a simple, consistent, maintainable site.
They do. They use tags and semantic structure to figure out what to read when.
You also skipped the "and other assistive technology" part of my sentence. Tools for navigating, or alternative rendering, improves when your site is semantic.
I use these tools every now and again, I'm not basing this on theory.
> You still need class names,
Not as many. If you use divs and classes everywhere, you end up using classes for semantic meaning.
> You have components that are shared between pages, so you either have to include all your CSS on every page
Use classless CSS as far as you can, use site-specific (layout) stylesheets, and use webcomponents for those components that are truly novel. Webcomponents with shadow dom means it can include it's own stylesheet without affecting the rest of the site.
In many cases, you get by with just classless CSS. Site-specific layout is a one-liner. Webcomponents bring their own styles.
So no, you don't need to bring an entire JS UI framework for this.
> You're always going to need JavaScript eventually
Depends entirely on what you're building, and a lot of the time you can get away with something simple like HTMX and JQuery.
But even if you do end up needing a JS framework for some portion of your site, limiting the amount of stuff that needs to be handled by this framework _greatly_ reduces the amount of complexity, and amount of code, that the developer has to write.
You're always going to use classes for semantic meaning anyway, because the HTML standard doesn't and can't define all the semantic distinctions that will be relevant in what you're making.
> use webcomponents for those components that are truly novel. Webcomponents with shadow dom means it can include it's own stylesheet without affecting the rest of the site.
I guarantee you the author of this rant hates webcomponents even more than they hate Javascript. (Indeed I'm pretty sure they qualify as a "JS UI framework").
> But even if you do end up needing a JS framework for some portion of your site, limiting the amount of stuff that needs to be handled by this framework _greatly_ reduces the amount of complexity, and amount of code, that the developer has to write.
You can draw an arbitrary line and say JS is "code" and HTML and CSS are "not code", but that doesn't actually make them any simpler to understand. Expressing your whole site in the same framework used the same way results in something that's much easier to read and maintain.