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

251–260 of 357 posts

Re: The State of JavaScript – Survey results

#251

Post by OhSoHumble »

joshowens wrote: post #215
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…

I suspect that we didn't get enough Ember responders, because I do think they have a reasonable sized community. 9k responses is likely not enough to draw a reasonable conclusion that it isn't popular. I wish we could have paired up npm downloads or some other stat besides some of this data...

What kind of was a head scratcher for me was that Ember had such a high rate of "heard of it, not interested" from the responders. Especially when I looked a couple columns over at the Angular 1 data where a lot of people tried it but would never try it again.

I don't know how a sample of 9k maps to the developer community at large but I found it puzzling that so many people were dismissive of Ember. What makes Ember unappealing enough to not warrant being tried out in a side project? Personally, I saw it and thought "boy, a framework that wants to be stable for several years - sign me up."

Re: The State of JavaScript – Survey results

#252

Post by davidjnelson »

Touche wrote: post #35
lhnz wrote: post #18

Earlier quoted context omitted.

It's not so much that churn has been greatly reduced, but that the worst churn has started to be centralised and hidden behind tools like `create-react-app`. There will still be more churn as people come up with ways to be more productive, however it will be hopefully concentrated in areas other than build process tooling.

You're spinning this as a positive thing, but the fact that a UI library needs its own build tool does not speak well to the state of front-end development. Specifically the fact that we still don't have modules or widely-deployed http2 is what makes the build tool complexity necessary.

I remember building Windows ui apps 10-15 years ago, and that definitely needed a build tool. Http2 might be great for module loading, so things don't have to be bundled, but there's lots of unsupported use cases right? Css encapsulation, autoprefixing, hot reloading for dev, compiling features not yet in browsers into js versions supporters by browsers etc.

Re: The State of JavaScript – Survey results

#253

Post by rojobuffalo »

tiglionabbit wrote: post #219
rojobuffalo wrote: post #86

Earlier quoted context omitted.

Respectfully disagree--I like Relay better. And Relay 2 is including client-side state, so you don't need Redux. It has a steep learning curve and some initial setup overhead; but from a long-range perspective--I think it will have better performance and code comprehensibility. Maybe Apollo is better suited for freelancers though.

I thought Relay already had client side state? Also what's Relay 2? Where are you finding information about it? My opinion of Relay right now is that it has way too many needless complications. It looks like it brought a ton of baggage from being used in Facebook that just gets in the way of general use. So I'm interested in an alternative. However, the real problem with all of this stuff is cache management. Properl…

By client-side state, I mean user interactions that affect variables used across the app that don't need to be persisted. Relay doesn't do that yet, as it only deals with persisted data. @josephsavona[1] and @wincent[2] are the guys putting information out about Relay 2. Greg Hurrell (@wincent) did a talk[3] about it in August.

And since I'm linking to related resources, I just want to add a plug for an awesome project a friend is working on (and we're putting it into production on my startup project). @calebmer/postgraphql[4] let's you get a free GraphQL API from a PostgreSQL schema.

[1]: https://github.com/josephsavona

[2]: https://github.com/wincent

[3]: https://www.youtube.com/watch?v=OEfUBN9dAI8

[4]: https://github.com/calebmer/postgraphql

Re: The State of JavaScript – Survey results

#254

Post by davidjnelson »

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…

Create-react-app is a great idea, but I found it really didn't cover enough use cases.

Re: The State of JavaScript – Survey results

#255

Post by adjkant »

As someone who doesn't work incredibly often with Javascript but has dabbled with MEAN and extensions of MEAN, I found one of the last questions a bit biased in its results:

"I would like JavaScript to be my main programming language" (Rate 1 to 5)

49% (5) 35% (4-3) 16% - (2-1)

If you've taken this survey, it means that you have done at least a decent amount of work with Javascript. Chances are, you have at least enjoyed something about it so far, or are absolutely required to use it for some reason.

Of course many current Javascript users want it to be their main programming language.

I love this survey for so many reasons, and this is an incredibly small point. Personally, I think that a good Javascript tool, framework, flavor, whatever, should be able to easily integrate with other technologies. I really enjoyed Angular for that reason (yet to dive into React). I think the idea of "JAVASCRIPT EVERYWHERE" is just really unneeded. Yes, we are stuck with Javascript as a language. Yes, it should be more than a simple afterthought on top of other tech. Making Javascript better and safer doesn't mean you have to do it everywhere, because ubiquitous Javascript doesn't matter if the different dependencies are completely different anyways.

