Live data from Hacker News

The State of JavaScript – Survey results

stateofjs.com

71–80 of 357 posts

Re: The State of JavaScript – Survey results

#71

ES6, CoffeeScript, and TypeScript all have near-perfect awareness, which surprised me since TypeScript isn’t quite as popular as the other two yet. I take issue with that statement. Just anecdotal, but I think these days Typescript is much more "popular" than CoffeeScript

Anecdotally, CS appears to have lost quite a bit of popularity while TS gained some.

RedMonk seems to confirm these trends. TS grows while CS stagnates:

Q1 2016: http://sogrady-media.redmonk.com/sogrady/files/2016/02/lang-...

Q3 2016: http://sogrady-media.redmonk.com/sogrady/files/2016/07/lang....

Re: The State of JavaScript – Survey results

#72
post #52

I'd love to hear more from people that expressed certain viewpoints - specifically those who used a library but wouldn't use it again... Specifically mobx :) I've played with most popular js libs now and I've found that for my use case I wasn't totally happy for one reason or another. I've been dabbling in mobx for that last few weeks and the ease with which it has allowed me resolve issues in my codebase is really p…

After using Mobx for a few weeks, I've come to question why anybody would use anything else. It is the only software I've ever used that was created for a dynamic language that has me trying to re-implement in my favored strong/static typed languages. Now I just point and laugh at anybody trying to make sense of their Redux global state atom with a bajillion reducers.

So far, I've only found one common objection to it: that it embraces mutable state. Well duh...UIs are state machines. They need mutable state because their entire existence depends on it. Sure, you might be able to model the mutable state of UIs using immutable data structures, but you can't get rid of the mutable state. And because of this, my opinion of this objection is that it is of a religious nature. You can ignore this particular objection with no risk at all.

Re: The State of JavaScript – Survey results

#73
post #64

For the life of me I can't understand why webpack has become the de facto build tool. It's so much more complex than anything else I've tried. I understand it's supposed to be faster, but still, I wouldn't bother with it until your build times actually start to become a nuisance.

[deleted]

Re: The State of JavaScript – Survey results

#74
post #28
post #9

Earlier quoted context omitted.

I see this same, tired old meme in every thread about web technologies. It's funny to me that certain people are so disdainful of the churn in web development on a forum dedicated to "hackers". Web application development is hard, and the reason why there's so much churn is because smart, inventive people are constantly finding better ways to do things. Things aren't just resetting from scratch every 18 months. The w…

> "... the reason why there's so much churn is because smart, inventive people are constantly finding better ways to do things." It also follows that at some point, these smart, inventive people will come up with fairly stable frameworks that are sufficiently flexible and powerful to accommodate most of the problem space out there. It is reasonable to ask if such a point has been reached...

Depends on the space.. for example, Express has been pretty stable.. Angular 1.x has been as stable as anything else for the most part... Node's mostly been progressive additions, and features from engine updates since 0.10... npm has been pretty stable since node 0.10, though there's been significant advancements since npm 3 came out.

Browserify -> Webpack has been noisy. Babel 5 -> 6 equally noisy, but better for moving forward

Today, I think webpack, babel, react, redux and fetch cover a LOT of ground for client-side dev. There's a few other bits around that, and I think CSS tooling is starting the a similar shakeup to node's tooling options.

In the end, almost all the JS features I care about seem to be at stage-3 now, so who knows when they'll be in the major browsers.

Re: The State of JavaScript – Survey results

#75
post #3

Super interesting. Lots of data there. Two things that stood out from a quick once-over: Vue is doing better than I expected. PostCSS is less adopted than I expected.

I hope Vue is going to be quite popular. I haven't actually used it but have looked at the documentation and have heard so many people praise it. I have only heard of good things. It just doesn't have the support like Angular or React has from the big Companies.

Re: The State of JavaScript – Survey results

#76
post #9

Earlier quoted context omitted.

