This is fun in to theory and in simple examples, but show me a big project that applies this and how it made a difference.
There are some bold objectives at the start that would be wonderful, but I’m a bit disappointed by the advice. I really don’t see how these would work in anything other than very basic scenarios, even less how they would achieve the objectives.
I’m all for using the web platform to the max, and I’m absolutely for reducing complexity as much as possible, but I’m highly skeptical these principles will achieve that and I would not be surprised if it increases complexity by having multiple ways to do something.
With peace and love but I can’t see from this list if you actually put these principles to the test or you just assumed it will do what you hope it will.
Why? Why does it need to be good for big projects in order to be good practice?
I’m genuinely asking. I never understood this argument that people bring.
In my view, the web is 95% small to medium projects. Most technologies should be focused on that - simple solutions for simple projectS. Add complexity later.
Because in practice there is little value in making easier things easier. While 95% on the web are small projects, 95% of work is done on large projects.
Many developers also dislike using many different frameworks, because that would require more learning. If you have to choose one technology it's better to use one where you can do everything. Not one where you can do 95% really fast, but 5% not at all.
I personally always use "complex" frameworks like Angular or React because sooner or later feature requests come in, where those frameworks pay off. On average it saves time for me to always use those frameworks. That might be different for you depending on the work you do.
Do you have any data to support that 95% claim? As big as FAANG and other huge development teams are, it seems to me it's still only the tip of the pyramid, with the overwhelming majority of people in the industry working full time on small or midsized projects. It'd be interesting to see some concrete info on it.
The point where frameworks like Angular and React pay off and what I think of as complex projects are those where there is a some nontrivial feature. This coukd be a project with 1 developer working on it for 6 months.
For example a static page with a booking process with various entry points on the website, which slightly change the booking logic. Also you can book as a new user, as a logged in user, for somebody else etc. Also the logic is changing at regular intervals, because the business owner is trying different things out.
Using Angular with reactive forms makes this easier to develop, maintain and hand off to other Angular devs.
While it makes writing the static parts of the website more complicated, it makes developing the booking process easier. And overly complicated business processes are what is mentally challenging for me. This is where I want all the help I can get. Writing static pages is something I can do in any framework even when I am tired. Making this part easier or reducing boilerplate is nice but doesn't make me much happier. Being able to build ridiculously complicated forms without my head exploding does :) Of course if you work on projects with relatively straight forward requirements there is 0 advantage in using Angular or React for you. It always depends on the type of work you do.
> a booking process with various entry points on the website, which slightly change the booking logic. Also you can book as a new user, as a logged in user, for somebody else etc. Also the logic is changing at regular intervals
The more complex the business logic, and the more options there are, and the more it is expected to change, the more it benefits the development team to write that code in their language of choice on the backend, close to the data store(s), using native classes/objects -- rather than being forced to write it in JS/TS, serialize everything to/from JSON, reliant on magic under the hood to lay it out in the DOM, with more and more "state" necessary to be managed client-side.
> the more it benefits the development team to write that code in their language of choice on the backend
Why?
TS is maintainable and very pleasant to code in. Most people’s computers are way faster than making round trips to a server. You talk about serializing everything to/from JSON, but my phone can do that in milliseconds (if not faster). Compare that to 100-200ms of latency between a faraway server, and all of a sudden doing things client side makes sense.
Engineering is all about tradeoffs. I’m tired of people trying to make blanket statements like “React is always better”, or “SSR is always better”. It’s not, and we know it’s not. There are several successful, performant, maintainable apps written using React. There are plenty written using a backend framework and SSR too. Heck, there’s successes that use both!
The common denominators in the success stories? Competent engineers. And I expect a competent engineer can analyze requirements and determine what would be the best outcome for their target users. A booking site absolutely benefits from a front end framework that handles client side logic. It probably also benefits from a clever backend for processing the data after the user is finished with it. Let’s not pretend there’s a one sized solution that fits everything, because there isn’t.
A tangential answer (focusing on backend not language) is because I'm (we're) going to have to reproduce much of the fronted complexity of the business logic on the backend to validate what the frontend sends.
I'm mostly agreeing with you. I've built multiple web-platformed insurance systems and booking systems in the last decade and moved from fully server rendered pages to client rendered forms. The complexity increased with that change but as you highlight once it's done the ability to test different frontend flows is great.
But I'd like a way to share more of the business logic rather than writing it twice.
> Compare that to 100-200ms of latency between a faraway server
A complex booking engine like an airline or Stubhub needs constant, almost real-time connectivity with a database, otherwise you risk selling product at a stale price, double-selling, selling to an unauthenticated person, getting taxes and fees wrong, missing custom post-sale add-on opportunities, and lots of other potential problems. The client has to make a lot of network calls, so you're going to deal with latency, there's no client-side solution that avoids it without risking the issues above.
If only they actually worked like this. I’ve experienced, as I’m sure many other people have, problems booking flights, lodging, buying tickets, etc, where when I go to checkout it fails because I was too slow. It’s also much faster to only request smaller pieces of data if you can, instead of resending an entire web page and then re-rendering the whole web page.
All that to say, there are tradeoffs. Finding the solution with the best latency and the best experience requires a careful analysis of all these details and figuring out which approach (or combination of approaches) solves that problem the most efficiently. Of course it’s not easy, but nothing you’ve said here indicates one solution would always outperform another solution.
> problems booking flights, lodging, buying tickets, etc, where when I go to checkout it fails
Because they are typically written using popular heavy frameworks! Big, expert teams of developers can't get it all bug-free and fast and smooth when working with them. Thank you for making my point better than I could.
> only request smaller pieces of data if you can, instead of resending an entire web page and then re-rendering the whole web page
You have revealed by this statement that you have no idea how HTMX works. You are making an argument against something you've clearly never looked at.
I don’t understand why you’re bringing HTMX into this? This is a blog about HTML first, and the comment I originally responded too seemed to imply a more traditional MVC or SSR site was the way to go. It feels like you’re just searching for a “gotcha” argument at this point and not arguing in good faith.
My whole argument can be succinctly summed up by this comment from a different Hacker News user from when React was first announced:
> One of the biggest problems with the web platform is that we've spent the last 20 years trying to shim applications into a document framework. HTML was designed to help academics share research papers, not to replace native thick-client applications, yet that's the direction it's been evolving towards.
> I'm really happy to see Web Components (inc. Polymer, Angular, x-tags, and React) landing into HTML. If we accept that web apps != web pages at a spec level, hopefully we can build an awesome platform on which to create tools that leverage all the great parts of the web (linkable, available, auto-updating, device-agnostic) without the mess that we've made trying to make the web do something it wasn't designed for.[0]
This sentiment, after 10 years, is still spot on. The web isn’t academics sharing research papers anymore. Interactive web apps, whether you like it or not, require a ton of client side state management. React was developed to address concerns with managing that state and improving performance where HTML5 fell short. It still succeeds at that.
Of course, if you have a static site, don’t use React! But let’s not pretend there’s no use case for it either. There’s tradeoffs. And I’ll repeat that til the end of time. No matter what you choose, there’s tradeoffs.
> How are you going to do the updates without FE logic? Refresh the page constantly? The client being able to fetch just updates is a lot more efficient. If you open a web socket the server can even push.
That's exactly why HTMX has gained immediate traction so quickly, it solves many of these exact problems elegantly and easily, much of the time without a single line of JS.
I suspect even at Google a lot more than 5% of effort goes into small to midsized projects. Bazel, ninja, protobuf, grpc, the API documentation website for Gmail, VP9, the Google transcode api, takeout, various corp network tools & services and so on.
The big projects are of course important. But even chrome needs a simple little website with a download link.
That's a good point. I personally always like Angular and React, because even with most simple projects there is this one feature that is so ridiculously complicated that making it slightly easier to develop and maintain is important to me. I'll gladly write thousands of lines of boilerplate just so I make it easier for me to succeed in developing this one endboss feature. If you do not have at least this one insane feature, Angular and React are definitely overkill.
I always see this as a communication/management failure.
Product folks come up with features. They have no idea how hard those features are to implement. Which in a way is a blessing; they'll come up with the best features if they don't have to consider the implementation details. But because there are always trade-offs in implementation they also don't understand those.
A feature that is super difficult to implement, and that therefore has trade-offs on speed, maintainability, etc, should be communicated back to the product folks. If you have to move to a framework just to implement this one feature, then that is either because this one feature is really badly or over-designed, or that one feature is absolutely critical to the entire site, which is stupidly rare and again a symptom that someone hasn't really thought this through enough.
The failure in communication is usually "you're just the nerd pushing the nerd buttons, you don't have valid opinions on product design" which is a cause of so, so many problems in our industry.
> The failure in communication is usually "you're just the nerd pushing the nerd buttons, you don't have valid opinions on product design" which is a cause of so, so many problems in our industry.
But are they that wrong? We compute to, well, do things with our lives. To find out how to go places, to pay bills, to talk with friends, to meet with people, to learn about things. A view that computation should come with technical (e.g. tech bloat) limitations in mind feels important only to technical people and not to actual computing.
If building it one way will take 3 months and involve shipping 500Kb of JS to every user, whereas building it a slightly different way will take 2 weeks and ship only 50Kb of JS, then I think the second option is better, even if it includes a slightly degraded customer experience (though tbh 500Kb of JS is all by itself a degraded customer experience).
Our online lives would be a lot better if the product folks listened to the tech folks a bit more.
I like to draw a parallel to music; if the producer doesn't understand music at all, then maybe they should listen to the musicians a bit when it comes to creating a musical product.
> even if it includes a slightly degraded customer experience (though tbh 500Kb of JS is all by itself a degraded customer experience).
What if people don't use it because of the degraded customer experience? Then does it really help if people who would originally benefit from the computation never compute?
> Our online lives would be a lot better if the product folks listened to the tech folks a bit more.
I mean, according to which metrics? Again this is really popular on HN and other nerd forums but from what I can tell it's just a nerd forum indicator. I think you can make a decent case for involving tech and product together, and I can think of many, but it's a case-by-case basis and has nothing to do with degrading customer experience. This view is popular on HN because we don't actually care here much about actual customers and care more about things like "site payload" and "how much JS is running in my browser". If the argument is that people with older devices won't be able to run the JS like this, I'd argue that your networks have more latency than any bloat you get from JS. Which is why a holistic experience matters more than what your personal tech-experience gets hung up on.
From my experience I don't think product and management folks care much about the user experience either; it seems to be mostly ego and dick-measuring.
My target user is someone running 3G on their phone on the commute home in a crowded train. The designer's sexy animations and carefully coordinated state changes are not worth the extra 100Kb of 3rd-party dependency JS required to get them to work, because the user is not going to see them; they're going to switch away from the app after 10s of staring at a blank page waiting for the JS to download.
Seen too many "perfect" designs on a laptop monitor right next to the router in the dev studio fail completely in the wild. Every Kb matters.
Unless you have anything more than anecdotes and feelings to contribute to this discussion, I don't think there's anything more to discuss. Data makes a more convincing argument for such bold claims, especially when a minority of practitioners claims that their way of doing things is more correct than a much larger majority. I will say, from your maligning of "product and management folks" to your anecdotally-driven interest in page weight, its like every dev stereotype ever.
Are people really struggling at that level, though? It has never been easier to write a complex page with minimal Javascript - there are more and more HTML elements that do what you expect (expandos and modals as some recent examples), Javascript is cleaner and more consistent across browsers (you really don't need jQuery anymore), and CSS is more powerful but also so much simpler (flex+grid solve so many problems).
Then if that's not enough, you've got things like HTMX if you're keen on doing everything in terms of html templating, you've got tools like Svelte if you want an isolated chunk of dynamic UI in a mostly static page, you've got bundlers like Vite that just work without any configuration if you get to the point where you need a build step, and you've got a multitude of lightweight frameworks for the next step.
And on top of that, pretty much all the old ways still work. The browser is an incredibly stable environment! Outside of a handful of security-related removals, if it got into a mainstream browser, without a feature flag or an explicit "experimental" warning, it's pretty much there for life. So if you want to go back to the old ways, there's not much stopping you - but a whole bunch of quality-of-life development improvements along the way to make things even easier than they were back then.
Most professional frontend developers are working on projects that require something more complicated than just the basics, because, well, that's where the complexity lies, and so that's where the work is.
You can still find developers who are using the basics, but mostly they're designing WordPress themes or working for boutique web design agencies, because those are the sorts of problems that are solved with just simple HTML, JS, and CSS.
It's like asking a Java developer when the last time they developed something without maven or gradle is, or Python developer why their first reaction is to use pip. If the majority of problems developers had to solve were simple enough that they didn't need these tools, then there'd be far fewer developers and most of them would still end up working on the 20% of projects where they're necessary. Because, well, that's where the complexity lies.
> Find a professional front-end developer who is willing to use simple HTML, JS & CSS and I'd agree with you.
> It's almost impossible. The first reaction is always `npm init`
Consider a simple case — a static website containing several pages (it's simpler than anything requiring a dynamic server, right?). If you are a professional front-end developer, you are almost certain to prefer some kind of a static-site generator over copy-pasting the html template with repeated elements (header, footer, navigation) multiple times, because you know that copy-pasting will bite you when you need to change something. You could use a static-site generator written in Ruby (but then you would gem install), or in Python (but then you would pip install); or you could use a Hugo binary (I'd love to see anyone call its templating language simple); or, if you are a front-end developer, you might npm init && npm install eleventy. Is this too complex a step?
> or you could use a Hugo binary (I'd love to see anyone call its templating language simple)
I dunno, I'm a Go dev, so it makes sense to me ;)
> Is this too complex a step?
If it just stopped there, sure, that would be fine. But it never does. My experience of front-end devs is that they will do anything to avoid writing any actual code. So there's a tendency to pull in dependencies and bloat the thing until it suffocates in its own complexity. I've seen node_modules with thousands of subdirs, and a build process that takes minutes, for really very simple sites.
I mean, I am a big SPA framework guy. That's pretty much the main thing I use, day-in, day-out, because most of the projects I'm working on are complex enough that simply hand-coding the entire UI will not work.
And, while only a minority of projects are that complex, those projects are the ones most developers are working on. Most other projects are probably better served with a wordpress install and a bit of theme customisation. Which means it's going to be a minority of developers who work with the very minimal things that are sufficient in these sorts of cases.
Are you writing that complex projects need SPA, everything else is better served with Wordpress?
I've used SPA frameworks, but try to avoid it if I can, because most of the logic is in the backend. I don't want to create and sync API interfaces, have 1-2 additional contexts (JS + frontend framework) and debug an extra layer.
With htmx I can now have interactivity via the backend. I use Alpine.js for some interactivity.
> If you have to choose one technology it's better to use one where you can do everything. Not one where you can do 95% really fast, but 5% not at all.
> I personally always use "complex" frameworks like Angular or React because sooner or later feature requests come in, where those frameworks pay off. On average it saves time for me to always use those frameworks.
I wonder whether they ever pay off. First, I don't believe the frameworks you mention really, as you suggest, enable the last 5% of functionality that would otherwise be impossible. No, those frameworks are written in the same language they work in, which means that strictly speaking they do not enable any new functionality.
Second, whatever ease / speed of development you use must be weighed against the additional cost borne by the project's users. The time you save (that you might otherwise spend learning to achieve the same result without the framework) could be less than the time spent collectively by users waiting for the framework to load.
Not at all. There are a lot of frameworks that support static exports and/or pre-rendering. Often those produce incredibly fast results, in many cases faster than hand rolled solutions.
If you use a CMS you have already a templating situation and dynamic content, using a framework, or jamstack like situation is not that different, depending on the specifics it might produce faster results.
You don't need a frontend framework for that. Fuck people who do. They're the reason most websites are slow as molasses on my three year old phone, despite them being very basic sites. Just stuffed to the brim with unnecessary bullshit.
While I agree that there is probably an overuse of frontend rendering when templating in the backend would be fine, I suspect most of the problems you see have nothing to do with that. In my experience, the number one issue with slow sites is an overuse of trackers and advertising that drags everything down.
Precisely. Using libraries / frameworks like React, Vue, Svelte, etc. adds nearly no overhead to the core functionality of whatever it is you're creating, _especially Svelte,_ since it compiles down to the bare minimum necessary to power any dynamic functionality (it doesn't ship with a complete runtime), and supports static templates and markdown out of the box.
I can say with confidence that unless I royally screw something up in my component lifecycles or render loops, everything is just as snappy as ever. No latency. No lag. Just a zippy fast web app with URL/route changes that fly, fetched data populating quickly, and interactions feeling wonderful -- and that's because said apps I'm developing _aren't_ using any heavy tracking libraries.
People are too quick to blame slow performance on modern view libraries, and even likelier: they've never used them before.
If you statically export you won't even notice, and when navigating it will actually be a lot faster when only the content is replaced..
Have you checked this is the reason? not slow network? and not ads/analytics and blocking assets? That's not exclusive to frameworks btw, and probably less likely as most optimize these things for you.
The website that is linked originally has a bunch of blocking assets.. lighthouse score is not amazing either.
Just like the original article, you might want to test your assumptions a bit more.
“95% work is done on large project” this perception might just because you have chosen complex frameworks. Remember google and facebook starts with no frameworks at all. Are they small projects? No.
I'd be more than happy to see small or medium projects and how these tips improved them. Any real world examples would be great.
I would also add that a lot of us do work on the bigger projects, which makes sense as bigger projects require more people. So at least in my life, and I expect many others, it is quite relevant.
I also don't believe the article qualifies that these tips are only for small to medium projects, I'd read it very differently if it did, but I would still like to see some real world examples though.
> In my view, the web is 95% small to medium projects.
I'm not sure that view is correct. For one thing, I'm not sure how you even define this.
As technology has advanced, many of the "small/medium" projects that used to require lots of dev time have turned into fully-built alternatives. The days when you need a dev to setup a blog are gone, as are the days you need one to setup a store, or a simple marketing website.
Are these part of the 95%? In some sense, yes, but in the sense of giving advice on a framework to choose, not at all, because no dev will even be making that choice - it's irrelevant.
As for medium-sized projects, there are tens of thousands of small, internal company tools that aren't even on the open internet. They probably fit your definition of being medium sized, let's say have a few devs working on them for many years, certainly medium sized compared to FB etc - but I'm not sure that whether this approach is right or wrong for them. (Genuinely not sure!)
I'm just saying, you need to much better define what you mean by small and medium sized, because some people might be thinking of my definition, while for some people medium-sized is, idk, AirBNB, which is tiny compared to FB but gigantic compared to most projects out there.
I would say that explaining where guidelines are applicable is on author side.
For text at hand I understand that author expects this way should be “the best” for everyone.
Then author gives examples that even in medium project at first requirement change or first additional non-trivial rule are going to have 2-way bindings plus bunch of other plumbing implemented where “html first” doesn’t have it and someone will have to write some JS monster to handle state etc.
Their second principle, to use inline styling, makes it harder to create a consistent look across the entire website. Defining that in one place and referencing it everywhere is better and easier.
I tried to push for an "HTML first" style frontend at my job, but we hired some run-of-the-mill frontend devs and they basically didn't get it and just wanted everything to be divs with VueJS controlling all of the logic and content.
One semi-objective thing we lost was accessibility. Much of the site is impossible to navigate via keyboard due to naively re-implemented behavior like links being divs with click event listeners. It's actually somewhat worrying - when regulations hit us, we'll have to scramble hard to get back what we threw out.
But all in all I kind of agree with you that it's very hard to find high profile examples of sites that are "HTML first". I believe in it, but haven't actually seen it pan out. But I suspect the reasons for it not panning out might be purely in education. By the time HTML became powerful, frontend dev education was already deeply framework-focused.
> it's very hard to find high profile examples of sites that are "HTML first"
Because the tools to create it are relatively new, and the sites you're speaking of had already been written. What high-profile site didn't already have a massive legacy React/Angular/Vue codebase, and a team of framework-trained developers, as of 2021?
If the rendering framework doesn't support accessibility as a first class citizen (or better yet, automatically creates/makes accessibility part of what is rendered), then the framework is not suitable for production use.
React simply diffs the DOM and updates it in an efficient way. If you are putting weird divs instead of anchors and buttons (or instead of special components provided by a React-based framework), that's entirely on you.
if you're using react and then hand roll custom components and don't do accessibility, then it's just as bad as choosing a component framework which doesn't do accessibility. I am not talking about react (or any framework directly) specifically.
> entirely on you
of course - choosing a framework or hand rolling one makes no difference. It's still not production ready, if it doesn't have accessibility built in.
I think the point they're making is that you'd have the same problems with developers working HTML-first. Accessibility does not simply come for free in either situation, you need to make sure it's present.
Choosing, for example, whether to use a div with a click handler, or a proper button, is a decision you need to make regardless of whether or not you're using a framework.
So it seems incorrect to say that you lost accessibility in this case due to the framework. You lost accessibility due to developers who didn't understand the web platform well enough to design proper accessible controls. If they hadn't used a framework, they'd probably still not have made the site accessible.
> developers who didn't understand the web platform well enough to design proper accessible controls.
And i actually think that it is _better_ for a developer not to have to do their own accessibility controls, but delegate this problem to the component framework. They have to know about the problem, but not have to spend cognitive budget thinking about it while they compose their UI from framework components - this should _automatically_ be taken care of by the design of the framework.
But you're using the same component framework regardless of whether you use React or not: it's the same underlying elements that you decide between, and the same process of configuring then correctly to be accessible.
For a frontend developer who is younger than jQuery, starting a project following this advice would be a good opportunity to learn why we do the things we do like build steps, and remember how much development sucked before HMR.
I suspect the author hasn't actually done this on a project with more than one person, supporting 99% of browsers in the wild. I also suspect they didn't run their own code, because either my screen is not as tasty, or "onlick" is not an handler of div.
Do you find that your team often has to reinvent the wheel in terms of what libraries like React/Vue/Svelte have to offer? Doesn't that increase time and scope tremendously?
I actually find that I often have to reinvent a lot of the browser's wheel when using React and friends, so it's often a wash.
Complete back button support beyond what the router offers, saving search/sort/filter in query string so users can copy/paste/bookmark/back/forward, handling connection and other errors gracefully, loading, accessibility, having to wrap Vanilla JS components into their own framework-compatible components, having to update things in different parts of the screen. And the last often requires a total paradigm change in terms of how data is handled in the app thanks to the introduction of state managers (React-sans-Redux looks totally different from regular React). All those require extra work on every project I worked, and no, libraries often don't solve them completely or as easily as it is with previous backend tech.
These frameworks are also steering a lot of software into some very problematic product decisions. Like using fancy third party components where stylized native would suffice (and be more useable/accessible), using date pickers for absolutely everything that looks like a date (it sucks to type your birthday in those unless you were born this month), saving things in the browser instead of in the backend (so the site looks different in different computers), or just having some specific UI-framework forced on you so you have to use a certain framework.
There are obvious advantages to frontend frameworks, and I'm a big fan of React/Vue/Svelte. I really like those things, been using those for years and I was doing what used to be called "DHTML" since the late 90s. But it takes so much more complexity than the average web app to reap those advantages... IMO they are definitely overused.
Vue.js has led the way on HTML first in a lot of ways. You can pull it in with no build step, you can add dynamic content to pages without making it a SPA, and it mostly works through overloading HTML attributes for basic use cases.
Good old times, I used to have a file watcher that would refresh the page on change using a browser extension, not anywhere near the convenience of HMR though haha.
I do agree with you, it's why I'm skeptical about the results of following this advice. I vividly remember how much things sucked, and obv the web has come a long way, but the tools have gotten even further. If I see how much mileage I get out of the tools I use on the daily, I would not be nearly as productive without them, and produce a lot more buggy, inaccessible, and shitty apps.
> starting a project following this advice would be a good opportunity to learn why we do the things we do like build steps
Honestly, and sarcasm aside, I think this is an incredibly important thing for any new web developer to do.
Trying to learn web development in 2023 (or even in 2014, when I started my career) is so hard, because you're constantly standing on top of the shoulders of giants without even knowing how far you are from the ground.
I started a refresh of my personal site a few months back and resolved to write all the html and css "by hand", vanilla style, as a way of forcing myself to relearn the basics, and it was really refreshing to strip away all the layers of extra stuff and build it with simple tools. And I actually learned a ton of stuff that was useful on a daily basis while I worked on a React project during my day job, stuff that I just had never had to do or learn or use because some framework was always helping me out.
Recently I've been working on a little toy app in Phoenix, and I had the "revelation" that Eex / Phoenix components were slowing me down instead of speeding me up, because I didn't understand the underlying concepts as well as I needed to. As soon as I said "fuck it, I'm writing vanilla html and only using Eex where it's absolutely necessary" I was able to get through a whole host of issues that were giving me friction and actually build what I wanted.
I had a similar experience a few years ago when learning Phoenix. I just didn't get Ecto at all, and the reason was simple - I didn't know SQL and database design. Once I resolved to just figure out how to do the thing I was doing with raw SQL, Ecto immediately made way more sense.
We obviously can't peel back layers of the onion forever, or we'd never get anything done. At some point you have to get comfortable with abstracting away the details. But what I've found in web dev is that the big frameworks are written by people who've done the "vanilla" way so much that they've identified places where things hurt and built solutions that abstract that pain away. That's all well and good when you understand why the abstraction exists and the problem it solves, but it can really be confusing before you've put in the work to gain some of that context.
We have forgotten the old lessons. Backend first was a defense mechanism against people who believe their eyes and not the experts.
When you make a product that looks like it works but doesn’t, they don’t understand. They put you on a path to overpromise and underdeliver.
One of the lesser known features of unit tests are that they give the code that management can’t see more QA prior to being wired up. They narrow that awkward window from first paint to shipping.
I've created my first website in 1999 with plain HTML, CSS, vanilla JS, hosted on Geocities.
Since then I've been using PHP/WordPress/Yii/Laravel, Ruby/Rails/Sinatra/Jekyll, React/Typescript, ClojureScript to create both sites and apps.
With React / TSX components / CSS-in-TS / Effects / Context I'm home. Finally a fully fledged programming language for the web / front-end. A language made explicitly for the front-end, built om modern principles like functional, reactive programming.
Now I can do software development. Before that, with HTML, CSS, plain JS, PHP it was ... just hacking, nothing else. (Rails was good for full-stack, was not shining on the front-end)
I'll skip frameworks when the web stack will be ready for the apps, too. Now it's (perhaps) good enough for sites, I should admit.
It's worth mentioning that the friction to deploy a web app is nearly zero these days, depending on how complex it is.
As an example, shipping a macOS or iOS app, via official means, requires a lengthy review & approval process, upfront costs, buy-in into native languages with little to no use outside of these platforms, a limited selection of tools, and hard decisions about which version of the OS to support based on the features you need vs. the market share of older versions.
People (and teams) choose web development for the lower barrier to entry, and as a platform, browsers get products most of the way to their goals, and fast.
My preference is local first desktop applications. Sometimes it’s because I prefer files, sometimes it’s because native apps are more fluid and more egonomic.
What about for getting quotes on insurance? Or booking a restaurant? Or a flight or hotel? Submitting your taxes? Getting printable directions to a trailhead? Proving feedback on someone’s Figma document? Previewing a 3D model before getting it printed…
Is it your preference to install a new local first desktop application any time you wish to do any of these things?
That depends where the data and the logic all. If they only store the data, but I’m doing all the computation, it may as well be a local app (figma, the 3d viewer..) or at least have an API so I can build my own interface.
I’m not against Web Apps, but many take my browser as free real estate.
The line is very blurry, and the moment you'd like dynamic, interactive content embedded within that static content is when it's time to reach for a view library like React.
At that point, I'm just going to start the project with React / Vue / Svelte every time because almost 100% of the time, I realize I need to support the features they offer that raw HTML/CSS cannot, or if they do, are very poorly implemented by browsers, hitting limitations with them that become frustrating and prevent you from achieving the scope you're aiming for.
Using any of those three libraries/frameworks is painless, and I can get a project going rapidly and with high confidence that I can support any functionality, interaction, animation, content, routing, and other common web problems, with great ease.
All of the technologies you used previously were considered "finally fully fledged" until they weren't!
We will be doing something different in a couple of years and saying that the stuff we do now is out of date and the new stuff is home. It's always been this way. We are tech nomads finding ourselves new homes as and when we move on.
Using PHP and other tools/frameworks that tightly coupled the frontend to the backend codebase made life miserable. While I was excited to get into web development back when these technologies were popular, they were anything but pleasant to use.
With the introduction of Angular 1.x and eventually React, Vue, and Svelte -- creating web apps finally felt productive, easy to debug, and easy to ship. Wiring up interactions finally felt intuitive. No more jQuery code colliding with itself as you struggle to organize your project and cobble together a bunch of poorly maintained "component" libraries and pray they work together without obvious user-facing bugs on your site or app.
Or worse: on a team of engineers.
I won't lie, learning how early build systems worked was a pain, but the curve was completely worth it, and I wouldn't change a thing. Today, using tools like Vite with their default project templates is almost too easy, and you can hit the ground running in no time.
Publishing to Vercel, Netlify, and other modern hosting stacks is a breeze, and they all support direct tie-ins with every popular package & build system.
"I really don’t see how these would work in anything other than very basic scenarios, even less how they would achieve the objectives."
Well, what are the objectives? If they are complex, so should the code be complex. That's the nature of our job. By adding an advanced framework you up the complexity by default. Instead of adding more code, you add more build dependencies. This is especially wasteful on websites.
In my opinion, people today are afraid of writing code. Everyone wants some framework to write code for them. That is not how we push our industry forward.
No one is afraid of writing code, we're afraid of maintaining code, and solving tedious and repetitive problems that already have solutions. Frameworks abstract complexity, which in practical terms decreases the complexity I personally have to deal with, and shifts the complexity to the minds of a team of open-source developers who support the framework or library in parallel. Abstraction is exactly how we push the industry forward, not by building less, more basic, and shittier applications in a some faux-noble quest to use inline event handlers.
The chances of this happening before your project is obsolete are pretty slim.
Edit: it depends on what you mean by "bites the dust". If you mean "isn't cool anymore" then I'd say that's kind of irrelevant. If you mean "isn't supported anymore", I don't see that happening any time within the next decade at least. Rails isn't cool anymore but it's still supported and lots of people are still (more or less) happily using it at their day jobs. React is so widely used it'll be kept on life support long after it has been supplanted by something better, if and when that happens.
>React is so widely used it'll be kept on life support long after it has been supplanted by something better, if and when that happens.
React might be 10 years old, but it changed like 5 times during that time.
Something built in first or second version of React is pretty much an entirely different framework at this point. (Would it even build with using the newset toolchains?).
It's almost disingenuous to ignore that fact.
So while it's unlikely that there won't be a thing called "React" in the future, it's not that crazy of an idea.
React's first flavor (class-based components) are fully backwards compatible with today's React versions. It doesn't seem odd to me that a popular library identifies its pain points and improves its APIs & patterns over time. That's the beauty of open source software with large communities guiding their growth.
Today, it's moving heavily towards server-side rendering because the client-side / SPA format is already quite mature. Their approach with server components is an optimization path that uses concepts/patterns from already popular server-side languages and frameworks + templating, and blends them seamlessly with client-side development, giving engineers the best of many worlds.
This was a natural evolution from NextJS which popularized this way of using React, and it's giving engineers more choices in how they build + optimize their apps.
No you're right, but the benefit is: a more consistent dev experience across client and server-side. Being able to write the same components in either environment for specific optimization purposes (static rendering vs. interactions) is a huge plus. It reduces the cognitive overhead of context switching between languages and technologies.
When there are so many projects that run on React, and so many companies rely on React, it's inevitable that it will be supported for a long time to come, even if it would go out of fashion.
And speaking from experience maintaining React apps is quite nice. React has great backwards compatibility, and where it doesn't there are usually codemods available. Dependencies can be tricky, but that's not exclusive to React.
Also don't forget React evolves, backed by multiple #huge companies, and still innovating.
I love maintaining and cleaning up code (I will insist on cleaning up according to my taste even if it already works fine in production, just like when I carve the turkey I eat some crispy and fatty pieces hot from the oven) It takes a great weight off my short term memory and ADD that I know that the code already worked, so if it stops working, I did it, recently.
But here's the thing, hot-shot devs, and hot-shot dev wannabes look down on maintenance; and humans are social creatures, me included. So I'm not going to do a job for you that you look down on, unless you carry me in (and out) on a sedan chair.
Same for writing doc, I'm good at it and enoy it, but there's no pleasure in doing something that other people don't really value.
Better than maintaining vanilla JS applications that reinvented React for no d*mn reason. At least there's a massive pool of engineers who could jump into an old project and work on it right away, rather than wading through some clever engineer's buggy attempt at a view state management system.
Popular backend templating systems face the same problem with possible sunsetting and decay of collective knowledge over time.
React is a great investment, and is here to stay for a long time because its team (and community) are massive, and are keeping pace with newer libraries/frameworks that are in a lot of ways doing things better. React's market share has hardly been touched by Vue, Svelte, Solid, etc. and less so by HTMX and other new attempts at un-frameworking the web.
I'll enjoy that a hell of a lot more than I'll enjoy doing the same thing on bullshit vanilla code I scratched together myself under the pressure of a deadline, lol.
In some sense I agree, I am very mindful of the dependencies I add and I am not afraid to write something custom if that better fits the situation.
But this article is not showing me how to do that and the things listed are not going to have an impact on the complexity of my projects as these basic things are solved quite well.
> By adding an advanced framework you up the complexity by default
If you know your project will remain simple then by all means. That's often not how it works though and then you end up writing a framework yourself once the scope gets increased and features are added.
Adding to that that using a framework gives you so many things for free. There are so many aspects to a good website and leaning on a group of people specialising in all those things is often a smart move with better outcomes.
I think the initial complexity might be a little bit higher, but there often is a big return on investment later on, and also immediately in terms of productivity.
I'm not going to stop you from not using a framework, I think it's great to experience it, have been there many times before, got burned (badly), and now make different decisions.
Too many people today are being pointed toward React to do very simple things, like a single-page site that is nothing more than a little text, some images, and a few links out to various other places. These sites could easily be HTML/CSS. There is a lot of complexity for the sake of complexity on the web right now.
The worldwide jobs program that is modern-day Javascript would have you believe that elaborate front-ends are necessary to give end users the experiences they expect, which is an utter pile of lies. What users want is something simple that works.
One of the worst feelings is building a site without a view library like React, getting 80% there, and then realizing you absolutely need dynamic functionality and/or state management because the project's scope changed or started calling for it, only to realize you now need to refactor much (or all) of the site to make it easier to maintain across the board.
This is why I reach for a view library like React, Vue, or Svelte, even if I'm creating something simple. This is because I'm familiar with using these and they provide me with the ability to implement nearly any kind of dynamic functionality or interactions I could want, fine control over component lifecycle, and tight integration with my CSS library of choice to speed up development.
End-users are none the wiser, that is of course unless I do a terrible job using these tools.
For personal projects I usually use Astro[1] solely because 90% of the stuff I am making doesn't require anything more than basic HTML/CSS and maybe a couple static components, but I also have the flexibility to add SSR rendering or even more dynamic components like Svelte without making an entirely new project.
Astro is an excellent choice! I've never used it, but always wanted an excuse to. I think it blends the best of both worlds, and the fact that you mix various view libraries is powerful!
I have a suspicion the reason most people reach for a framework is primarily about two different things: modern tooling (modules/bundling, typescript, etc) and templating. They don't really "need" a virtual dom diffing rendering pipeline, but the fact that you get all these other things out of the box with little setup is what makes it the go-to solution.
Then of course you're left to reimplement basic browser functionality that you now lost (or more likely, you just grab another package that solves that and throw it in your payload).
Not in a way that scales, if you need it. It all depends on the problems you're trying to solve, and if it gets to a point where I feel like I'm reinventing any of the popular frameworks, I'm just going to use them instead.
Even if this isn’t always practical for larger projects today, I would argue that this should “ultimately” be the goal—-at some point the “standard” browser runtime should be expressive enough to not require lots of tooling to make most apps.
I'm not sure that's always the case — we don't expect assembly to be a high-level language after all! The more specific and batteries-included the browser becomes, the harder it is to go off the beaten track. My standard example here is date pickers — theoretically it's just a simple component, and yet there is no one-size-fits-all option. What works for booking an appointment won't work as well for putting in a date of birth. What works for a date of birth won't work if you're trying to book a set of nights in a hotel. You might want to include prices for individual days directly in the date picker. You might want to show which days are valid and which aren't. You might want to show several months, you might want to show just a week.
I don't necessarily disagree that more components in browsers is a bad thing (I've been very happy to use the new modal element, for example), but I think the browser is working better right now as a lower-level (albeit still fairly high-level) platform that allows people to build a variety of documents and applications on top.
Counterpoint: The article is titled "HTML First" not "HTML Only"
Admittedly I had the same reaction you did as I was reading the article. All I could think was how poorly these approaches would scale when the need arose for even modest ly complex state management.
While the body of the article doesn't address this, IMO the title does. I think it's generally good advice to suggest only reaching for the tools intended for complex environments when they become necessary, not before.
How is that a response to "Not everything has be a Large Enterprise Application."? If I said "not everything has to be blue" would you reply "what's one thing that's blue?"?
To be fair, 37 Signals (Basecamp) which is behind ruby on rails, changes their front end philosophy with every new major version of rails
And to be fairer, it's generally a pretty good philosophy for greenfield apps at that particular point in time, but if I started an app on rails 4 or 5 there's no way I'm updating my front end every time they change their minds about how front end should work
They believe this now, in 4-5 years it'll be XYZ next thing
People buy into ideas and once they've paid the price, they dislike when that investment is challenged with new information. The resistance that I see in these thread to the idea that going back to HTML might be enough, to me looks very much like that.
Basecamp (formerly 37signals) has a track record of challenging the status quo, whether in business or engineering practices and to actually be fair, they're not changing their front-end philosophy on a whim or to simply follow a fad. They're trying to solve real problems. In the past, their flagship product served as proof that exposed many established counter-advices as merely baseless beliefs. Over the years, they've demonstrated how many "bad ideas" could actually work better for you, once you allow yourself to become a bit more pragmatic.
They might not be BIG, but they're also not small. Imo, what they say and do engineering-wise tends to matter much more to average developers than what Facebook or Google might recommend.
I think the question stands, is Basecamp a good enough example?
I think this is a rational strategy. They aren't changing concepts just randomly for that alone. As we learn problems with the last approach we try something new to address it. If you're starting a new app green field this is an ideal time to try to shed some baggage.
It's been a while since I used it but I did a limited trial of Hey and it was genuinely miserable to use. Not only did everything take a few ms extra, the entire interface was so incredibly janky and had no accessibility concerns at all. They were shipping their website to their mobile apps and it was horrid. I would not put Hey as a shining example anywhere for this philosophy
It's been a long time since I used Basecamp but that was decent enough
If they did I'd honestly love to get the details and be proven wrong.
With just this list it's hard to imagine how this would work.
The only scenario where I can sort of imagine it being potentially helpful is an agency setting with many not-too-complex projects and limited ongoing development. I can imagine updating projects being a hassle. That said I don't have experience in that field, and I bet there are other ways to deal with that.
There are some bold objectives at the start that would be wonderful, but I’m a bit disappointed by the advice. I really don’t see how these would work in anything other than very basic scenarios, even less how they would achieve the objectives.
I’m all for using the web platform to the max, and I’m absolutely for reducing complexity as much as possible, but I’m highly skeptical these principles will achieve that and I would not be surprised if it increases complexity by having multiple ways to do something.
With peace and love but I can’t see from this list if you actually put these principles to the test or you just assumed it will do what you hope it will.