Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

>It's very hard to reason about DOM

I don't mean to be overly snarky here, but as someone who's just totally out of their depth in modern web UI - is that why people like these frameworks? Because they're very easy to reason about? I've generally found them to be mountains and mountains of boilerplate and spaghetti, but I really do not have a wide base of experience to pull from on this topic.




I started with Jquery, I learned React. I prefer React.

React complexity is often conflated with things like Next JS or other SPA solutions. React was originally meant to be a library for building small components that you drop into an otherwise static websites. But people usually don't talk about React unless they're talking about whole sites being in React. For that reason, I think its complexity is exaggerated.

More importantly, what the commenter is referring to is the fact that you are encouraged to write Jquery code that can break if you decide to move a div or change a class name. The workflow of CSS selectors is fine for small apps, but can lead to hard to track bugs down the road. It can be avoided if you make a lot of unique IDs. But otherwise you're screwed. There's no scoping. You technically have to read every piece of Jquery code before changing any other code, html, or css, because you could break half the site depending on what people were depending on. There's no IDE support telling you what is selecting what. Events are not colocated on the things they attach to, they could be anywhere.

I can update a React component and be sure that the only places it affects are the places its rendered. And I can get type checking on every input going into a component. That's just way better to me.

I still use JQuery at work, but I usually dread it. And people say JQuery is "smaller" but I would still prefer something like Svelte to Jquery if that's a concern.

I can take or leave Vue, I don't really notice a huge difference between it and other component frameworks.


I’m a big fan of React and jQuery but it sounds like you’re not using jQuery right.

All my jQuery components were self contained and you just initialized them with $(‘[data-date-picker]’).datePicker(). It is pretty obvious to anyone looking at the code that if you remove “data-date-picker”, it stopped being a date picker.


Then you have dumb stuff like if you check a box and want some additional form fields, you have to inject a div or input into the DOM manually, and then make sure you initialize your datepicker, but maybe there will be a flash of unpickerified input if you don't do it right.


I haven’t used jquery in 10 years or so, but I’m pretty sure this isn’t what you would do. You would just hide or unhide the inputs with jquery.


That is true, but this is built-in to React and it's optional for JQuery. I am working on legacy projects a lot and nobody ever writes JQuery like this outside of famous libraries.


React was developed by Facebook. I don't think they did it for small components on otherwise static sites.


Facebook was a fairly static site back then, but small is a relative term here. I don't mean to say it was only meant to do that. Just that the origins of React are a far cry from the complexity of SPA frameworks like Next JS. And it can still be used as quite a simple drop in component system. Nothing is stopping you from doing that. Which is why people often say React is not a framework but a library, because it's true.

https://legacy.reactjs.org/blog/2013/06/05/why-react.html


what I usually did, was using data-xxx attributes (and document these attributes and how works) to inject special functionality to html elements. I did this with jQuery, and now I do with vainilla JavaScript.


That's one of the reasons I like them, yes. I've done a lot of manual DOM manipulation, and a lot of jQuery. When you're building anything complex, it starts to become quite difficult to figure out why a particular piece of the DOM is behaving the way it is. It could be an overly aggressive selector that accidentally targeted it, or any number of things.

Prior to React (and similar libraries), DOM manipulation was generally done in a mutating, effectful way. With React (and similar), if a thing is behaving strangely, I just need to go to the component that rendered said thing, and I can almost always find the problem.


Yes React is easy to reason about. In fact old versions of React were even easier to reason about than modern versions using hooks (`useState`). I used to use React and just React: no random npm packages, no Babel or any transpilation, no JSX, and it was pure joy compared to jQuery in a complex multi-step form. The jQuery code was in fact spaghetti.


For your blog, jquery is totally fine and reasonable. Jquery for a web application? That is going to be way more of a headache. It all depends on what you’re trying to accomplish.


I guess the "easy to reason about" thing people keep saying is meant to tell you that the modern frameworks allow modularization.

Personally, I do find their style of modularization abhorrent. As you said, it's full of boilerplate, it's also full of dependencies, and the worst sin in a software architecture: they don't enable you to specify a simple interface between modules. But they do solve the lack of structure you get when all the code talks to each other freely through the DOM.


Creating a brand new Vue app using Vite as your build system (official) takes less than 2 minutes and you can immediately start using Vue by following its documentation and creating a well-organized web application with its friendly patterns and solutions to the most common pro-UX problems you could encounter in a web app.

Give it a shot, it's stupid-easy, and that's not downplaying anything either.


This is pretty funny because the front end team at my company decided last year to migrate from Vue to React because Vue is too complicated and it's hard to find people who know it vs React. Impossible for me to get a read on this stuff. Such a clusterfuck of an ecosystem.


Yea there's certainly a lot of mixed opinions and learning curves involved to be sure. On the one hand, I love how many options there are to build web applications, but on the other, it really does feel fragmented and hiring front-end engineers is a huge gamble with all the different preferences involved because there is no true concept of "standards" everyone follows.

Thankfully it's pretty easy to align a team with a little time and learning what everyone wants.


You can make spaghetti with everything. But without framework spaghetti is even worse. People who make a mess out react do it because they try to use it as if it is jquery.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: