I think that this comment is a great example of the total disconnect these conversations always have.
On the one hand we have lots of people on here who are building full-featured web apps, not websites, on teams of 30+. These people look at frameworkless options and immediately have a dozen different questions about how your frameworkless design handles a dozen different features that their use case absolutely requires, and the answer is that it doesn't handle those features because it doesn't require them because it's a blog.
Meanwhile there are also a lot of people on here who have never worked on a large-scale web app and wonder why frameworks even exist when it's so obviously easy to build a blog without them.
It would be nice if we could just agree that the web hosts an enormous spectrum of different kinds of software and make it clear what kind of software we're talking about when we were opining about frameworks—whether for or against.
His thesis was that before arguing about software development tools, practices, anything really, it's vital to establish what kind of development you're doing, because each "world" has its own requirements that in turn motivate different practices and tools.
The worlds he quoted were Shrink-wrap; Internal; Embedded; Games; and Throwaway. Shrink-wrap is no longer a thing for most developers, and we can probably name some others today that didn't exist then. But the basic advice he gave then matches what you're saying today:
We need to anchor arguments about tooling in a statement about the type of development we're trying to address, and we need to appreciate that the needs of each world are different.
This is also why it's often frustrating to try to understand people's opinions regarding programming and code. There's almost always too little context, even without handwavy or subjective stuff like "it's too complex" or general bandwagoning.
Actually, I feel like many times the conversations about code are pretty shallow anyway with not much info. Maybe it's just difficult without properly established context but OTOH that can quickly get complicated and require a lot more effort.
100% this. The biggest problem I see is understanding the context of what you are building. Even inside a SaaS company. Are you building a feature that is a core part of the service or just a test shot to see if its possible to sell,or maybe you already sold something to a customer that is not your target customer. Yhey still need it and should get it. But maybe its more important to be quick and dirty. if its a core part, Then you need to make sure the architecture is good and maybe even add more test then normal. Context matter so much
So much great and timeless stuff was written in the 2000's, it's great and should be part of everyone's read list. Another one that's still pretty timeless is https://randsinrepose.com/
I think a really good example of this is that lots of times even when making a web app, different people make the web app from the people who made the marketing site for selling the web app.
I agree with Spolsky in theory. But in practice, I've been on one project in the last few decades which I actually think benefited from integrating a web framework. The majority of projects I've worked on absolutely did not need JavaScript, and the rest would have been served by an approach similar to what's described in the OP--a few minimal vanilla JS files to create a few web components.
And yet large teams of very smart people reach for NPM as just part of their initial setup process. It's so ubiquitous that I essentially had to learn to not write this way on my own, by asking myself "can I do this without JS"? Almost every time I asked that question, the answer was "yes", and the non-JS way was much easier. But for a long time I wondered if I was wrong--maybe the framework JS way is easier in some way I don't understand--because everyone around me was doing it the framework JS way. It's taken me years of experimentation to build up a preponderance of evidence to persuade myself that in fact, the framework JS way is just worse, most of the time.
Everybody wants to be Facebook or Google, but the fact is you probably just aren't. You probably don't have their problems and you probably don't need to use their tools.
Shrink-wrap is still very much a thing, even if distribution is entirely digital in most cases. It's dominated by internal line-of-business apps, sure, but that was true back then also.
Of course, Shrink-wrap 2020-2025 is not exactly the same as Shrink-wrap 1995-2000. You mentioned digital distribution. Speaking from my lived experience... We shipped software on golden masters that were used to manufacture DVDs at scale.
At that time, the entire software industry worked on long release cycles because of the friction of shipping software on manufactured media. And in those days, people read physical dead tree computer magazines, which had long lead times for articles. This affected software development, because months before we were scheduled to "ship," we were sharing screen shots with journalists, doing interviews, and placing stories in magazines timed to drop when we released.
I remember a death march to get a product ready so that we'd have DVDs to give away at JavaOne in the Moscone Center, where our CTO was scheduled to give a talk. The way software was distributed in those days all strongly influenced the way companies attempted to manage software development.
I work on a site that was built without frameworks with just a sprinkle of jQuery on top of a traditional MVC framework.
It worked great but then the business grew and the software became bigger than what fits in 1 engineer’s head. We now have lots of issues that need fixing.
A good example are pages that take 5 seconds to load because they have to do so much, then you submit a form, and the page reload takes 5 seconds to go through but there is no UI feedback so you press the button a few more times because maybe it didn’t work? Then you get an error because the first action worked but the subsequent actions failed due to uniqueness constraints. Now as a user you’re confused: did you place the order or not? You got an error but the order also showed up in your history. Hmmm
As engineers we have issues understanding what is and isn’t in scope. Will this javascript file you touched affect only the feature you wanted, or another 50 pages you didn’t even know about? When you add a new thing in a template, how many N+1 issues across how many pages did you just cause? Where does the data even get loaded?? The query lives so far away from where you use the data that it’s really hard to track down. Etc
We started putting new things in React, especially the more interactive areas of the site. It’s pretty nice in comparison. Not perfect, but the framework pushing you to think in components helps a lot. I’m slowly introducing this mentality to other parts but the framework really wants to fight you on it so it’s gonna take a while.
I think I will never understand, how people write their code in such a messy unorganized way, that it becomes unclear, whether touching some piece of code changes the behavior on 50 other pages. To me that reeks of badly structured code, with bad abstraction layers, perhaps stuffing too much stuff into a single module or, if the language is still backward and doesn't have modules, a file. Especially for websites, the path to rendering a page should be pretty clear. Have some weird JS requiring menu functionality? Well ... put it in "menu.js". Will it affect 50 other pages? No, it will affect the menu. Or yes, if you count the menu as part of those pages. Have some video player stuff? Well it is going to affect all pages where there is the video player. Something for forms? All pages where you have such forms. Then there are things like maybe animations or checkbox states. But I fail to come up with examples, where the scope of the change is so unclear, that one can't relatively quickly figure out what will be affected and what not. It must be some WordPress mess or something. Then I can imagine it. But with a site built from ground up? Nope, must be bad design or structure.
Of course you could just have made up that example as a straw man as well.
> To me that reeks of badly structured code, with bad abstraction layers, perhaps stuffing too much stuff into a single module or, if the language is still backward and doesn't have modules, a file
Yes and that’s normal. Big ball of mud is the worlds most popular software architecture.
> Well ... put it in "menu.js". Will it affect 50 other pages? No, it will affect the menu
MVC frameworks, used traditionally, don’t support this super well. If you want some dynamic value in the menu supplied by the backend, every view has to make sure it passes that value into the template layer. Change the menu, gotta go around changing every view to supply that new value.
MVC with jQuery or some SPA framework at some point you have to consider why the menu is tied to the view at all, and not deriving its state from the user session. I'd say in either case who decides that (and who rewrites it) is equally messy. The nice part about SPAs is you can usually slice off that functionality and give it to one set of developers to deal with in isolation much easier than you can with an MVC structure.
> why the menu is tied to the view at all, and not deriving its state from the user session
Yes! But it turns out in some of these frameworks “the user session” is not a magic global, your view has to pass it into the template.
And even if it was a global, you are super limited in how much derived data/queries you can compute off of it. Because you’re not using a full-powered language – instead it’s jinja, mustache, or similar.
This is doing the same thing described in the GP of your comment.
If 1/few people are building a site so simple that the menu code is in "menu.js", then sure, separate your code and go about your day. But when 30+ FTEs are building a huge app with lots of tightly interconnected features, then the complexity is there no matter how you architect your code - it's part of the business requirements. Like GGP said, they're different domains, and stuff said about one doesn't necessarily apply to the other.
Nailed it. And a lot of people who say "this sounds like an application, let's pick an application framework to use" from the start are people who have experienced what you're currently experiencing. But it's very hard to describe in a compelling way to someone who has never had the same experience.
But the "looks like not an app, maybe we should not use an application framework" tends to be silenced by "React bootcamp people are a dime a dozen so let's use what they know".
Maybe. Personally I haven't come across this phenomenon. But I haven't worked on this type of system in a very long time, so it's probably different perspective from different experience.
>A good example are pages that take 5 seconds to load because they have to do so much, then you submit a form, and the page reload takes 5 seconds to go through but there is no UI feedback so you press the button a few more times because maybe it didn’t work? Then you get an error because the first action worked but the subsequent actions failed due to uniqueness constraints.
It's been standard practice for at least 25 years to disable the submit button once it is pressed. If you aren't doing this as a developer, you are practically begging for trouble, and it's really so easy to avoid that trouble.
Lots of people build stuff and don’t have 25 years of experience. Or it seemed like “unnecessary complexity” when the app had 5 users and interactions took 100ms.
A lot of standard things feel like “wow people are way overthinking this, it’s so easy” when you have 5 users :)
TypeScript helps a lot – you get quick traceability of where things are used and squiggly lines, if you break a contract. Yes a statically typed MVC framework would get you this, but in my experience the apps that get into this mess also don't use types "because types add too much complexity" (likely true for that company stage).
Componentization brings the other piece – self-contained components that declare their own data dependencies (load their own data), bring their own isolated styling, and generally handle all their internal behavior. This takes some skill/experience to get right and yes you can totally pull it off with every toolstack if you're good enough. The benefit is having a stack that encourages you to think about interfaces and contracts between components and hiding the messy internals from the outside world.
So for example in Flask I'm encouraging this pattern of tiny composable views: https://swizec.com/blog/a-pattern-for-composable-ui-in-flask... Once you have these, you can then move them in and out of the page with some JavaScript and an Ajax call. HTMX does this afaik and it's also how we used to build PHP+Ajax apps for a brief moment 20 years ago before client-side rendering took over for various reasons (smaller payloads mattered back then as did sharing an API between web and mobile)
edit: Point is that an approach based on composability guarantees that components won't break each other, can be moved around, and can live side-by-side without worry. The more your stack can guarantee this (as opposed to manual vigilance) the better.
Thankfully, there's a bunch of great and "easy to get going" languages now that __also__ have types (or optionally encourage them) that the "don't have types" thing isn't as much of a forced issue anymore (though engineers can still choose to go type-free and eventually face the wrath of lack of types in a large-scale project)
> On the one hand we have lots of people on here who are building full-featured web apps, not websites, on teams of 30+.
Photopea is a full-featured web app, not website, written without frameworks by a single individual. It is absolutely possible to build feature rich applications without the framework du jour.
Team of 30 people is not needed to write fully featured application.
Team of 30 people is needed to build, run and maintain enterprise applications. Where you might need 24/7 support and such support requires at least 5 FTE, you might need features changed when 3 people go on 2 or 3 weeks vacations. Maybe that single person will come up with something better to do with their life so you need to have some people to take over.
What parent comment was about, people make broad statements not understanding that world is much bigger place.
Yea it is absolutely possible to build an app the way you describe but it doesn’t work for every app everywhere.
The same of course using React/Angular doesn’t work for everything, everywhere.
You missed the "teams of 30+" part. I believe that a single individual who's dedicated to it can absolutely build a lot of cool stuff without frameworks, but there's a reason why large teams working on complex software tend to settle on them.
The only real viable alternative with a large team is a hand rolled framework, which isn't always worth the trade-off.
Absolutely, and this sort of thing happens in large companies as well.
Software engineers are great at providing “well, why don’t you just..” answers to problems they don’t actually have their brains wrapped around. This often leads to attempts to scale poorly scaling approaches (e.g., we’ll just bake every variant, since there are only four today - which becomes combinatorially intractable after a few years of development).
On the flip side, software engineers are also great at choosing how they’re going to solve a problem before they really have a handle on what they’re going to solve.
I use this maybe 5-10 times per year (and several engineers I work with have taken to repeating it): “tell me what you’re doing but, more importantly, tell me what you’re not doing.”
Forcing people to be explicit about what is not in scope helps to bring clarity to otherwise murky tangles of ambiguity.
Not just some people. There are a wildly unnecessary amount of marketing pages and pages with basic forms that are built using React.
Every time I've been at a company and suggested moving to vanilla css+html or a static generator, the reaction is like I brought up rewriting in assembly.
There needs to be a significant push for simplification of the default toolchain. I understand using React, but reaching for it by default at the beginning should be seen as unnecessary complication.
Especially because it's 100x easier to move from html+css to a framework than it is to move from a framework to literally anything else.
Why not use React for that? If I use React for everything then I don’t have to decide, I don’t have to use two different tools. Consistency is fantastic, if you only use nails then you only need to carry a hammer.
Why use two incompatible languages (JSX and HTML) for different types of web pages, when you could just always use JSX? React can statically render to HTML if your page is really static.
I think what you’re really complaining about is that people use React for static content and don’t statically render it first. That is sloppy, I agree. But it’s not React itself that’s the problem but rather the developers who don’t care what they are doing.
HTML will be around long after React is dead. What guarantee does a React codebase have that its toolchain will still work in 5 years? We've seen build tools come and go, whole approaches deprecated. What if a security update requires upgrading to a non-compatible version of React, therefore necessitating a considerable refactor?
Meanwhile, the original Space Jam website still renders perfectly.
The standards are superior to the frameworks built on top of them. Abstractions come and go, but web standards, once adopted, have a solid track record of sticking around.
In theory, you can completely statically render everything. In practice, every static site I've seen built with React also uses dynamic client-side components, either as a prerendering mechanism, or because there are dynamic toggles and things on the site that are easiest to build as React components. This usually means that a lot of excess Javascript gets loaded on the client that isn't usually necessary.
The islands/RSC work seems to offer some improvements to this, but most of these websites still include a full copy of React on the page to essentially do what the speculation rules API and a `<dialog>` element could do just as easily.
You never have a definitive answer. It's always probabilistic. You make the decision that you think has the highest odds of success at every point in time.
If you're building something with specifications, then what are we even talking about? You know what you need to build so just build that.
But this thread is about what to do when you don't know. "Start the simplest way" is not always the right answer, because you have some information about what you plan or want or hope to build, so you can use that information. Not everything is a set of hyperlinked webpages, and you often know that right away, even when you don't have many details sorted out at all.
I'm not suggesting building a complex system from scratch. I'm suggesting building systems using tools designed to support the kind of system you're building.
Do you think your quote is true in all cases? Or are you implying that choosing to build using a framework implies building a complex system frame scratch?
Consider a different kind of system. Does every triple-A video game evolve from a simple framework-free implementation, or do most of them choose a graphics engine to build on top of? If a game studio chooses Unity from the start, for instance, is it building a complex system that won't work?
How is it any different to choose a web application framework from the start when building a web application?
You err on the side of what's best for your business given known constraints. Usually frameworks make teams more productive, and that's worth more than "simplicity", whatever that means to you.
Replacing non-framework JS with a framework is very hard. Replacing static HTML+CSS with React is much more doable, as it isn’t too hard to transform HTML to JSX.
Yes but if it turns out that you really are building an application, but you didn't think you were up front, it is likely that you started to add "just a little bit of js here and there", because after all each little thing you're doing is not that hard and it feels silly to block any one of those little things on "let's add a framework now". So then you find that you have a "non-framework JS" application that is hard to migrate. That's how path dependency works.
It's true that there is path dependency in the other direction. You implement a framework up front, but then it turns out you're making something too simple for that to really be worthwhile. But very similarly, no individual thing you're doing is a forcing function to simplify things, so you keep doing your simple thing with an overly complex tool.
It always strikes me that people want there to be one right answer for how to start a project, either always choose a framework up front, or never do that. But in my view it's just not that easy, you have to think about what you're doing and make the right decision for that thing.
And if you can point me to an example of that I will happily lampoon them.
If we're talking about Medium, then yes, Medium is a complete disaster zone that should not be emulated anywhere. Their reader-facing use case does not require JavaScript at all except as a light optional seasoning on top.
All I'm saying is that we need to actually talk about use cases whenever we're talking about frameworks, which we almost never do. Failing to specify the use cases turns the conversation incoherent because we end up having two different conversations without even realizing it.
We're building a collaborative IDE for tasks and notes [1] from scratch without frameworks/dependencies.
Not saying frameworks are never the right answer of course, but it's as much a trade-off for complex apps as it is for blogs. Things like performance, bundle size, tooling complexity, easy of debugging and call stack depth, API stability, risk of hitting hard-to-work-around constraints all matter at scale too.
I love it! All ES6, no deps.. probably makes your lives harder than they should be but in the name of pureness and badassery and complete control over performance, awesome!
You choose to suffer for the right reasons.
Wishing you the best of luck and that I can try it soon.
Forgot to say.. I very much admire and appreciate the aspect of "ejectability". More software should strive for this ideal.
Agreed that it's a trade-off. In your case I probably would have made the same call. Again, though: that's why use cases matter. Web app/blog is only one dichotomy—the most common two types of web dev but far from the only.
Maybe there is this disconnect, but half of the react developers I personally met used react: "because it is good on resumes and I don't understand how to work without a framework". So I am not entirely sure we have the whole picture here.
I also write more complex webapps using vanilla webtech (with a strong server-side solution like flask, django or similar). I checked out react it just hasn't clicked yet for me in combination with my serverside style.
A counter example is Filestash [1], a full fledge file manager that can open > 100 file (from parquet, arrow, geojson, shp, raw images, etc...). Since it got moved out of React, the app perform better by every single metric than the original one. While I agree there's no team of 30 behind it, so is tons of software with people blindly defaulting to React for the same reason than people choose IBM: nobody get fired for choosing IBM / React.
You and a few others are missing the point, which means I probably failed to communicate super effectively. Counterexamples aren't really a thing here because my point isn't that you do or don't need a framework for any specific kind of project, my point is that requirements vary and you can't talk framework vs frameworkless without talking requirements.
A blog is just one example of a place where frameworks don't help, chosen because the site OP shared is functionally the same as a blog. Other applications have different requirements and those requirements may also not benefit from a framework. Alternatively, the requirements themselves may actually have benefited from a framework and the authors chose to avoid them because the team preferred not to or because they felt strongly about avoiding frameworks because of personal preference.
In this case, this project has really one active contributor [0], so it's missing one of the key ingredients that in my experience really call for a framework: coordination between a large number of people.
(And lest I be mistaken: just because a project has a large number of people does not mean a framework would for sure be the best choice. I'm sure there are counterexamples to that too! It's just a hint in that direction, not an ironclad law.)
I like this framing the most. My personal website is vanilla, and my SPA-like apps are with React. I originally chose vanilla for my personal website bc I thought it'd keep refreshing my fundamentals... but actually its simple enough that vanilla is actually just the correct choice.
> I think that this comment is a great example of the total disconnect these conversations always have.
If we're being fair, the same could be said of this comment, which goes on to make some assumptions. One guy giving an anecdote that is not a web app does not prove much. I've built award winning web apps with progressive enhancement. It takes less code, less time, the performance is better, and they can be just as interactive. We need to stop looking for the weaknesses in each other's arguments and look for their strengths. I'm guilty of this as well.
I think you're reading into my comment implications that I didn't intend to put there. The point is that situations differ and we need to be explicit about what kinds of situations we're talking about when we're sharing our opinions on the suitability of frameworks. I'm not advocating for or against frameworks in any particular situation.
> It would be nice if we could just … make it clear what kind of software we're talking about when we were opining
Irony here is that OP did precisely this with a link to the precise thing he built. Meanwhile you haven’t offered even a rough description of what you built, much less a link.
I could, but it would be a distraction because my entire point is that there are an enormous variety of apps with a large variety of requirements being deployed on the web. If I give examples that's going to turn into an argument over whether these specific examples actually need a framework, which will turn into a whole bunch of other hypotheticals of situations that would justify it or situations that won't.
Rather than opening up that can of worms I'm going to leave it where I left it.
I'm not trying to be pretentious, but wrangling an HN thread is hard and I don't have time to get into an argument about a bunch of different implementation details. Rather than just ignore your post I decided to respond explaining why I couldn't answer.
The only valid short answer is what I said: that it really depends on the details and how they all work together. I truly can't give you features in isolation that won't be questionable, because the decision hinges on the whole combination of factors. Had I said "x and y" someone would have come along and argued that X and Y didn't call for a framework because Z. Me identifying the two points would have accomplished nothing and would actually have undermined my primary point of "it depends".
Edit: btw, I just corrected the downvote on your original post with an upvote. Whoever did that probably assumed you were being belligerent, but that's not fair.
I think that this comment is a great example of the total disconnect these conversations always have.
I just pointed out that frameworks are not always necessary.
>> In this case: this is a WordPress blog.
No. It is not a "blog". It's a news site. It uses WP as a CMS. That does not make it a blog, and comes across as nothing more than an attempt to belittle it. The New Yorker, with its 90 year archive (at the time) was run on WP too for a time. Its used by many major publishers.
If you look at other news sites, be it NYTimes, Polygon, Verge, Wired, etc, most of them use frameworks to some degree. React, preact, svelte, whatever. It works for them. Underscore, and Backbone are two frameworks that were developed at the NYTimes. Its not alway necessary, and you can still do a lot without them.
It's not an attempt to belittle it at all, but as far as I know a news site and a blog have the same feature requirements—the main difference that I'm aware of is that a news site has more traffic and more articles and so may need better caching.
If you're aware of requirements that a news site has that a blog doesn't (and I assume you would be, as the OP and creator of the above site), I'd love to hear it.
Blogs and news sites are both in the "content publishing" space, so yes their requirements will overlap. There's likely a complexity continuum from:
1. Something like a one-person blog published by committing Markdown to a GitHub repository and having that published automatically, all the way to;
2. A journalistic news site that has a full CMS back-end tracking multiple authors/bylines, some kind of editor/approval/review workflow, features for deciding what gets shown "above the fold," linters that enforce style guidelines, specialized search features, &c.
While some blogs can have complex requirements and some news sites might be simple, I hope we can appreciate that there will be some blogs that are much, much simpler than the NYT and this have fewer and simpler requirements.
They're both "publishing words," but the back-end complexity reflects the complexity of the business -processes and model more than the complexity of displaying articles on web pages.
Right, I agree with all of this. My point was always that requirements vary and it's pointless to talk about frameworks-vs-no-frameworks unless you're clear up front what your requirements are.
In this particular site's case, the requirements are met by WordPress, so "a WordPress blog" is a simple description of what it is. It wasn't meant to include a value judgement.
Ah, you're right, I forgot a category: The people who will shamelessly dismiss other people's work and assert that they could do it better no matter how much context you share. This group is particularly fond of leaving dismissive comments without any substance.
If you assign a value judgement to that statement that's on you, not me. I was just providing the missing context: why OP didn't need a frontend framework to meet their requirements.
On the one hand we have lots of people on here who are building full-featured web apps, not websites, on teams of 30+. These people look at frameworkless options and immediately have a dozen different questions about how your frameworkless design handles a dozen different features that their use case absolutely requires, and the answer is that it doesn't handle those features because it doesn't require them because it's a blog.
Meanwhile there are also a lot of people on here who have never worked on a large-scale web app and wonder why frameworks even exist when it's so obviously easy to build a blog without them.
It would be nice if we could just agree that the web hosts an enormous spectrum of different kinds of software and make it clear what kind of software we're talking about when we were opining about frameworks—whether for or against.
In this case: this is a WordPress blog.