The last part is only my opinion, but I wanted to add it because I think the survey's nature is going to exclude many people with it.

Re: The State of JavaScript – Survey results

#256

Post by SureshG »

EugeneOZ wrote: post #216
wstrange wrote: post #79

Earlier quoted context omitted.

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.

JSON support is awful, "optional types" means "no types". Thanks, but even TS is better.

Enable strong mode. It's pretty neat - https://github.com/dart-lang/dev_compiler/blob/master/doc/ST...

Re: The State of JavaScript – Survey results

#257

Post by OhSoHumble »

sotojuan wrote: post #249
OhSoHumble wrote: post #239

Earlier quoted context omitted.

Why the dismissive "huh?" Was there anything I said that was incoherent or not easily understood? "Does it have a better story for cache management or something?" I think this question shows a misunderstanding of what I'm trying to convey. I can't really offer a set of deep technical answers when contrasting the various JavaScript frameworks. Most of my use cases for front end development comes down to some pretty si…

What did you use to learn Ember? I'm also in the "convention over config" camp and I love that the Ember team sticks to it but also introduces new tech like FastBoot whenever they can.

https://news.ycombinator.com/item?id=12631268

That's the comment that listed the article I followed. It's pretty tightly coupled to Rails and ActiveModel but it fit my use case pretty well. I found other resources as I googled around.

I used https://github.com/thoughtbot/ember-cli-rails to hook up Rails and Ember.

I found that I still had to tweak a couple of things like getting generated Rails controller to `render :json` by default but the article was fairly comprehensive.

Re: The State of JavaScript – Survey results

#258

Post by fbonetti »

bcheung wrote: post #175

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…

I'm not sure why you've been downvoted. I absolutely LOVE that Elm simplifies the boiler plate of a front-end app. Instead of needing a dozen different packages and tools, you basically just need the Elm core library and you're good to go.

Re: The State of JavaScript – Survey results

#259

Post by OhSoHumble »

fatbird wrote: post #158
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…

Virtually every JS tool/lib/framework sells itself as "simplifying" something, and they usually do. It's the overhead of constantly simplifying that's murdering our productivity.

I think it depends on how you quantify "simple." If you refer to simplicity as a small framework or library with very little moving parts, e.g react or sinatra, then that's one way to arrive at a definition. However, complexity in a designed problem arises when you need to take a large variety of 'simple' components and mesh them together to solve a problem.

In this context, I'm defining simplicity as low barrier to entry and/or easy to understand ideas. I think of myself as a fairly average developer; that I'm not wholly intelligent or skilled. I want a framework that bosses me around and tells me what to do.

Accomplishing simple tasks like mapping JSON returned from Rails to Ember routes and rendering that data into a table was very easy for me to understand and do. The simplicity I'm talking about was the setup, generation, and mechanics of the process. Ember, as another commenter pointed out, is not simple internally. It is glued together using evil magicks as far as I'm concerned. But I'm happy about that because when something does break, it means that I'm doing something that is going against convention or that something is truly broken.

As far as the former, then I need to learn the convention. For the latter, then I need to post questions in forums, hit up IRC, etc. But the positive aspect about the second process is that my project is already fully set up and I'm comfortable with my framework enough that I don't feel completely out of water.

Re: The State of JavaScript – Survey results

#260

Post by tolmasky »

adjkant wrote: post #255

As someone who doesn't work incredibly often with Javascript but has dabbled with MEAN and extensions of MEAN, I found one of the last questions a bit biased in its results: "I would like JavaScript to be my main programming language" (Rate 1 to 5) 49% (5) 35% (4-3) 16% - (2-1) If you've taken this survey, it means that you have done at least a decent amount of work with Javascript. Chances are, you have at least enj…

Its interesting because the reason I think "JAVASCRIPT EVERYWHERE" is valid is because I think "EVERYTHING EVERYWHERE" is valid. Don't get me wrong, some languages are incredibly domain specific and don't make a tremendous amount of sense at all parts of the stack (and some parts of the stack should have domain specific languages), but JavaScript is a general purpose language, that has some interesting things to offer different domains (whether it be server development, app development, etc), but most importantly... SO DO MOST OTHER LANGUAGES! I would love a world where I could choose from most general purpose languages for most tasks. I haven't found many reasons other than "why?" for being against JavaScript being everywhere. I know that if I was a Ruby guy I'd certainly like it if I could use Ruby in as much of the stack as possible, and I think that's totally reasonable. For example, I applaud transpile-to-JS languages so that you can use a language of your choice for the browser (vs thinking "why do we need Clojure everywhere!").
Post reply on HN