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

111–120 of 357 posts

Re: The State of JavaScript – Survey results

#111

Post by BinaryIdiot »

sotojuan wrote: post #90
BinaryIdiot wrote: post #78

Earlier quoted context omitted.

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

The problem with frontend is that making code synchronous blocks the client—even if it's something that "should be" synchronous. If it's anything more complex than a loop or a map through an array, it's recommended you make it async.

Making something asynchronous doesn't do anything magical to unblock the client; a long running asynchronous call that's not accessing an external resource will block the client just as much with the only differencing being the scheduler gets freed up just before running the asynchronous code. If you have something long running you need to use a generator yield pattern (process in pieces with ES5). I addressed this in my initial comment.

Re: The State of JavaScript – Survey results

#112

Post by arxpoetica »

darksaints wrote: post #72
aidos wrote: 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 i…

I'm really interested in what you're saying about UIs as state machines. Do you have any articles/references to back this up? Genuine curiousity here.

Re: The State of JavaScript – Survey results

#113

Post by cloverich »

morgante wrote: post #42
Roboprog wrote: post #14

Some interesting things on the "Front End Frameworks" page: * 53% of the respondents used React, and would do so again. * 47% use "No framework", and would do so again. (hmm. that doesn't leave much room, unless you can use more than one tool depending on the situation) * 43% had "no interest" in Angular 2. One other thing to consider, of the "had used X, would/would-not use again" responses: there is of course a lot…

The way I read it is that each question is independent. So I can say I've used Angular and would never use it again while also saying I've used React and would use it again. This is really a pretty decisively positive stat for React. Very few of its users would never use it again, while a lot of people have tried Angular and abandoned it. (This certainly matches my experience and anecdotes I've heard in the community…

> The way I read it is that each question is independent.

Mine as well. I have two active work projects -- one is React, and one is plain Javascript. The latter is to keep the project extremely lean (mobile form single time use type thing) and I've enjoyed using no libraries in it (yet). So I would have responded positively to both of those questions.

Re: The State of JavaScript – Survey results

#114

Post by solidr53 »

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.

Re: The State of JavaScript – Survey results

#116

Post by BinaryIdiot »

Swizec wrote: post #102
BinaryIdiot wrote: post #69

Earlier quoted context omitted.

Same. ECMA changed to using dates a while ago and people are still saying "ES6" and "ES7". I've also seen people refer to all new syntax and features as "ES6" including things that in ECMAScript2017. Honestly though I think ECMA has some of the blame for this. I don't think they do a very good job communicating changes and versioning.

In my experience ES6 means "modern". Anything that wasn't there before 2015. Considering we're encouraging everyone to use transpilers and features from the future, and that browsers will forever lag just a little bit behind, I don't think that's a super bad idea. Most programmers don't care exactly which features are in ECMAScript2015 and which are in ECMAScript2016 etc. All they care about is "Can I do this thing I…

> Considering we're encouraging everyone to use transpilers and features from the future

Please don't encourage this. Transpilers have a huge set of dependencies and technical complexity. I know everyone is in a hurry to use the next standard ASAP but, especially for new people, I think transpilers should be recommended against. Otherwise now you now need a build process and you need to learn how to use map files to properly debug back to your original code not to mention being unable to properly debug on older / alternative browsers.

> Detailed versioning is an implementation detail.

For the engine sure but for everyone who needs the features they need to know what is supported when, etc. It's far, far more than a simple implementation detail.

Re: The State of JavaScript – Survey results

#118

Post by inputcoffee »

So interesting I am still looking at it.

Suggestion: Add an optional section on how the developer learned the technology

I think you could do a really interesting meta-analysis where you could see a relationship between the way things were learned and the popularity of the tool.

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

Re: The State of JavaScript – Survey results

#120

Post by pmontra »

FrancoDiaz wrote: post #16

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

The survey also comments "few developers have used CoffeeScript, and apparently almost nobody wants to learn it" and concludes with "Some technologies [...] proved to be on their way out (CoffeeScript)."

Hopefully DHH recognizes this and deprecates CS out of Rails.

Post reply on HN