Vanilla JS is very powerful and has the features you need to build SPAs without a big framework. Proxies and mutation observers are great for maintaining state, Updating the DOM yourself is fine, view transitions are awesome, etc. The only thing that's hard is routing, but there are lots of small dedicated JS libraries to handle that. Here's one I made that gives you the Express API on the frontend: https://github.com/rooseveltframework/single-page-express
Ask HN: How does one build large front end apps without a framework like React?
21–30 of 197 posts
Re: Ask HN: How does one build large front end apps without a framework like React?
#22> JS frameworks move really quickly React is a lot more stable than I think you're giving it credit for. > And the stability also means that more time is spent on delivering features Frameworks/libs also exist to save you time, thus letting you spend more time on delivering features. And fwiw, the obsidian team seems to agree in principle. Your link goes to a forum post of some kind, in which one may find a link to o…
> React is a lot more stable than I think you're giving it credit for. That's until you have to use it in a real project, for a long time the go to solution was the facebook maintained CRA which is now deprecated. I have spent a lot more time than I'd like to admit migrating webpack versions when it was considered best practises to use class component with decorator but decorator never was standardised in the browser…
These are good points, but many of them aren't specific to React, and in fact likely apply if you're rolling most of your own code. For example, the app that OP used to start the conversation uses webpack (https://help.obsidian.md/credits#Third+party+acknowledgement...).
> running npm install would not give you a dozen high vulnerability package
Yes, this is a serious problem, but mostly an npm messaging problem: https://overreacted.io/npm-audit-broken-by-design/
Re: Ask HN: How does one build large front end apps without a framework like React?
#23MDN has your answer, built into the browser, ready to go:
https://developer.mozilla.org/docs/Web/API/Web_components
If that's not enough, Lit enhances it a bit such that either LitElement and/or litHtml can accommodate whichever style you want: https://lit.dev/
Re: Ask HN: How does one build large front end apps without a framework like React?
#24It’s always mildly amusing how many engineers believe that React is a framework. I personally attribute it to lack of experience—once you’ve used enough proper frameworks, you’d laugh at that comparison. The fact that React is and always has been literally defined as a library right on its website doesn’t seem to stop them.
Incidentally, many of the issues people have with React are attributable to this mistake: knowing what a framework is supposed to be, one might expect React to take care of everything, and when it turns out you’re on your own and using React in a complex project means (whether consciously or not) coming up with a homegrown React-based framework of your own, or using a collection of disparate extras that fill in the blanks (like CRA), by then it’s already a hairy mess of a codebase in a desperate need of refactoring.
React lacks most of framework traits. The library does reactive rendering and contains a somewhat restricted set of low-level primitives around it. Even its DOM integration is handled by a separate, optional library (ReactDOM).
Someone could complain it feels like with Vercel the direction for React is to become closer to a framework (now with RSC and JSX runtime being part of React), but still it is nowhere near a state where the phrase “a framework like React” rings true—and, in fact, Vercel’s interests are aligned with keeping React more of a library than a framework so that more people use Next and are upsold Vercel’s hosting, and Next is in fact a framework in the full sense of the word, comparable to Django or Rails.
Similarly, Vue, Angular, Marko, Astro, Qwik, etc. are frameworks. They provide you with project structure, scaffolding, and a lot of batteries. The fact that many of them are, in fact, using React under the hood speaks volumes.
Re: Ask HN: How does one build large front end apps without a framework like React?
#25I have had some really good results with Alpine.js and back-end templating for simpler apps (especially served from non-traditional embedded web servers). This base plus the combo of what kids these days call "vanilla JS" and whatever other libraries make sense has worked for me for small-to-medium complexity sites. It would easily grow to larger efforts as long as the team did. I think if my sites grew to need larger teams, there would be some value in using frameworks other people have used; this basically means "match the big guys" to make brainpower a little more fungible, even if the tools aren't perfect for the job.
Re: Ask HN: How does one build large front end apps without a framework like React?
#26It depends on the target product.
I'm working with JS for already 25 years. Tried all of the frameworks, and continue on doing it. And every time I try something new, the refactoring flow turns most of them into NextJS (if it's very UI rich or customer facing or something very web-oriented), or Vite+React+Tailwind (client) and Hono (backend) if it's more of a tinker toy needing more custom solutions.
The boilerplate with NextJS is cleanest (compared to all the other frameworks) and API is the most straightforward one, and you can safely ignore the vendor lock in. Its just a pretext to hate on NextJS. They all have some kind of a "vendor" lock in. Be it a vendor-or-a-specific-approach-or-whatever-lock-in.
And Vite+React+Hono — simplest to set up for quick experiments, and very powerful with minimal boilerplate. Will probably create a starter for this one, as I have been using this stack quite a lot lately.
EDIT:
You can pretend vanilla JS is all you need, but then your app grows, then you suddenly need types, and state, and more events and their handlers, and SSR or something else. Thus React has been the most stable bet for quite a while for me now.
Re: Ask HN: How does one build large front end apps without a framework like React?
#27As someone who does both a lot of app development and web development I’m always kind of confused about how insanely far behind the majority of the web crowd is on these topics and I largely put it at the feet of React who went off on a wildly different direction and ended up making a huge mess in my opinion that huge numbers of people will swear is somehow a “best practice”.
My advice is to go and learn a proper architecture (MVVM is a great fit in my opinion for MOST things) and then figure out how to implement that with something you enjoy using. My only bit of advice here is that the closer you stick to the underlying web platform the better off you’re going to be so if you want a concrete recommendation something like Lit here gives you all the primitives you need along with great performance, documentation and developer experience.
Re: Ask HN: How does one build large front end apps without a framework like React?
#28> JS frameworks move really quickly React is a lot more stable than I think you're giving it credit for. > And the stability also means that more time is spent on delivering features Frameworks/libs also exist to save you time, thus letting you spend more time on delivering features. And fwiw, the obsidian team seems to agree in principle. Your link goes to a forum post of some kind, in which one may find a link to o…
> React is a lot more stable than I think you're giving it credit for. That's until you have to use it in a real project, for a long time the go to solution was the facebook maintained CRA which is now deprecated. I have spent a lot more time than I'd like to admit migrating webpack versions when it was considered best practises to use class component with decorator but decorator never was standardised in the browser…
I agree with the Next shitshow, but webpack/CRA was always shaky while Vite's sane defaults (and great reloading) has been a great improvement for us outside of the Next world and functional components now feels like a fairly non-error prone and simple way to work so I don't see that going away for a long time (and has already lasted a bunch of years).
I think the only shaky moving part for us right now is styled components being left behind due to the RSC changes, but there's both mostly source compatible rewrites as well as perhaps even better alternatives (vanilla-extract).
Re: Ask HN: How does one build large front end apps without a framework like React?
#29The reality is that DOM is pretty high-level already. It's just not that hard to do. The only things that have improved my productivity over the years are:
A) getting better at handling graph data structure,
B) learning how to use Regular Expressions as a code editing tool,
C) quit chasing every new thing, and
D) Typescript.
JSX encourages sloppy HTML. Props are are overly verbose. Hooks are a nightmare. Contexts are gross. Portals are a stupid hack for the very, very stupid reason of making it nearly impossible for parent elements to read anything about their children. The whole "props down, events up" paradigm is woefully naive and half of React exists to get around it because of that.
So yeah, if all you know is react, you've already been on the hard path.
Re: Ask HN: How does one build large front end apps without a framework like React?
#30> JS frameworks move really quickly React is a lot more stable than I think you're giving it credit for. > And the stability also means that more time is spent on delivering features Frameworks/libs also exist to save you time, thus letting you spend more time on delivering features. And fwiw, the obsidian team seems to agree in principle. Your link goes to a forum post of some kind, in which one may find a link to o…
> React is a lot more stable than I think you're giving it credit for. A lot of the HN zeitgegist would have you believe React is the opposite, sadly.
The React ecosystem moves really quickly, and likes to re-invent wheels.
But React core APIs remain relatively stable, I've been using React the same way for many years at this point, and you can ignore the parts you don't like, like I'm ignoring hooks and haven't found a single use case where I needed them.