I see this same, tired old meme in every thread about web technologies. It's funny to me that certain people are so disdainful of the churn in web development on a forum dedicated to "hackers". Web application development is hard, and the reason why there's so much churn is because smart, inventive people are constantly finding better ways to do things. Things aren't just resetting from scratch every 18 months. The w…

I agree that a lot of the churn is each generation (a generation here seeming to be about a year) of tools learning from and building upon the former. Obviously the churn is continuing since developers realize that the tools are quite "there" yet. My hope is that some year we will finally reach "there" (not perfection, but highly good enough) and the churn will slow down to the point that perhaps the generation time…

Well, most of the features I care about in JS are in stage 3 now. Webpack 2 will get the tree shaking, and babel seems ready to work with both. It think the CSS options are next in line to see some shakeup... I've been liking what I'm seeing from JSS, though I still use mostly sass at work.

Re: The State of JavaScript – Survey results

#77
post #61

Earlier quoted context omitted.

I always thought relay was an alternative to redux

Not really. Relay is mostly designed around querying a backend data store, not updating/managing client-side state.

Relay v2 will bring with it a way to manage client side state.

Re: The State of JavaScript – Survey results

#78

I apologize if the predictability of this comment, but I just want to say, I recently started a new gig at a company that has undergone a full on embrace of Javascript for tooling and server side projects and it boggles my mind how much productivity is wasted on this ecosystem. There is an interesting amount of energy put into making asynchronous code read synchronously in situations where asynchronous code provides…

> There is an interesting amount of energy put into making asynchronous code read synchronously in situations where asynchronous code provides no benefit.

I see many new / intermediate people trying to do this. They want to make everything asynchronous when it does make sense to. You want asynchronous when you're accessing an external resources or for something low running (in which case yields / multiple asynchronous calls are necessary to free up the thread for GUI rendering if we're talking web browser here).

I do not like the new async / await syntax. Some days I think I'm alone in this but synchronous and asynchronous are two very different use cases and I think allowing both to be represented the same way can be highly confusing.

> The dependency tree of any one project tends to be incomprehensibly sprawling

This is entirely developers faults. NPM gives you A TON of rope to hang yourself with and every project I jump into people use libraries without considering to their dependencies and end up with a tree of over 3,000 dependencies. It's absolute madness!

> Runtime version numbering is... weird

Semantic versioning has been around for quite some time. I used it when I did Java and C# development; is it really that weird? Is there something about it that's weird?

> Don't even get me started on the interplay of Gulp, Grunt, Webpack and NPM.

NPM is kinda necessary for dependency resolution but beyond that gulp, grunt and webpack are all replaceable with simple scripts. It's actually one of the best and worst things about the JavaScript ecosystem: you can make your build work and behave in any way you want but you have to write the code or learn one of many build systems to do this. In other spaces, like Java, you typically just have ant and mavin and no one bothers with anything else.

Re: The State of JavaScript – Survey results

#79

I apologize if the predictability of this comment, but I just want to say, I recently started a new gig at a company that has undergone a full on embrace of Javascript for tooling and server side projects and it boggles my mind how much productivity is wasted on this ecosystem. There is an interesting amount of energy put into making asynchronous code read synchronously in situations where asynchronous code provides…

Give Dart a try.

It has a single dependency management tool (pub), support for Angular 2, and is generally a joy to use.

Material widgets for Angular 2 (the same ones Google uses internally to build Adwords) are expected to be announced at the Dart summit in October.

Re: The State of JavaScript – Survey results

#80
post #64

For the life of me I can't understand why webpack has become the de facto build tool. It's so much more complex than anything else I've tried. I understand it's supposed to be faster, but still, I wouldn't bother with it until your build times actually start to become a nuisance.

I don't think webpack is best considered as a build tool. It's primarily a dependency wrangler - it lets you define entry points, which can declare arbitrary dependencies on assets, which can then declare their own dependencies, forever and ever, and webpack will wrangle all that into a single JS file, a single CSS file, or whatever it is you need. As it happens one can also do build-tool stuff (transpiling, prefixing, etc) on the resulting files, but that's not where the magic is.
Post reply on HN