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

171–180 of 357 posts

Re: The State of JavaScript – Survey results

#171

Post by Forlien »

labrador wrote: post #161
Illniyar wrote: post #125

Earlier quoted context omitted.

> somehow JS devs have decided switch statements are bad huh. You obviously haven't played with Redux yet, it's basically switch statements all they way. The JS community is the biggest programming community in the world, there is no way you can lump anything on the community as a whole.

Redux is a wonderful piece of software and of course I use switch statements. I was referring to this question on reddit/r/javascript which kind of boggled my mind. I didn't know there were people advocating against switch statements. https://www.reddit.com/r/javascript/comments/2582qv/is_switc...

Did you link the wrong page? It looks like they are advocating switch statements.

Re: The State of JavaScript – Survey results

#172

Post by OhSoHumble »

lightblade wrote: post #167
kowdermeister wrote: post #165

Earlier quoted context omitted.

The reason is probably that it's closely tied to Rails. I don't want to learn Rails, but I keep seeing Ember and Rails mentioned together. Probably the same community is behind them (too lazy to look up). I don't really know where I have this preconception from, but probably it's not just me. http://discuss.emberjs.com/t/are-developers-creating-ember-a...

Ember has zero ties to Rails. We are using Ember with Java backend. I have seen Ember used with .NET and Go backend. There are even the SANE stack [0]. The only possible tie that Ember with Rails is that it used to bundle ActiveRecordAdapter with Ember data. It is now separated into another project possibly due to this exact reason. [0]: http://sanestack.com

I think that project is still under ember-data?

https://github.com/ember-data/active-model-adapter

Re: The State of JavaScript – Survey results

#173

Post by jordanlev »

OhSoHumble wrote: post #152

It's really unfortunate that so many people aren't interested in learning Ember. I just started an internal IT tool in Rails and Ember and I'm really enjoying the simplicity of it. I want something that is easy to understand, easy to setup, and won't change for a while. I became more interested in Ember when I read something online about how they are focusing on stability in the long term instead of a bunch of featur…

To each their own. I tried learning Ember many times (due to my admiration/respect for Yehuda Katz), but it was always too confusing for me. Vue.js is what I use now, because it's the only front-end framework I was ever able to learn and use in real-world projects.

Re: The State of JavaScript – Survey results

#174

Post by carapace »

(Thin sans-serif grey body text means you hate your readers.)

-----

edit: I've tried to read it now and this site is crappy as hell. Does anyone have a link to a coherent write-up of these results?

-----

Furthermore, I know it's bad form to mention your own downvotes but I dare you I DARE YOU to make a case for that horrible font choice. You can't because it's pure vanity. Style over substance. Thhhpppppt!

Re: The State of JavaScript – Survey results

#175

Post by bcheung »

One thing I have noticed over the years is that the front end community is becoming more and more a "let me google how to do it" kind of community. The tooling ecosystem is so burdensome. Just to get a hello world app with React, Redux, Webpack, esLint, and ES6 takes forever. Sure there are starter boiler plates but they all don't seem to do quite what you need. Before it felt more like a solidly engineered app, now it feels a lot more like glueing various snippets from StackOverflow together.

I'm also finding the overhead from React / Redux very noisy. I have to do so much typing and define the same thing over and over across a bunch of different files just to do something simple.

I really like how Elm basically implements all of this with much cleaner syntax and works out of the box. It's too bad it doesn't have as much community behind it. I'd like to use it more but find it doesn't have enough community for me to consider using it for anything outside of home projects.

Re: The State of JavaScript – Survey results

#176

Post by ufmace »

Nice article. I started a new hobby Rails project a couple of months ago and was a little surprised to see that even Rails 5 still defaults to Coffeescript. Googled around a bit and decided to drop it, as it seems to be more or less abandoned these days, which this survey seems to confirm. I wonder if/when Rails will switch to ES6 or something?

Re: The State of JavaScript – Survey results

#177

Post by thisisblurry »

sgdesign wrote: post #27
savanaly wrote: post #5

Great job on the interactive presentation.

Author here, thanks!

I agree; it looks really nice!

Minor nit: would you be open to using colorblind friendly color choices in the future? The current colors are pretty hard for me to differentiate between.

Re: The State of JavaScript – Survey results

#178

Post by lhnz »

Touche wrote: post #59
lhnz wrote: post #47

Earlier quoted context omitted.

I wouldn't say that was spin, I said that build complexity is likely going to be handled by fewer engineers. The underlying problem still exists but less people need to put their oar in: that's bittersweet.

You're pointing to create-react-app as a solution to JS churn when it was just created 2 and a half months ago. The fact that people keep thinking that a 2 and a half month old project is the solution to all of their web development problems is exactly why there's so much churn. Every new tool overtakes the previous generation by being superficially more simple, only to add complexity of its own over time until the n…

I don't think that will happen with create-react-app since its intention is zero customisation.

You can't generate more complexity with a tool that reduces opportunity for developer choice.

A basic example is that a starter app would normally require you to connect 10s of libraries together just to get started. It is difficult to argue that not having to do so is actually more complex.

Post reply on HN