Live data from Hacker News

The Brutal Lifecycle of JavaScript Frameworks

stackoverflow.blog

101–110 of 128 posts

Re: The Brutal Lifecycle of JavaScript Frameworks

#101
post #44

Earlier quoted context omitted.

Yeah with jquery we were composing templates server side. Compared to Vue trying to do a SPA in jQuery is a season in hell. It can be done but it's brutal and fragile.

I'm quite surprised at this conclusion. I've always felt that doing SPA with jQuery was the easiest thing I've ever done in my development career. It's so easy to get something set up and running. And it's a breeze to figure out and read the code too: even when it's 10s of thousands of lines of code. Is it just me, or are many of the newer frameworks actually harder to use? I tried Angular 1 about 4 or 5 years ago an…

> And [jQuery is] a breeze to figure out and read the code too: even when it's 10s of thousands of lines of code.

> Is it just me

Probably.

Re: The Brutal Lifecycle of JavaScript Frameworks

#102
post #44

Earlier quoted context omitted.

Yeah with jquery we were composing templates server side. Compared to Vue trying to do a SPA in jQuery is a season in hell. It can be done but it's brutal and fragile.

I'm quite surprised at this conclusion. I've always felt that doing SPA with jQuery was the easiest thing I've ever done in my development career. It's so easy to get something set up and running. And it's a breeze to figure out and read the code too: even when it's 10s of thousands of lines of code. Is it just me, or are many of the newer frameworks actually harder to use? I tried Angular 1 about 4 or 5 years ago an…

Depends on the SPA. If you're trying to do something relatively simple, where the events and state clearly map to the UI, jQuery isn't too bad. It's even fun.

Once your SPA goes through an iteration or two with a few different programmers, you find your events have nasty ordering dependencies and your data becomes inconsistent all on its own. You have no idea why because you can't reproduce any of these issues on your own. You have to watch other people interact with your app just to reproduce bugs ("why the hell would you double click a link?") and git bisect becomes the most productive tool in your toolbox. Most project discussions end with a shrug. You yearn for the days when it was possible for a single human to ever understand the entire app, but that was six months ago and management steadfastly refuses to fund a rewrite. You look wildly around for any sign of hope...

As for Angular, agreed, but I'd rather work with it than a bunch of jQuery. React and Vue are quite pleasant.

Re: The Brutal Lifecycle of JavaScript Frameworks

#103
post #74

Earlier quoted context omitted.

> It can be done but it's brutal and fragile. Actually many who did jQuery were proud of it. Some of us made rock solid sites or improved exiting ones quite a bit using a technology known as progressive enhancement. Let me tell you what is fragile: the cool things I make today that won't even try to work if I disable Javascript. :-) Edit: and given what we have seen over the last few days now would be a good time to…

I miss progressive enhancement, when/why did it die.

Did progressive enhancement ever catch on? It made for some great Rails 2 tutorials but I don't remember seeing it much in the wild.

It's going away because you basically have to write everything twice and it's hell to keep consistent.

Re: The Brutal Lifecycle of JavaScript Frameworks

#104

Earlier quoted context omitted.

It's not the IP address that's the problem, it's that they're processing personally identifiable information about their users in a way they haven't asked permission for and is not related to the service they're providing. Here's the UK's ICO guidance for what you can process, as far as I can tell they've got no lawful basis for trying to match a user's IP address to a company without the user asking them to. https:/…

I skimmed that link and couldn't figure out what they mean by "processing". (It's related to compliance with a law, so I assume that the common sense meaning of a word isn't necessarily what is meant.) Do you understand what they mean by "processing" in this context? It seems like you're saying that analyzing IP addresses a user connected from in order to determine their likely employer is against the UK's GDPR guida…

Since these provisions are most likely based on EU directives I would assume that this definition is also reflected in UK law:

> (b) 'processing of personal data' ('processing') shall mean any operation or set of operations which is performed upon personal data, whether or not by automatic means, such as collection, recording, organization, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, blocking, erasure or destruction;

(Directive 95/46/EC)

