Live data from Hacker News

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

news.ycombinator.com

151–160 of 303 posts

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

#151
post #126

Earlier quoted context omitted.

> without having to think about threads or synchronization. Just pipe data through the channel! I mostly agree with what you're saying, but note having a channel doesn't mean one stops worrying about synchronization. If two goroutines both started waiting for data from a channel they'd be deadlocked.

True, on the other hand, go will take care of that to some extend and terminate if all go routines have been deadlocked. Which means well-designed services will remain available even if only with degraded performance.

I didn't know go can do deadlock detection. Thanks for this, I learned something new today.

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

#152
post #57

Imagine that you have a furniture factory. There is one room where one guy who works for you produces tables. In next room there is another who produces sofas. And then another one who makes chairs. The demand is great, so routinely you hire more people to produce more things. As you walk, you realise that each of them uses selection of screws and chisels and screws and wheels, and types of wood and door handles and…

> Java had its Sun, Python had BDFL Guido, JS has no such thing. For JavaScript the TC39 is responsible for its improvement and standardisation. Thats were ES6 was developed. ES2016 aka ES6 took a fair amount of time, but the TC39 switched to "rolling releases". ES2017 aka ES 7 is already in the works and is going to be released 2017. https://github.com/tc39

Actually, ES2015=ES6, ES2016=ES7, which was released earlier this year. Most people mess that up due to the combination of unfortunate naming and the fact that ES7 wasn't nearly as big of a jump as ES6 was.

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

#153
post #16

The open-source-JavaScript community right now is just the largest, most active open source community that has ever existed. Check out the stats that GitHub recently announced: https://octoverse.github.com/ Open source JavaScript activity as measured by pull requests has doubled (!!) in the past year. It's more than the next two languages (Java and Python) combined. Most of the top repositories on GitHub are JavaScri…

To a large extent this is true because the javascript community is busy with the re-invention of all of computer history, only without applying all of the lessons learned. Activity does not equate quality.

I remember you writing something similar 4 years ago: https://news.ycombinator.com/item?id=5415585

It's definitely frustrating to see. And it's also frustrating to see the vitriolic reactions to anyone who criticizes the current culture of the JavaScript community.

I use React and all of its associated tools and ecosystem, and while I find them productive and useful, the whole situation is a bigger mess than it needs to be. I don't think it's necessarily anyone's fault; I don't see a willful desire to ignore the hard-won computing knowledge we'e accumulated. It just seems as though the JS community's enthusiasm has, at least recently, has exceeded the rate at which good tooling can be developed.

I think that's changing, though. From what I've seen, in the past year there has been more of a push toward building mature, reliable, maintainable JS applications. I've also seen more interest in optimization. The Closure Compiler has been around for a long time, and at least in the Angular 2 community I've noticed jump in the number of people looking to use Closure and other tools like Rollup to optimize everything and deliver the smallest possible code bundle to the browser. And ES2015's statically analyzable modules go a long way toward making more optimization possible.

So I agree, things are a bit crazy. And I agree that activity does not equal quality. But there's a lot of activity, and some of it is of high quality. I can't guarantee that the high quality work that brings more of those lessons learned to the JS world will become popular, but I'm at least seeing a positive trend in that direction.

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

#154

The problem is that everything in JS exploded during just few years (Node was published in 2009), and it took few years to build tooling around Node to start utilising all this power. And then everyone started to build "rich" web applications (it is called differently every year), with the "best" tool existing. I personally see two major problems – usually cool startups who can afford using the bleeding edge will die…

> Also, the barrier is low, and therefore we have a lot of complex websites built by novices, running in development mode in the actual production.

I'm not a huge fan of the "Javascript programmers are novices" myth. It's quite damaging.

Javascript is a kitchen-sink language these days in the ES6+ world. You've got the functional programming features... monads, functors, applicative and even immutable data structures are just a library. You have classes, interfaces, protocols and of course event-driven programming, prototypes, etc, etc, etc. It's not a small spec these days.

