Live data from Hacker News

The Brutal Lifecycle of JavaScript Frameworks

stackoverflow.blog

121–128 of 128 posts

Re: The Brutal Lifecycle of JavaScript Frameworks

#121
post #74
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…

If you need your website to work without JS, Nuxtjs is an amazing VueJS framework for SSR or static prerendering.

Re: The Brutal Lifecycle of JavaScript Frameworks

#122

Earlier quoted context omitted.

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

The code loops through an array, has side effects and returns nothing so forEach would be more descriptive IMO.

As for simple/readable it’s the same code but s/map/forEach.

Re: The Brutal Lifecycle of JavaScript Frameworks

#123

Earlier quoted context omitted.

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

Actually, this is incorrect. You're abusing map here. The purpose of map is to map an existing array onto a new array. You're using map here to mutate properties on nodes in the original array, and creating a new Array, which has the length of the initial array, where each value is the return value of `node.style.background = 'yellow';`

forEach is much more indicative of what you're actually doing here, which is running through an iterable and mutating properties on each node.

Simple rule of thumb: if you're not using the results of `map`, you shouldn't be using it.

Re: The Brutal Lifecycle of JavaScript Frameworks

#124
post #93

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.

> which seem driven by devs eager to create portfolios on Github.

Is this supported by any facts? It seems like a hand-wavey hasty generalization.

Re: The Brutal Lifecycle of JavaScript Frameworks

#125
post #93

Earlier quoted context omitted.

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

> which seem driven by devs eager to create portfolios on Github. Is this supported by any facts? It seems like a hand-wavey hasty generalization.

The increasing trend of startups asking for Github accounts on their job offers.

You just need to search on job boards.

Re: The Brutal Lifecycle of JavaScript Frameworks

#126
post #6

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.

Right, jQuery is good and mature, and I can usually find what I need in the documentation. It will never die. I don't use jQuery by itself these days, of course. I'm using it in combination with mithril.js (not as popular as React, but similar in concept) at the moment.

https://www.reddit.com/r/programmingcirclejerk/comments/7q81...

Re: The Brutal Lifecycle of JavaScript Frameworks

#127
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?

Yups. Nice one!

Re: The Brutal Lifecycle of JavaScript Frameworks

#128
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,…

StackOverflow is not a substitute to writing an API reference guide. Are you saying that Ember never planned to document anything of their framework? That sounds like a big problem.
Post reply on HN