Live data from Hacker News

Ask HN: Why is everything in JavaScript changing so fast?

news.ycombinator.com

141–150 of 303 posts

Re: Ask HN: Why is everything in JavaScript changing so fast?

#141
Because nobody has yet invented a compelling way to write JavaScript applications, so people keep trying. We're still waiting for the Ruby on Rails of frontend development.

I'm not saying Ruby on Rails is the best backend framework (I don't use it anymore), but when it came around everybody understood that it was getting something right. It popularized a new model for server-side web development that all other communities started to follow and improve. When it came out, most developers who were already working with the web could see that it would be very useful, it solved real-world problems they had, it just made sense.

This is much less clear with JavaScript frameworks. They usually have a tough learning curve and the benefits are not always coming as expected. So people keep trying to find a model that works well.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#142

Earlier quoted context omitted.

the lack of a good standard library might have something to do with it. I'll admit im not sure.

The shaming of mature libraries doesn't help either. Try showing off something with jQuery these days.

Yeah. I've just taken to ignoring those responses.

As far as I'm concerned, jQuery & lodash are part of the "standard library". Certainly there are cases where one or the other isn't needed for a particularly application. But if you're doing anything with the DOM, or doing anything more complex than simple if/then callbacks, you're either using them or you're reimplementing them bit by bit.

Certainly jquery has some... warts... but I haven't seen any project emerge that's succeeded at being a cleaned up replacement. And jquery 3.0 looks like it's trying to forge ahead in that direction itself.