The point is that there are smart people who use the language to great effect. Enough with the "unwashed masses," story please.

Personally I'll take an ML or Lisp based language anyway... but thankfully I can have my cake and eat it too by compiling to Javascript.

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

#155
post #129
post #94

Earlier quoted context omitted.

It's easy to sit back and critisize JavaScript and the web with dismissive comments like this. I have heard variations on these same memes for many years. But something that I almost never hear: critics offering a candid explanation for why their platform / language / framework - which maybe wasn't perfect but CERTAINLY compared to JavaScript was awesome - did not become the de facto tool across as diverse a spectrum…

> But something that I almost never hear: critics offering a candid explanation for why their platform / language / framework - which maybe wasn't perfect but CERTAINLY compared to JavaScript was awesome - did not become the de facto tool across as diverse a spectrum for delivering features / products / tools to users. Because JavaScript was, and basically still is, the only option for client-side web development - t…

There's a certain amount of irony in mentioning "Worse is Better" in this context.

People trying to use Javascript as a surrogate C++^H^H^H Java will be sorely disappointed.

People trying to use Javascript as something that blends Scheme and Smalltalk will be using it as its creator intended. While this won't make the extreme purists happy, for many of us, Javascript is an acceptable Lisp.

I have come to prefer Javascript to Java (or C#), but most of my coworkers still think in Java, so that's another issue :-)

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

#156

The problem is that everything in JS exploded during just few years (Node was published in 2009), and it took few years to build tooling around Node to start utilising all this power. And then everyone started to build "rich" web applications (it is called differently every year), with the "best" tool existing. I personally see two major problems – usually cool startups who can afford using the bleeding edge will die…

Soon we'll have trouble hiring Angular 1 devs to maintain legacy code, like COBOL. Except COBOL started in 1959, not 2009.

It seems to me that many big companies are asking for Java + Angular skills these days; and that many new projects are build using that stack. This has the effect that it is still very worthwhile to learn Angular 1. I don't think it is going anywhere soon, plenty of companies are invested in it.

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

#157
post #16

The open-source-JavaScript community right now is just the largest, most active open source community that has ever existed. Check out the stats that GitHub recently announced: https://octoverse.github.com/ Open source JavaScript activity as measured by pull requests has doubled (!!) in the past year. It's more than the next two languages (Java and Python) combined. Most of the top repositories on GitHub are JavaScri…

It is not because something is larger that it is better.

These stats prove the hype, not that it is good quality code, with good quality documentation, with a friendly and safe community, and a reliable archiving system for it's dependencies.

I have nothing against JS in particular, but there is a bit too much hype about it.

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

#158
post #126

Earlier quoted context omitted.

True, on the other hand, go will take care of that to some extend and terminate if all go routines have been deadlocked. Which means well-designed services will remain available even if only with degraded performance.

I didn't know go can do deadlock detection. Thanks for this, I learned something new today.

it's not a 100% detection. You can certainly pile up deadlocked go routines, but the way most libraries (including the standard library) are setup, if you were to write some server, you'd only deadlock on the request but the app keep running. There is no way to reliably detect that but the service will probably service most requests if you didn't plain deadlock everything.

If all go routines are deadlocked, the runtime will terminate the service.

It's a kind of graceful and somewhat safe degradation.

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

#159

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

Hmm. The "fear" aspect sounds a lot like what Steve Yegge called software conservatism.

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

#160

The problem is that everything in JS exploded during just few years (Node was published in 2009), and it took few years to build tooling around Node to start utilising all this power. And then everyone started to build "rich" web applications (it is called differently every year), with the "best" tool existing. I personally see two major problems – usually cool startups who can afford using the bleeding edge will die…

My hope is that with WebAssembly, it will stop mattering.

JS development will probably go on like if nothing changed, but people that don't like it will be able to opt-out.

Post reply on HN