19:59 CET Framework 138 Comments 104
Ask HN: How does one build large front end apps without a framework like React?
111–120 of 197 posts
Re: Ask HN: How does one build large front end apps without a framework like React?
#112I've abandoned Next.js and React for Elixir / Phoenix. I am able to build a perfectly pleasant user experience with just a sprinkle of vanilla JS via Phoenix hooks. The fact that I have been able to build a multi-user collaborative editor experience without a single additional dependency is incredible. I previously worked for a well-established and well-funded React team who had this feature on their roadmap for half…
I'm curious what is specific to Phoenix that made this so productive for that project? Is the frontend using something like HTMX?
Re: Ask HN: How does one build large front end apps without a framework like React?
#113Earlier quoted context omitted.
> 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 com…
Agreed... I quickly ejected from the couple CRA projects I've used and quickly switched to Parcel, then Vite as they matured as it's just a much better experience. Not nearly as bad as trying to update some of the testing frameworks.
Re: Ask HN: How does one build large front end apps without a framework like React?
#114The important thing in any "large" application is to set consistent patterns for doing common tasks: creating UI components, re-using them, updating their content as a result of data changes (reactivity), etc. This can be done with or without a framework. A framework establishes a large portion of those patterns upfront. If the framework is a popular one (e.g. React) rather than an in-house one, it makes it easier to…
Thank you for your comment (and replies). This makes me realize that we can also actively choose which patterns of a framework we want to use, and which aspects of a project are better built to work independently.
Also, so cool that you got to know Silver! Their team is small but very talented, I look up to them a lot.
Re: Ask HN: How does one build large front end apps without a framework like React?
#115there's design principles behind css js and html and people don't bother to learn them and instead want to shoehorn what they know into these languages. Take the time and actually learn the elegance of these underlying languages and use them properly.
I don't know why people continue to refuse to do this.
Re: Ask HN: How does one build large front end apps without a framework like React?
#116I'll add a secondary, or implicit, criteria that the approach you take should not require a 'build process' for the front end app. M -> the MODEL is managed by the backend server, or in-browser via WASM V -> the VIEW is defined by the HTML and CSS C -> the CONTROLLER can be solely Javascript in the front-end, solely backend server processes, or most likely a mix of the two
model is html
view is css
controller is js
that's why there's 3.
Re: Ask HN: How does one build large front end apps without a framework like React?
#117There's a lot to learn from next gen app tools
- Svelte seems to be fast and simplifying complexity - Laravel is likely the most complete end to end ecosystem I can't rule out. Their hotwire tech is impressive and all built in. - Rails has something similar I believe
It depends on your app too.
React definitely can be heavier than needed especially if the client experience doesn't heavily benefit from it or there's other ways to achieve it.
Re: Ask HN: How does one build large front end apps without a framework like React?
#118> 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. Hooks are only 5 years old. The docs were revamped 2 years ago and there's lots of dead links to the old docs page which has a scary warning "These docs are old and won’t be updated." Create-react-app was deprecated in February of this year and in their blog post they tell you to use frameworks like Next.js. And then there's the ecosystem. Next.js…
Most of your complaints are about things that are not React. Those are optional. I can still standup a vanilla React stack in an afternoon just as easily as I did 5 years ago and immediately start writing the exact same code and have it "just work".
Re: Ask HN: How does one build large front end apps without a framework like React?
#119The 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. Having spent the last 20+ years building Web apps, I've only just started using React, due to…
So, how do you manage reactivity? Manual DOM patching?
Yeah, it's not that big of a deal.
This whole thing about "absolutely everything must be pure, functional reactive code" is just something that people used as a cudgel to get their fellow developers to adopt React. And React isn't even pure, nor does it really do reactivity right! But it makes for cool demos where you can throw together TODO-APP really quickly and never mind that real world applications have much more, cross-cutting complexity that just can't fit into the reactive paradigm.
Yes, managing program state is hard. Full stop. React doesn't actually solve that problem. In fact, I think it makes it worse, because of how top-down, everything-should-be-props it is. Elements should be able to inspect their children. Elements should be able to move them around however they want. And those elements should be written to just take it.
There are major parts of React's modern design that point to the fact that it was clearly taken over by functional programming weenies (not that I hate functional programming, just the kind of people who insist it's the only way).
We only have to look at Hooks to see why. Hooks must only be called at the top-level of a component. But where do Hooks come from? Regular imports that are then accessible anywhere. It violates the open/closed principle. What should be a protected method of a base Component class, so that only implementing child classes can call it, is instead possible to call from anywhere with no indication it's wrong until runtime. That's just bad design, in OOP or FP. Someone, somewhere at Meta, decided "Object-oriented programming is wrong" and went out of their way to avoid it.
Re: Ask HN: How does one build large front end apps without a framework like React?
#120A few years ago I rebuilt a 3D model checker for the building industry and intentionally avoided a full frontend framework to keep the UI performant.
I wrote a small internal mini-framework to follow the MVC pattern and Web Components for reusable elements. I also used external libraries: three.js for 3D rendering, sql.js for handling the 3d's models meta-data in a performant way, and @tanstack/virtual for virtualizing large lists and tables.
The biggest benefit was finer control over performance. The main downside was a less comfortable developer experience — it’s harder to find polished, ready-made vanilla-JavaScript components, so you implement more yourself.