Live data from Hacker News

Ask HN: How does one build large front end apps without a framework like React?

news.ycombinator.com

71–80 of 197 posts

Re: Ask HN: How does one build large front end apps without a framework like React?

#71
post #56

They will write their own framework of sorts in any case.

I don't think this has to be true. If you think of a framework as a piece of code that calls you where you sort of supply it with configuration you could do that when writing vanilla js but you don't have to. When I write vanilla js I don't have a seperate file called framework.js. There is very little code needed to manage state. Almost all functions in my codebase are doing concrete things.

I mean in a complex enough application you'll have to come up with some abstractions that will make you life easier anyway. I doubt that you will manually add and remove classes, or add and remove nodes via direct DOM API calls every time you need to do that. You know what I mean? A set of such abstractions is what I call a framework. It doesn't have to be a separate file called "framework.js". It may even be more of a library than a framework. But I believe you will inevitably come to that to centralize certain things and make them easier to do.

Re: Ask HN: How does one build large front end apps without a framework like React?

#72

It’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: know…

https://en.wikipedia.org/wiki/Software_framework>

Re: Ask HN: How does one build large front end apps without a framework like React?

#73

> 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 introduced app router 3 years ago and lots of docs for libraries still assume you're using pages router. Remix is now react router v7, and I have no idea what's going on with all this Tanstack stuff. There's a new typescript compiler called "Speedy Web Compiler" which just came out in April and as a result Vite now has 4 options for creating a new React project: react, react-ts, react-swc, react-swc-ts

Meanwhile moment.js has had 5 releases in the last 4 years. 3 of them in 2022 and 2 in 2023.

Re: Ask HN: How does one build large front end apps without a framework like React?

#74
Back in 2000ish, a singular dude built a full-blown bank teller workplace app using IE4.0 proprietary features and client-side JS. Server communication was done by posting a form into a single-pixel frame and then looking for objects in the DOM of the returned html. It was fast, robust and scalable.

You have been conditioned to think frameworks are necessary. That’s not true. You can build anything without them and it would probably be better in many ways. Would you spend a ton of time? Yes. Would your code be harder to maintain? Yes. But it is absolutely doable and not as hard as you’d think

Re: Ask HN: How does one build large front end apps without a framework like React?

#76

> 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…

> Hooks are only 5 years old

7. Worth saying that React really only took off 9-10 years ago, so hooks are damn near the beginning of time for _most_ react devs.

> 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.

IMO those are not dead links. A link is 'dead' if it links to a page that doesn't exist. Links to old pages with warnings are appropriate in many cases. Many projects are using older versions of react, and devs need to look up info. Not sure this should be seen as a problem.

> Create-react-app was deprecated in February of this year and in their blog post they tell you to use frameworks like Next.js.

Not sure why this is a problem. A very early tool got deprecated, and the react docs recommend the current paradigm. It's not like they're changing their getting started guidance every month, or even every year.

> Remix is now react router v7

If this is a bitch fest about React, then the react docs and CRA are fair game, but remix isn't IMO.

Re: Ask HN: How does one build large front end apps without a framework like React?

#77
post #70

Earlier quoted context omitted.

If you are writing the same DOM update code in each event handler you can abstract it into a function.

What I'm saying, say you have 3 dependent dropdown pickers, selecting an item in the first one determine which of the other 2 are shown. When you have reactive interfaces like that, it's hard to extract the common "business" logic. Either you redraw everything from scratch or you do a sort of show/hide on DOM elements as in jQuery days. Not sure how you can abstract that. If you do abstract it, you end up with backbo…

You are still thinking in terms of framework goodness, which is why this is challenging for you. Don't do that. Don't redraw anything. Don't create some shallow copy, cloned node, or other insanity. You don't need any of that. You don't need to litter your code, most especially your DOM nodes, with a bunch of business logic insanity.

All you need is the event handler. The event handler can be assigned to a node's event property directly, but if this is for a commercial site with lots of third party analytics/spyware you need to use a event listener instead because those third party libraries will overwrite your event assignments. The event handler receives an event object as an argument with a reference back to the given DOM node.

All the business logic should be stored in a single location representing a given business function, typically far away from the browser logic. It makes sense when you write the code without using a framework. If you write the code and try to make it look like a framework it will look like a framework, unsurprisingly. If you don't do a bunch of framework component insanity it will not look like a framework.

This is a person problem, not a technology problem.

Re: Ask HN: How does one build large front end apps without a framework like React?

#78

The 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?

Re: Ask HN: How does one build large front end apps without a framework like React?

#79

> 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…

> Hooks are only 5 years old.

That is a long damn time in this industry, and class-based components still work just fine.

Re: Ask HN: How does one build large front end apps without a framework like React?

#80

Earlier quoted context omitted.

I mainly use React via Reagent in ClojureScript, and literally have no use cases where I need to use useState/useEffects for anything. Turning it around, what exactly are you unable to do without useState/useEffects?

When I want to memoize something slightly complex, for simplicity's sake let's say sorting an array of objects based on one of it's keys. I can put that in a useMemo and it won't sort it again when the page eventually rerenders for some reason. Usually that array is mapped elsewhere and those child components might also re render if the array is recalculated. useEffects are when I need to call something outside of re…

> all criticisms welcome :)

No criticism really. Your useMemo example is the right use. Your useEffect use is fine, but for things like api calls (which 'call something outside of react' may refer to), you're often better leaning on something like react-query, which is of course built on top of useEffect. So still the right tool, but let others handle many of the sharp edges around that problem.

Post reply on HN