News for hackers. Stuff that matters.
Re:How and why we moved to Vue.js by dham on Sunday February 11, 2018 @10:14AM (#16352971)
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.
Re:How and why we moved to Vue.js by dyeje on Sunday February 11, 2018 @11:07AM (#16353216)
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).
Re:How and why we moved to Vue.js by dham on Sunday February 11, 2018 @02:57PM (#16354419)
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.
Re:How and why we moved to Vue.js by cstejerean on Sunday February 11, 2018 @03:23PM (#16354576)
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.
Re:How and why we moved to Vue.js by faitswulff on Sunday February 11, 2018 @12:10PM (#16353497)
> 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.

Re:How and why we moved to Vue.js by rleija on Sunday February 11, 2018 @03:30PM (#16354622)
ReactJS is declarative as well.
Re:How and why we moved to Vue.js by faitswulff on Sunday February 11, 2018 @04:21PM (#16354876)
I wasn't saying that it isn't.
Re:How and why we moved to Vue.js by GhostVII on Sunday February 11, 2018 @04:18PM (#16354861)
JSX is not declarative
Re:How and why we moved to Vue.js by timbuckley on Sunday February 11, 2018 @05:14PM (#16355133)
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.
Re:How and why we moved to Vue.js by shams93 on Sunday February 11, 2018 @11:42AM (#16353363)
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.
Re:How and why we moved to Vue.js by masklinn on Sunday February 11, 2018 @12:30PM (#16353613)
> 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.

Re:How and why we moved to Vue.js by dragonshed on Sunday February 11, 2018 @09:26PM (#16356107)
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.

Re:How and why we moved to Vue.js by temporallobe on Monday February 12, 2018 @12:57AM (#16356848)
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.
Re:How and why we moved to Vue.js by Can_Not on Friday February 16, 2018 @10:15AM (#16392859)
> 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?

Re:How and why we moved to Vue.js by philliphaydon on Sunday February 11, 2018 @08:46PM (#16355965)
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.

Re:How and why we moved to Vue.js by Klathmon on Sunday February 11, 2018 @11:53AM (#16353405)
FYI it's "the virtual Dom", the shadow Dom is something different.
Re:How and why we moved to Vue.js by osrec on Sunday February 11, 2018 @11:12AM (#16353244)
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.
Re:How and why we moved to Vue.js by hashkb on Sunday February 11, 2018 @11:48AM (#16353387)
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.
Re:How and why we moved to Vue.js by the_duke on Sunday February 11, 2018 @12:30PM (#16353608)
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.

Re:How and why we moved to Vue.js by mercer on Sunday February 11, 2018 @01:08PM (#16353842)
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.
Re:How and why we moved to Vue.js by Can_Not on Friday February 16, 2018 @10:17AM (#16392881)
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).
Re:How and why we moved to Vue.js by dmethvin on Sunday February 11, 2018 @10:20AM (#16352993)
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.

Re:How and why we moved to Vue.js by dham on Sunday February 11, 2018 @10:35AM (#16353075)
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.
Re:How and why we moved to Vue.js by atoko on Sunday February 11, 2018 @10:32AM (#16353057)
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?
Re:How and why we moved to Vue.js by discreteevent on Sunday February 11, 2018 @05:17PM (#16355143)
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.

Re:How and why we moved to Vue.js by rhapsodic on Sunday February 11, 2018 @10:42PM (#16356358)
>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.

Re:How and why we moved to Vue.js by Can_Not on Friday February 16, 2018 @10:36AM (#16393023)
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.
Re:How and why we moved to Vue.js by BjoernKW on Sunday February 11, 2018 @04:21PM (#16354881)
> 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.

Re:How and why we moved to Vue.js by armandososa on Sunday February 11, 2018 @06:21PM (#16355405)
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.
Re:How and why we moved to Vue.js by whalesalad on Sunday February 11, 2018 @10:18AM (#16352987)
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.