Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of JavaScript – Survey results

stateofjs.com

Post reply on HN
Print view View original

141–150 of 357 posts

Re: The State of JavaScript – Survey results

#141

Post by slavik81 »

cloverich wrote: post #106
DarkTree wrote: post #82

Earlier quoted context omitted.

Yeah I think there is just a lot of friction when moving from the concise "ES6" to the lengthy, and somewhat awkward "ECMAScript2015". The fact that so many people still use the terms ES6 and ES7 gives others even less incentive to use the official naming scheme. Hopefully, it will iron itself out in the future.

I think its not just the length but the concept: Every other language has a normal looking version (Rust 1.12 announced! Java 8, etc). They had that with ES3, ES5, ES6, then decided (perhaps for very good reasons) to change to a unique (?) version scheme.

C and C++ also use years. For example, C99 was standardized in 1999. C++11 was standardized in 2011.

Re: The State of JavaScript – Survey results

#142

Post by at-fates-hands »

inputcoffee wrote: post #44

I appreciate that for the next year when there is a framework war I will have a link to shut it down. Typically a newbie will ask about which framework they should learn. There will be a bunch of "it depends" and "try them out" responses, and then someone will take pity and pick a clear direction based on their experience. Well and good. But this way the newbie can learn from the actual experience of lots of other pe…

>> Typically a newbie will ask about which framework they should learn..

Honestly the easiest way to learn this is to contact your local recruiters and ask them to send you some openings for FED positions.

In nearly every one, you will see which JS framework is the main one they use. In my recent experiences (the last two or three years) most corporate environments are using AngularJS, while the smaller startups are using React and some mix of various other libraries for their apps and sites.

There are still a few agencies I know using BackboneJS, since it was in that first wave of JS frameworks and there's apps and sites out there which still need supporting.

Re: The State of JavaScript – Survey results

#143

Post by crucialfelix »

solidr53 wrote: post #114
pauljaworski wrote: post #89

>Overall, developers are not happy about JavaScript testing. This is because of the low percentage of devs in the survey who have used Jest. I can't begin to describe the joy of finally finding a JS test utility that just works and doesn't require a giant configuration file. If you aren't using Jest, make the switch now! It's likely a lot of your existing tests will work with Jest.

I used Jest early on, it was nice, but I quickly started to encounter problems related to how new it was. It's way better now, so maybe I will switch back to Jest from enzyme.

The only things I found really annoying ... Completely disappeared in the last major update. Very clean to work with now.

Re: The State of JavaScript – Survey results

#144

Post by anamoulous »

BinaryIdiot wrote: post #78
anamoulous wrote: post #24

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 asynchronou…

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

I'm talking about the various schisms that have led to this page: https://nodejs.org/en/download/releases/

It's not a big deal once you familiarize yourself with what everything means, it's just a good example of some ecosystem baggage.

The ubiquity of using babel to get future language features also obscures the relevance of any one version of the runtime.

Re: The State of JavaScript – Survey results

#145

Post by tboyd47 »

drhayes9 wrote: post #103
vlunkr wrote: 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.

webpack allows some pretty sophisticated resource pipelines that go beyond what you can do with browserify, especially around binary resources. One of my use cases is working on a HTML5 game. I pre-process all the tilemap levels to add unique IDs to the entities within the file, but only for those JSON files that look like tilemaps. Each of those files' names get mangled as a hash of their contents as well, so I get…

Awesome. Guessing you wrote your own Webpack loader for tilemaps? I'd love to hear more about what went into that.

I had the same reaction as GP when I first saw it (meh, just another overly complex tool, who cares) but you can really do some ridiculously cool stuff with it. I also love how stable it is, compared to the ecosystem it's associated with.

Re: The State of JavaScript – Survey results

#146

Post by badthingfactory »

vlunkr wrote: 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.

What else have you tried? All of the alternatives have left me compromising on the way I build my front ends. The docs for Webpack aren't great, and configuring it might be a bit painful, but if there's a better option I would love to know what it is so I can start using it.

Things I want:

* es2015 transpiling * jsx support * css/less/sass support * module loading * uglification for production builds * hot module replacement * source maps * multiple bundles/entry points * hashed file names

Brunch fulfills a lot of these requirements, and I use it when I need to spin up an application really quick. But it misses on just enough items to make me reach for Webpack when I build anything serious.

Re: The State of JavaScript – Survey results

#147

Post by xtiansimon »

"It would also be a great resource for people looking to learn a technology and want pointers on where to start."

Second that comment.

It strikes me as a brilliant that open-source programming languages should have these sorts of statistics. I wish I could see every OSS language reported like this...hmmm. I would replace the stock market ticker in my phone with that!

Post reply on HN