Hacker News Reader

Comment by dham | Hacker News Reader

They're using jQuery wrong and now reaching for a framework. If you write bad code in jQuery you're going to write bad code in a framework. I've seen it a dozen times. Use event delegation and behaviors, not "if window.location = ''". That's just wrong. You can solve a ton of problems with jQuery(or plain DOM api) and mutation observers.

View on HN

I disagree. As someone who recently made the switch from jQuery to React, it is way easier to shoot yourself in the foot with jQuery. React let's you focus on how the component should behave instead of doing mental gymnastics trying to manipulate the DOM. There are always so many edge cases with DOM manipulation, it rarely turns out well for anything but trivial things (which I still use it for).

Yeah if you need a SPA jQuery won't work. Ultimately react and Vue will give you much cleaner code at the cost of learning the shadow Dom. All the old Dom methods from jquery and vanilla js over to shadow Dom instead.

FYI it's "the virtual Dom", the shadow Dom is something different.

> Yeah if you need a SPA jQuery won't work.

It will certainly work, there are plenty of SPA which use jquery (or even vanilla JS) for their DOM manipulation. But it will likely be significantly more painful and prone to desync bugs than using a vdom-based system

Not just SPAs either, any non-trivial component is affected.

Jquery solved a problem where building websites was a pain. Trying to listen to an event? Manipulate the dom? All painful.

But the thing is we aren’t really building websites anymore. We are building web applications. And jquery just plain sucks for that.

I challenge anyone to use jQuery to build a SPA and not re-invent backbone (poorly or otherwise).

I built a simple site recently and one complex page ended up with shitty recreations of backbone Model and View.. and never knew until a colleague reviewed my code and suggested I look those up.

I recently did exactly this and it wasn't that bad. It's not that I couldn't use Backbone, I decided not to because I didn't see the point in introducing yet another library when all I really needed to do was bind inputs to a model, which I did in about 5 lines of terse jQuery. Besides, I had custom widgets that wouldn't have benefited from Backbone anyway and would have required customization anyway. I think judicious use of libraries is ok, but tbe more elite among us tend to become libray snobs and shame people for not doing things the "right" way.

> there are plenty of SPA which use jquery (or even vanilla JS) for their DOM manipulation.

I've seen jQuery included in VueJS/react/ng2 for a specific complex plugin, and I've seen it for a few simple DOM manipulations where there was no reason for kQuery to do it instead of the framework, but is there actually a paradigm for jQuery being the root framework in an SPA? I've looked for jQuery SPA and found nothing. Does a jQuery SPA framework actually exist or are you talking about lots of homemade frameworks that use jQuery?

> React let's you focus on how the component should behave instead of doing mental gymnastics trying to manipulate the DOM

Agreed - a huge benefit of Vue is exactly that - it's declarative. You describe what you want with a (more or less) plain ol' Javascript object, instead of how you want something to work. It's almost like writing JSON - and is just as readable.

ReactJS is declarative as well.

JSX is not declarative

Not really sure how you can reach that conclusion. With JSX you are declaring what the HTML will look like, rather than specifying how to do the transitions. It's difficult to get more declarative than that.

I wasn't saying that it isn't.

It's easy to shoot yourself in the foot with any technology. People switch to a technology thinking they're writing better code with it, but in reality they're just a better at coding. Or it's a rewrite of something, in that case you know more about the problem you're solving. If you're bad at coding jQuery, when you switch to Vue or React, you then have gigantic mono components, if else if else rendering, 5000 state variables, or some other thing that you shoot yourself with.

Some technologies make it much easier to shoot yourself in the foot than others. jQuery is in that category. Some technologies make it easy to do things right by making sure that the right way is the path if least resistance.

I agree. Generally speaking, jQuery or VanillaJS will be more performant than React. If you combine jQuery with template literals, you can put together some pretty nice, manageable code for most use cases.

Generally speaking a regular dev under normal time/budget constraints will.het better performance out of React or Vue. It takes more time and more expertise to get that "optimal" VanillaJS performance. Analogy: Ruby vs C.

I disagree.

With React, you can quite quickly stumble over performance bottlenecks in non-trivial app when you don't know what you are doing.

Especially on mobile devices.

Could you give some examples? When it comes to trivial apps I'd say jQuery could be fine, but it feels like kind of working against what it was designed for. But for non-trivial apps I can think of at least as many jQuery 'gotchas' as I am aware of in React.

If your app is non-trivial, I expect maintainability nightmares in vanilla long before performance issues (which will be in both for people who don't know what they are doing).

I completely agree that you can do a lot with jQuery or even plain DOM and JS. It's often the right way to go when there's already back-end structure like Wordpress, Drupal, or ASP.NET and you just need simple things like form validation.

The benefit that frameworks offer is exactly that structure that jQuery doesn't provide (and was never designed to provide). A long-lived SPA needs good structure. If you aren't good at understanding how to create it yourself a framework can save a LOT of work.

I'm all for frameworks, because jQuery can eventually get out of hand. I just see a lack of knowledge on how to structure basic DOM code, so that's going to transfer into other frameworks. I'm more of a fan of someone going the DOM api route, seeing the pitfalls, then move to a framework. Not necessarily in the same project, just overall. It's good to see the pitfalls so you know why you're choosing something.

Exactly. The OP should learn the underlying technologies, instead of learning frameworks. They even admitted to not being willing to learn properly. At that point, how can you even make a fair comparison?

You could probably make this comparison: For someone who, for whatever reason, doesn't want to spend time learning the underlying technology, they will end up with a better solution if they use Vue.

In my case I have looked at the underlying technology of front end web and it appears to be nothing fundamental. Rather, it's a series of historical accidents, mainly around trying to make a markup based, styled, document behave like an application. I find it hard to get motivated to learn that. According to the article, the likes of me would be better off using Vue or some equivalent.

>You could probably make this comparison: For someone who, for whatever reason, doesn't want to spend time learning the underlying technology, they will end up with a better solution if they use Vue.

Or Wix or Wordpress even.

But for someone who has taken the trouble to develop an in-depth knowledge of, and facility with, the underlying technologies (HTML, CSS and JS), front end development is not that difficult or mysterious. And for them, these frameworks make the process needlessly complex rather than simpler.

Does wix/WordPress have the application level UX capabilities of VueJS/react before becoming a plugin writer? I find the comparison grossly disingenuous. If you were asked to write a TodoMVC in VueJS/react vs WordPress, you'd probably figure out how to start (and/or have already finished a proof of concept) in an hour with VueJS. In WordPress, you'd be 6 hours into the introduction to WordPress plugins and still unsure if a TodoMVC is possible or if WP is the right tool. If you legitimately think what people do with VueJS can be done just as well by juniors in WordPress, then you don't understand what VueJS/react actually do.

> If you write bad code in jQuery you're going to write bad code in a framework.

Preventing this is precisely what frameworks are for. A framework - a good one at least - provides a frame that has you code along guidelines (best practices, opinionated style devised by the framework creator etc.) and therefore prevents you from committing common mistakes.

Using a framework allows you to delegate low-level decisions to someone else, who - hopefully - is more knowledgeable than yourself in that area.

Agreed. I had to make something using jQuery after a couple years of working almost exclusively with React I found that I could mimic react components using jQuery plugins and it looks and works pretty good.

Yeah this is a pretty bad case study. I kept scrolling expecting to see some clean separations and healthy, maintainable components but it kinda just ended abruptly and left us all hanging.

Reply on news.ycombinator.com