Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Brutal Lifecycle of JavaScript Frameworks

stackoverflow.blog

Post reply on HN
Print view View original

91–100 of 128 posts

Re: The Brutal Lifecycle of JavaScript Frameworks

#91

Post by pjmlp »

lolive wrote: post #86

My question as a Java/Swing developper is this: what is the difference between React and Web Components? As far as I understand, both create self-contained components that you can use in your HTML, and that will react when you alter their DOM structure (for example changing an attribute value, or binding an HTML input value with an internal value inside the component). And from that perspective, will we see in the fu…

That could be the idea, but currently it seems Angular devs are more open to that idea, given that WebComponents are mostly driven by Google.

https://summit.polymer-project.org/

https://developer.chrome.com/devsummit/

You can some components here, as well as, the current state of browser support.

https://www.webcomponents.org/

Currently only HTML Imports seem to be a point of disagreement.

I am looking forward to them, as they can be the way for more sanity on Web development.

Re: The Brutal Lifecycle of JavaScript Frameworks

#92

Post by gwright »

mattmanser wrote: post #67
Cthulhu_ wrote: post #65

Earlier quoted context omitted.

Your IP is public, so you can't hide it; privacy invasion is a non-argument there. IP data retention, on the other hand, will be interesting. On the one hand, law enforcement wants to have ISPs and companies to track and remember those, for future investigations. But on the other hand, privacy advocates want that kind of data to not be stored at all.

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:/…

In skimming through the StackOverflow privacy statement it certainly appears that they disclose the collection of IP addresses and use of that information to report aggregated data ("we may publicly display information that is not personally identifying in the aggregate").

Re: The Brutal Lifecycle of JavaScript Frameworks

#93

Post by pjmlp »

catpolice wrote: post #47

I always have to show up to reiterate this is not a problem limited to Javascript. There have been framework fads for as long as there have been frameworks. I have dim memories of dozens of C++/Java/Python/Ruby/etc. next-big-things. It does seem like there are more of them and they rise and fall faster in the Javascript world, but this is probably better explained by the sheer number of Javascript programmers than an…

> I have dim memories of dozens of C++/Java/Python/Ruby/etc. next-big-things.

While true, none of them have changed so quickly as JavaScript ones, which seem driven by devs eager to create portfolios on Github.

Re: The Brutal Lifecycle of JavaScript Frameworks

#94

Post by werber »

scotchio wrote: post #25

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

You also have to take into consideration that the Vue community has the most Chinese devs of the JS SPA contenders and that might be reflected super well by SO data.

Re: The Brutal Lifecycle of JavaScript Frameworks

#95

Post by drderidder »

It's easy to see graphs trending down and say, oh, interest is waning. But the initial spike could just be lots people going through a learning curve. It tells you something about popularity, but ease-of-use, quality of docs, etc. must all factor in as well. I tend to see the high number of questions on certain frameworks as a red flag.

Re: The Brutal Lifecycle of JavaScript Frameworks

#96

Post by simonsarris »

mixonic wrote: post #89

The interesting story in this post is not about JS frameworks. It is about StackOverflow. The Ember community made a proactive decision to abandon StackOverflow around the 2.0 release (about 2.5 years ago). StackOverflow simply does not provide the tools we needed. For example when you answer a question: Are you answering for version 1.0 of a library? 2.0? Perhaps the "correct" answer for each is different. Perhaps,…

I think this is the most important takeaway. It's especially true for smaller libraries and commercial libraries. And even for huge ones like Rails, questions answered 6 years ago might be little more than a catalog of improper practices by now!

For a hard numbers example of "trends" being poor, I develop a JavaScript diagramming library, GoJS: https://gojs.net

It has competition, such as JointJS, jsPlumb, etc. If I look at StackOverflow tags, I would think we're in big trouble:

* 180 questions tagged gojs

* 449 questions tagged jointjs

* 518 questions tagged jsplumb

These aren't even enough to show up on StackOverflow's trend tool, and they make the case look pretty dire for GoJS!

But behold, Google trends: https://trends.google.com/trends/explore?date=all&q=gojs,joi... (ignore the last, partial-data month)

In search interest GoJS is clearly ahead of these other two libraries. What's more, if you compare the forums for each product, you'd see that GoJS gets 10x-100x the traffic of the others.

StackOverflow is simply not the a good place to gauge library interest and activity over the long term, and its not a good place as you say to ask or find answers to questions for products that have ecosystems which continuously improve their APIs and evolve.

Re: The Brutal Lifecycle of JavaScript Frameworks

#97

Post by djroomba »

eitland wrote: post #74
shams93 wrote: 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.

> 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.

Re: The Brutal Lifecycle of JavaScript Frameworks

#98

Post by Sawamara »

Klathmon wrote: post #64
Sawamara wrote: post #49

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…

(heads up, you need have a blank space between lines in HN to render them on different lines) I completely agree. Many people claim the web is overly complex, but then go back into the C++ world where you need a build tool to build your makefile which builds your project using cross compilation on a handful of platforms. I like to remind people that 10 years ago Android didn't exist, streaming video was still only ju…

Thank you! Oh, now that you mention it: just a few years ago, web streaming was not possible without using either flash or (maybe?) silverlight or something else because it was not implemented yet. Youtube crashed my pc regulary during the hd4850 end-days due to driver crashes. Node was not even a thing yet, let alone Electron/NWJS....

Re: The Brutal Lifecycle of JavaScript Frameworks

#99

Post by dasil003 »

mattmanser wrote: post #58
dasil003 wrote: post #54

Earlier quoted context omitted.

Does SO operate in the EU?

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 GDPR headache.

Re: The Brutal Lifecycle of JavaScript Frameworks

#100

Post by jedwardhawkins »

nailer wrote: post #82
tboyd47 wrote: post #56

Earlier quoted context omitted.

AngularJS refers to major version 1, Angular refers to 2.

Wow. That's really unintuitive.

I agree with the sentiment. Most people view them as distinct frameworks. I believe the use of the name Angular for major version 2+ helped retain a lot of users. I've seen a lot of uninformed devs and managers assume that because they already have so much code in AngularJS that Angular is the next logical tool for their team to use.
Post reply on HN