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

41–50 of 128 posts

Re: The Brutal Lifecycle of JavaScript Frameworks

#41

Post by bvm »

brentm wrote: post #38
mkirklions wrote: post #31

About to make an App using React(and react native?) Up until this point, I usually would make most things from scratch and pull in libraries sparce. No big deal because my previous programs didnt need to. (Self taught programmer for 11 years.) For the next 3 months, I'll be working on this almost alone. Is it worth using some of my resources to hire a React developer? Also, this topic implies React will be gone in ab…

I would learn React if I was you. Check out create-react-app on Github. It will set you up with a working app to play with in a matter of seconds. If you're expecting to use React Native it looks like they have a create-react-native-app also.

and don't eject until you really need to! CRA is fantastic and surprisingly extensible.

Re: The Brutal Lifecycle of JavaScript Frameworks

#42

Post by kuon »

I moved my frontend (I mean "in browser" by that) dev to elm about a year ago, and it's been a year of peace. I know elm has flaws, and it's development workflow can be criticized for being too slow or conservative, but it's been so predictable, so easy to work with, so maintainable and so solid in production, I have never been so happy about frontend dev.

Re: The Brutal Lifecycle of JavaScript Frameworks

#43

Post by var_explained »

lakechfoma wrote: post #26

Why is the measurement on questions asked for the first couple of graphs and then user traffic for the latter set? I wonder if traffic is the better measurement for the first two as well but I bet the graphs won't look quite as doom and gloom.

The first few graphs use the interactive [Stack Overflow Trends](http://insights.stackoverflow.com/trends) tool, which is all public data. This is useful since it lets readers modify the graphs (for example, to add a few more tags to the comparison).

The later graphs use data that's already not public (what tags users visit together, and what countries tags are visited from), so there's no reason not to use visits instead.

The graphs for visits over time do look very similar (in general question traffic by tag roughly matches questions asked, but as a slightly lagging indicator)

Re: The Brutal Lifecycle of JavaScript Frameworks

#44

Post by shams93 »

codingdave wrote: post #12
Kajayacht wrote: post #2

One of the things I don't think it accounts for in talking about the downfall of something like jQuery is that as time goes on, the questions have already been asked. So of course there's going to be less questions asked about jQuery in 2017 versus 2009, because if I need to figure out how to select elements based on an attribute rather than a class or id, it's already there.

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…

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.

Re: The Brutal Lifecycle of JavaScript Frameworks

#45

Post by mattmanser »

As an aside from the interesting article, does any one else find it pretty scary and privacy invading that stackoverflow think it's ok to match our IP addresses to the company we work in?

It seems like a massive invasion of privacy (which I guess lots of websites are doing).

But to me that SO can so casually mention the mass surveillance and privacy invasion they're doing without thinking that there's anything wrong with it is the worst part of it.

I certainly never knowingly agreed that they could check my IP address and then try and figure out what company I work at from it.

EDIT: Once GDPR is live in the EU, I think it might be interesting to see if I can challenge this privacy invasion and inappropriate use of personally identifying data. I guess we'll see if GDPR has any actual teeth in this instance.

Re: The Brutal Lifecycle of JavaScript Frameworks

#46

Post by mkirklions »

brentm wrote: post #38
mkirklions wrote: post #31

About to make an App using React(and react native?) Up until this point, I usually would make most things from scratch and pull in libraries sparce. No big deal because my previous programs didnt need to. (Self taught programmer for 11 years.) For the next 3 months, I'll be working on this almost alone. Is it worth using some of my resources to hire a React developer? Also, this topic implies React will be gone in ab…

I would learn React if I was you. Check out create-react-app on Github. It will set you up with a working app to play with in a matter of seconds. If you're expecting to use React Native it looks like they have a create-react-native-app also.

Right now I'm stuck working on getting SDKs installed.

I got my android app running which was easy after all the installs and updates.

Now I'm doing some weird command line stuff to try to get my Javascript server to wake up. Changing ports, more SDK updates, etc... Changing my App.js doesnt update, except if I turn everything off and back on again.

Re: The Brutal Lifecycle of JavaScript Frameworks

#47

Post by catpolice »

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 anything else. The labor statistics I can find peg the number of US software developers in 2002 at around 612,000 and around 3.87 million in 2016 - and most of the new ones focus on web development. There are way more web programmers out there than there have really ever been, so it makes sense that the rate of frameworks appearing (and to a degree, the overall lifecycle churn) would be accelerated.

Re: The Brutal Lifecycle of JavaScript Frameworks

#48

Post by kbenson »

dmitriid wrote: post #19
itcmcgrath wrote: post #13

Earlier quoted context omitted.

"Of course there's going to be less questions" Yet there are counter examples that show that can't be the complete story: http://sotagtrends.com/?tags=[jquery,python]&relative=false

You could argue that jQuery covers handling (a part of) DOM APIs which are updated only rarely. Once you know what $().append().on().trigger() does, there's not that much left to know about jQuery. And most everything can be understood from docs. Python, however, is a continuously evolving language with an ever expanding number of libraries and areas of application.

Python is just an outlier when looking at this. Here's[1] a larger set of languages and frameworks, and given the premise it's not hard to guess the JS frameworks from the graph.

1: http://sotagtrends.com/?tags=[jquery,angularjs,c,c%2B%2B,rub...

Re: The Brutal Lifecycle of JavaScript Frameworks

#49

Post by Sawamara »

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 sprinkled over to full-blown SPA-s because of a variety of reasons* - Having major new JavaScript versions and INSANE amounts of Javascript engine speedups that allow things that were unimaginable 8+ years ago - Having gone from "nothing" to a CPU-based to a full OpenGL ES-implementation, full GPU-based (), - Had went from procedural code to semi-class based systems towards functional towards functional reactive programming systems

And I could go on and on and on and on.

The DOM api matured during these years. The renderers got replaced. Their performance altered dramatically. Layouts went from "JUST USE TABLES" towards CSS, then towards Compile-to-css alternatives, etc. Single-core event systems got SharedArrayBuffers, webWorkers, we got from callbacks to promises, towards async/await. And do not get me started on almost getting observables properly.

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.

Re: The Brutal Lifecycle of JavaScript Frameworks

#50

Post by bigmanwalter »

rplnt wrote: post #34
bigmanwalter wrote: post #27

Earlier quoted context omitted.

To be fair, that's because the jQuery solution was usually orders of magnitude simpler. Although newer versions of javascript have absorbed enough of the jQuery api that this is no longer the case.

Acceptable way would be "Hey, it's done like this, but since the language sucks there's this random library where you can do it this way". Including jQuery for one small task would be stupid. Including jQuery in a non-web project would be weird. Including jQuery in some es variants would be impossible.

At that time, javascript was used exclusively for client-side web development. It was pretty much impossible to write ajax requests in any sane fashion that worked cross-browser. It's not such a stretch to assume the user asking the question could use jQuery.
Post reply on HN