Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

91–100 of 197 posts

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

#91

Post by gg2222 »

Octoth0rpe wrote: post #6

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

Unrelated to the topic, but wow, they're still using moment? I thought it was kind of deprecated and been trying to use other libs.

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

#92

Post by rudi-c »

austin-cheney wrote: post #64
dsego wrote: post #52

Earlier quoted context omitted.

Not sure how you avoid reinventing any of the component frameworks. Writing custom JS component backbone style seems tedious and error prone. Manually modifying the DOM on changes means writing the same logic several times, once for the initial render and then repeated in every event handler that has change the state of the UI. Alternatively, you might just be nuking your DOM with inner html and then running everythi…

> Not sure how you avoid reinventing any of the component frameworks. You don't do framework nonsense. That is all there is to it. For most people writing JavaScript for employment it is absolutely impossible to imagine any universe where a couple of lines of code could be written without something that looks like a framework. That is not a limitation of the language, but rather a limitation of the given developer's…

When you're writing only a "couple lines of code", you can do pretty much anything you want. There's no real tradeoffs to discuss except in a theoretical sense, because the stakes are so small.

If the app being built is "large" (which I understand to mean, has high essential complexity), then those tradeoffs matter a lot. If the app is built by a team instead of an individual, the people problems become significant. Those can very well be turned into a technology problem. The technology (framework in this discussion) can be used, among many other things, to establish a consistent way of solving the problems in the application, which alleviates many people problems.

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

#93

Post by Octoth0rpe »

mind-blight wrote: post #84
actinium226 wrote: post #73

Earlier quoted context omitted.

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

I'm gonna be honest, I've been developing with react for about 9 years across a lot of projects and companies. I've never used next. Maybe I'm out of touch, but I don't understand why people think it's so tightly could with the ecosystem

There is a large amount of what _might_ be described as astroturfing on the part of vercel to push Next. More charitably, vercel/the next community publishes a very large number of good tutorials/boilerplates/etc that are built on top of next.js.

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

#94

Post by juston1337 »

You can, but if you did you would likely just reinvent concepts that are in the framework. Maybe you will do a better job (problem is that many believe they can, and so do).

You could even write your own browser that uses python instead of javascript. However, it would only be compatible with python html pages. We stick with JS for web development because that is how the "browser framework" is designed. HTML, CSS, JS, etc. are all just part of that framework. If you wrote your own browser, you would need to reinvent all that as well.

I do not miss the early browser days, where different browsers could have been seen a different frameworks. Things go allot better when the browser framework standardized. I still suffer from the IE trauma.

Allot of what we see with JS frameworks ought to baked into the browser framework, but that process is uber slow, because people have to a agree, and people do not like to agree. But it is magic when they do.

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

#95

Post by rudi-c »

runjake wrote: post #63

Addressing the very first sentence in this post: > I had a mind-blown-moment when I learnt that Obsidian was built without any frontend JS framework. The comment you’ve linked to is wrong. Obsidian uses the Electron framework for its “front-end” framework. In fact, it was even affected by the recent “Tahoe” Electron bug. https://en.wikipedia.org/wiki/Obsidian_(software)#Availabili...

Framework is unfortunately a term that's both ill-defined and quite overloaded. Electron is a framework in a very different sense than the "JS frameworks" op is asking about. The latter is about libraries with APIs and mental models for producing the UI & UX of web applications.

Electron is just a way of running Chrome without the Chrome UI around it, + a few APIs for accessing native OS APIs. You wouldn't say that Chrome/Firefox/Safari are frameworks just because they execute JS code and has APIs. In the context of this discussion, it is fair to say that Obsidian was built without a framework.

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

#96

Post by yawnxyz »

I build a lot of micro sites, but I still use frameworks — like Deno (node alternative), Hono (for APIs), and Alpine.js (for tiny lightweight sites).

you don't have to though!

if you want to do more pure vanilla, understanding signals is really useful — this basically powers svelte's runs and react's hooks and whatever.

I love nanostores, a 286 byte (!) state manager that lets you build highly reactive pages w/o the weight: https://github.com/nanostores/nanostores

flexible tools like tinybase (https://github.com/tinyplex/tinybase) and unstorage (https://github.com/unjs/unstorage) are also super useful

tools like this lets you build highly reactive, engaging sites that load for under 50-100kb

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

#97

Post by ludicrousdispla »

I'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

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

#98

Post by austin-cheney »

rrgok wrote: post #82
austin-cheney wrote: post #77

Earlier quoted context omitted.

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

I did not understand the event handler part. Could you make an example?

    const myHandler = function (event) {
        console.log(event.target);
    };
    
    // this is simple and easier to troubleshoot,
    // but you can only directly assign one value to an object property
    myNode.onclick = myHandler;
    
    // for pages with JavaScript code from third party domains
    // use event listeners instead
    myNode.addEventListener("click", myHandler);
When leaving frameworks you have to stop thinking in terms of components, isolated code islands that exist only in their own isolated world. Instead think of areas of the page as parts of a larger whole. You can manage each part independently or not. You wouldn't program outside the browser using something like React, so your programming inside the browser should reflect how you would build an application if the browser weren't there.

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

#99

Post by actinium226 »

Octoth0rpe wrote: post #76
actinium226 wrote: post #73

Earlier quoted context omitted.

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

None of these are problems taken separately, but put together they're pretty frustrating. Hooks being 5 years old and being the predominant tool for certain tasks shows that the community only figured out how to solve a particular problem 5 years ago. Compare that, in terms of stability, to Python having coming up with the idea of packages a long time ago, and packages are now a stable part of the ecosystem (packaging is another story which I'll get to shortly).

Revamping the docs is not a problem by itself, but take a look at Python or Django, their docs have the same look and feel for older versions of the code. It's totally a minor problem, and if it were the only one I wouldn't be complaining here, but with the plethora of problems it starts to feel like death by a thousand papercuts.

> Create-react-app was deprecated

Going back to Python packaging, while it's much better than C/C++ packaging, people still love to complain about it! That said, pip is not deprecated. For React to just abandon the idea of helping users to create a project and telling them to "go bother someone else about it" does not seems like something a stable ecosystem would do.

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

It absolutely is a bitch fest about React because I inherited a simple site that should have never used React in the first place and it makes it so hard to do simple things without reinventing the wheel, but anyway, I'd say the ecosystem is fair game now that CRA is deprecated and the docs themselves tell you to go to Next or Vite or React Router or Tanstack.

Anyway, the point is that while React might be relatively stable from the point of view of the larger javascript ecosystem, it's still way less stable than it should be and way less stable than browser APIs.

Post reply on HN