All IPs are personal data (even if they are dynamicly assigned) if I read [1] correctly (Not a lawyer and there is most likely something I miss).

[1] http://curia.europa.eu/juris/celex.jsf?celex=62014CJ0582&lan...

Re: The Brutal Lifecycle of JavaScript Frameworks

#105

Woah... Was honestly surprised to see Vue.js was so tiny in comparison to Ang and React regarding "% of Stack Overflow questions that month". I thought it was much bigger

Maybe this should serve as a reminder that the HN bubble is not at all representative of the web development community at large nor it's membership a strong indicator of the community's sentiment.

Re: The Brutal Lifecycle of JavaScript Frameworks

#106
post #74

Earlier quoted context omitted.

> It can be done but it's brutal and fragile. Actually many who did jQuery were proud of it. Some of us made rock solid sites or improved exiting ones quite a bit using a technology known as progressive enhancement. Let me tell you what is fragile: the cool things I make today that won't even try to work if I disable Javascript. :-) Edit: and given what we have seen over the last few days now would be a good time to…

I miss progressive enhancement, when/why did it die.

[deleted]

Re: The Brutal Lifecycle of JavaScript Frameworks

#107
post #44

Earlier quoted context omitted.

Yeah with jquery we were composing templates server side. Compared to Vue trying to do a SPA in jQuery is a season in hell. It can be done but it's brutal and fragile.

I'm quite surprised at this conclusion. I've always felt that doing SPA with jQuery was the easiest thing I've ever done in my development career. It's so easy to get something set up and running. And it's a breeze to figure out and read the code too: even when it's 10s of thousands of lines of code. Is it just me, or are many of the newer frameworks actually harder to use? I tried Angular 1 about 4 or 5 years ago an…

>And it's a breeze to figure out and read the code too: even when it's 10s of thousands of lines of code.

Not at all. The issue with an application written in jQuery is a lack of sane state management. Forgetting to initialize (or re-initialize) values, not expecting things to be executed in a different order, and just poor organization in general led to mountains of runtime errors.

Nowadays we use Elm. The difference is night and day. I wrote a post on this topic a few months ago: https://charukiewi.cz/posts/elm/

Re: The Brutal Lifecycle of JavaScript Frameworks

#108
post #85

Earlier quoted context omitted.

On the same note, the older frameworks solved older problems. jQuery was the killer framework because it handled browser compatibility back in a time when people not only needed to support IE8, but IE6, and few companies felt comfortable telling people to just update their browser. Well, those days are past, so that problem is no longer a reason to choose a framework, and when you take that out of the picture, jQuery…

I am not at all a front-end developper. But isn't jQuery the DOM API done right? [Which is a good thing, but only the beginning of the journey.]

DOM APIs have much improved since jQuery first arrived, so while that was the case originally, it's become less true over time. It's definitely still less verbose though, for example:

  $('.my-component div').css({ background: 'yellow' })
vs.

  Array.from(document.querySelectorAll('.my-component div')).map(node => {
    node.style.background = 'yellow';
  })

Re: The Brutal Lifecycle of JavaScript Frameworks

#109
post #108
post #85

Earlier quoted context omitted.

I am not at all a front-end developper. But isn't jQuery the DOM API done right? [Which is a good thing, but only the beginning of the journey.]

DOM APIs have much improved since jQuery first arrived, so while that was the case originally, it's become less true over time. It's definitely still less verbose though, for example: $('.my-component div').css({ background: 'yellow' }) vs. Array.from(document.querySelectorAll('.my-component div')).map(node => { node.style.background = 'yellow'; })

Why use map instead of forEach?

Re: The Brutal Lifecycle of JavaScript Frameworks

#110
post #20

Remember that Merb was merged into Rails? That's a community converging, that's what brought Ruby to the point that it is recruiter-speak synonymous to Rails. In the JS world: not so much. But that prolly has many reasons. I can think of: the language changing rapidly, the community not very "close", people coming to JS from widely different places, and the fact that a JS framework can span either the FE or the BE or…

io.js?
Post reply on HN