(Still hate jquery's inconsistent ajax callback signatures. sigh.)

Re: Ask HN: Why is everything in JavaScript changing so fast?

#143

Because nobody has yet invented a compelling way to write JavaScript applications, so people keep trying. We're still waiting for the Ruby on Rails of frontend development. I'm not saying Ruby on Rails is the best backend framework (I don't use it anymore), but when it came around everybody understood that it was getting something right. It popularized a new model for server-side web development that all other commun…

I would say react is the way to write large data driven applications, but JavaScript, without a tool like Google closure, is not suitable for 100k lines of source code app that is being actively developed. Personally I am playing around with typescript and webstorm and that seems to me to be good enough.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#144

Earlier quoted context omitted.

There is a (perhaps apocryphal) story about the art class which was separated into 2 groups - one group worked on a single project all semester and the other group worked on a new project every day. People in the group that worked on a project every day produced better work than people in the "single project" group. My google-fu is weak, so I cannot find the reference. I'm not suggesting that the Javascript ecosystem…

This is the running premise behind the book Art and Fear, which basically concludes that iteration with quality feedback is the best way to develop your abilities and produce your best work. That is, quantity is the best path to quality. https://www.amazon.com/Art-Fear-Observations-Rewards-Artmaki...

Thank you!

Re: Ask HN: Why is everything in JavaScript changing so fast?

#145
post #95

Earlier quoted context omitted.

In my experience working with Perl and Python most external libraries work and are well documented. Whenever I have tried JavaScript its a vastly poorer experience. Admittedly I have far more experience with the first two languages, but that would likely find more problems with Perl or Python, no? (I don't really do PHP, but I have a feeling that I would find the experience closer to JavaScript from talking to collea…

I've never had problems with docs in JS, both node and browser. The MDN is a limitless ressource of information for the base language, and for libraries, well you're going to get undocumented libraries in any language. It might be more "obvious" in JS because of the sheer amount of libraries, but I've found python libs that were very poorly documented too. This is a problem we should be HAPPY to have. Having librarie…

I think the other poster meant 3rd party libraries, rather than the runtime.

That said, the docs on (most of) the libraries I have used are generally pretty good.

* Prototype - excellent docs (but library since overshadowed by jQuery)

* jQuery - initially the docs were hard to follow, but they seem to have gotten better

* Angular - good enough docs, and plenty of books on the larger concepts of how things fit together

* moment.js - excellent docs

* validatejs - excellent docs

* Ramdajs - generally excellent docs, but I am less familiar with some of the FP concepts used in a few cases.

The quality on some of the jQuery and Angular plugins varies a bit, admittedly.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#146
Because you can write a new JS/HTML framework in a few days. Compare this to e.g. Qt or GTK or WinForms or WPF. Each of those would require man years of effort to reproduce from scratch.

Also these JS frameworks tend to be opinionated with how databinding works etc, such that there's always something that you have to work around when you're using the framework in real-world projects. People get annoyed enough that hey it's easier just to create another framework.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#147

Because nobody has yet invented a compelling way to write JavaScript applications, so people keep trying. We're still waiting for the Ruby on Rails of frontend development. I'm not saying Ruby on Rails is the best backend framework (I don't use it anymore), but when it came around everybody understood that it was getting something right. It popularized a new model for server-side web development that all other commun…

I remember the, well, "rage" I had at Sun when I stumbled across RoR. I had completed my Java web certification the year before. The Java stuff seemed clumsy and repetitive. One year later, saw Rails. "Why couldn't you geniuses have done something like that, instead of this mess you gave us?!?"

Re: Ask HN: Why is everything in JavaScript changing so fast?

#148

In an industry without a guild / license / what have you, the incentives skew towards articles of proof. Articles of proof could be demo websites, screen shots, and open source libraries. Being the creator or top two contributor of a library is now worth so much more than being a small time contributor that the incentives are skewed towards everyone just making a new thing, always. It's their way to stand out. So why…

> The python API would likely be no slower and much easier to write and debug. But probably not for your qa engineer who most likely already (and possibly only) knows javascript.

Who needs more than one language?

One language is all we need? Who needs Assembler or C or LISP or HTML or CSS or Bash Script or Python or Perl??? WHO NEEDS THAT?

SINGLE STACK!! /s

Re: Ask HN: Why is everything in JavaScript changing so fast?

#149
My theory, which I think goes fairly against what others will say here, is that JavaScript/Node is the first truly post-internet environments to reach critical mass. By post-internet I mean they consider sharing and open source as foundational to the environment (as opposed to tacked on later, or merely supported).

The "JavaScript standard library" (or lack thereof) is a clear example of this: NPM is the LARGEST collection of packages of any language, and you can almost always find someone who has already written what you need most the time. It never ceases to surprise me. During the Pokemon Go craze I was curious to play with the protocol: there was already a package to do it. I wanted to ping my find my iPhone, there's already a package to do that. Its incredible. And yet the actual built in standard library is notoriously lacking. Although not by design, certainly the end result is that that has become "OK" thanks to NPM.

Compare this to something like AppKit (and UIKit), which were very much in the pre-internet/sharing mentality: there is one framework everyone has and becomes experts in and is fairy stable, because its kind of the only thing you can rely on being around. Sharing code is very difficult, to the point where just copying and pasting files is still a valid contender.

The explosion of options and the increase in churn is a natural consequence of this. There are simply more people working on more problems, all encouraged by an environment where sharing code is a fundamental property. If step 1 of setting up node is downloading other people's random packages then it should be no surprise that step 4 of sharing your own packages will seem natural. We should expect this to only get faster -- the more people program, the more crazy ideas will be tried, the more switching there will be. I really don't understand what the alternative is: arbitrarily choosing frameworks to be around for a 5 years (a decade?).

We are simply taking the last measure of stability, which was largely governed by how long it used to take information to disseminate to the entire community, how long it used to take one controlling body to get their large waterfall releases out the door, and using that as an arbitrary comparison point to how long it takes hundred of individuals to release their individual takes on software. Asking to "stop the churn" is a strange request: there's no single entity pushing stuff out "too fast", this is the aggregate affect of all programmers in the node community publishing their ideas. Who are we asking to slow down exactly? I can understand saying the single case of Angular 1/2, but the "JavaScript fatigue" people actually feel is due to the interaction of all the JavaScript projects that each gain and lose popularity.

Unless you believe we're really close to figuring this whole "software development" thing out (whatever that means), I wholeheartedly believe that programming 20 years from now will look more like this -- faster pace of developments.

Post reply on HN