Live data from Hacker News

The Brutal Lifecycle of JavaScript Frameworks

stackoverflow.blog

111–120 of 128 posts

Re: The Brutal Lifecycle of JavaScript Frameworks

#111
post #53
post #17

Earlier quoted context omitted.

I did that on a product as well. It went pretty well. The issue is with more complicated UI. The more complicated it is, the faster JQuery breaks down. That being said, it's better to have a bit of a spaghetti JQuery than to try and retrain unwilling programmers in Angular.

jQuery doesn't have to be spaghetti though. It gets that rap I think because most people that used it weren't good/experienced enough to organize bigger code. It can/usually does turn into a mess though but is faster to bang small things out in for me anyway.

It doesn’t have to be spaghetti. You are right. However, when you change state in multiple places, they either have to be aware of each other or you need some kind of state management. The benefit of libraries like React are that they abstract view rendering and take care of DOM diffing. The benefit of frameworks like Angular is that it manages state in addition to what React does.

On simpler projects, JQuery is more productive. But my main point is to program where it is comfortable and practical. The better academic choice is not necessarily the better choice. View your programming resources as people and make the pragmatic choice.

Re: The Brutal Lifecycle of JavaScript Frameworks

#112
post #73

IME Vue is so well designed, that I hardly have any issues with it. If I do, my go-to reference is the official documentation. You shouldn't base your usage assumptions on the amount of questions asked; Vue just doesn't require so many questions...

Ditto for React. Pretty much every "how do I do this" is covered in the official tutorial and every "how should I do this" is covered by supplemental guides (still official docs).

Some good ones: "thinking in React", "lifting state up", "controlled components", and similar docs in redux: "you might not need redux"

Re: The Brutal Lifecycle of JavaScript Frameworks

#113
post #108

Earlier quoted context omitted.

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?

If you only want to translate(map) each element in to another set of value, using Map is much more simpler and readable than forEach

Re: The Brutal Lifecycle of JavaScript Frameworks

#114
post #39
post #16

The PHP and Vue correlation can at least partly be explained by the fact that Laravel, a popular PHP web framework, has first-hand support for Vue and installs Vue by default in projects bootstrapped with their cli tool.

WordPress.com But Vues triumphal march starts before Laravel or WordPress.

WordPress.com uses React[1] and the new WordPress CMS Gutenberg[2] editor is also using React. (Just FYI)

[1] https://github.com/Automattic/wp-calypso

[2] https://github.com/WordPress/gutenberg

Re: The Brutal Lifecycle of JavaScript Frameworks

#115
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'; })

The modern DOM API has forEach on NodeList so you can skip the Array.from.

  document.querySelectorAll('.my-component div').forEach(node => node.style.background = 'yellow');
https://developer.mozilla.org/en-US/docs/Web/API/NodeList/fo...

Re: The Brutal Lifecycle of JavaScript Frameworks

#116

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

Angular and react are used by more devs than Vue.

also keep in mind that Angular is complex enough to warrant 10x more questions. and React community, has done a lot of RnD in areas like flux, graphql, cssInJs etc. hence they too would have more questions.

Re: The Brutal Lifecycle of JavaScript Frameworks

#118

It is not really a brutal lifecycle at all, to be honest. Everyone loves a good rant about how fast the JS frameworks burn out, but it is not frameworks that burn out, but rather: In the 8+ years since Iphone/Android duo made a HUGE change in how we consume web content, we went from: - Having static resolution for websites to dynamically changing site resolutions - Having static HTML renders with some dynamic bits sp…

"The web has seen more transformations in terms of what is an "app" or a "website" in 8-10 years than ANY OTHER area in programming. It is only natural that widely different tasks need widely different tools to work with."

These frameworks are not as different, though, so I don't that's the driving force.

I think that the implicit argument of the article is that although new frameworks emerge, almost none of them get a large enough ecosystem or amount of adoption to become entrenched.

The other thing that the author hints at is that there is a relationship between server-side platforms and choice of JS framework. Ember got a small lift because it was co-designed by one of the best and most well-known Rails developers, but Rails people seem to have gone to React, and Angular seems to have been adopted by the C# community to the point that Microsoft and Google run joint events. Thus newcomer JS frameworks are less likely to get enough adoption to stick around, because server-side frameworks now have implicit default JS frameworks.

Re: The Brutal Lifecycle of JavaScript Frameworks

#119

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…

It's not about what you release to the public, if you're processing this data in private it's still culpable.

This page gives it some context:

https://ico.org.uk/for-organisations/guide-to-the-general-da...

Further down are the 6 reasons for processing.

We know the first 5 don't apply:

    consent - there's no consent
    contract - it's not necessary to provide the Q&A answer site
    Legal obligation - there's no legal obligation
    Vital interests - nope
    Public task - nope

So what it falls under is "Legitimate interests", SO want to use a user's IP address, process it to add company name, store that and then use that data for profiling their customers to serve them ads.

One of the problems for SO is that further down they go into this a bit more and there's a few key questions:

    Would individuals expect this processing to take place?
    Are some of the individuals concerned likely to object?
    Are you able to stop the processing at any time on request?
Which I would think would be answer No, Yes, No. Which seems to indicate that there's some problems with SO's approach.

Re: The Brutal Lifecycle of JavaScript Frameworks

#120

Earlier quoted context omitted.

They don't block EU users, so they do business in the EU. As it offers goods and services to EU citizens, it has to operate according to GDPR as far as I understand it. And it does do sales in the EU, there are plenty of SO jobs being advertized (and paid for) in the EU.

I know GDPR is written this way, the question is how it will be enforced? If SO has no operations in the EU, and it's literally just take EUR payments, and the volume is relatively small (or they figure out some offshore processing hack) then they could make the decision to stop processing EUR and give GDPR the middle finger. That's a lot of ifs, but it's not a foregone conclusion that European markets are worth the…

No, they'd have to block the whole of the EU from accessing the site.
Post reply on HN