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

231–240 of 357 posts

Re: The State of JavaScript – Survey results

#231

Post by PudgePacket »

OhSoHumble wrote: post #196
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…

I'd like to dive into React sometime when I get a side project that needs web development but I am a simple guy and I need a "hey stupid follow these conventions" setup in order to learn and grow and be productive. There are a couple projects out there that do this but they're new. The WalmartLabs Electrode project looks incredibly slick and has good documentation so maybe I'll spend an hour or two with it this upcom…

From my experience this one seems like the best bet, being somewhat endorsed by Facebook. It's zero config too which is infinitely nice when you're just getting started https://github.com/facebookincubator/create-react-app.

Re: The State of JavaScript – Survey results

#232

Post by davidjnelson »

BinaryIdiot wrote: post #116
Swizec wrote: post #102

Earlier quoted context omitted.

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…

It's a good point, they are complex. But on a team doing a complex spa, you'd need someone who's a tooling expert right?

Re: The State of JavaScript – Survey results

#233

Post by morgante »

tiglionabbit wrote: post #228
morgante wrote: post #227

Earlier quoted context omitted.

> I suppose you have a class of data that is not trivial enough to store in a single component's state, but also not worth sending to the server. Exactly. For example, one application I'm working on has a complicated multi-page form/wizard. Redux is great for keeping this manageable and in fact takes care of all the management for this without me also having to write code for managing it on the backend at all.

You mean Redux, right?

Yup! Edited.

Re: The State of JavaScript – Survey results

#234

Post by sgdesign »

triangleman wrote: post #55

I wish to register my complaint with the term "ES6" which has always been unofficial and refers to the official standard "EMCAScript2015".

"EMCAScript2015" is a mouthful, and I suspect a lot of people would assume it's referring to the "old" version of JavaScript just because it's not the current year.

It might be the more "technically" correct name, but from a branding/marketing/communication point of view, ES6 is vastly superior in my opinion.

Re: The State of JavaScript – Survey results

#235

Post by sgdesign »

thisisblurry wrote: post #177
sgdesign wrote: post #27

Earlier quoted context omitted.

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.

Really sorry about that! I'll keep it in mind next time.

Re: The State of JavaScript – Survey results

#236

Post by djmashko2 »

k__ wrote: post #229
djmashko2 wrote: post #126

Earlier quoted context omitted.

(Disclaimer: I work on Apollo) Yes, it was a bit surprising to see "Apollo" separate from "GraphQL" here, since our primary focus is to enable people to take advantage of GraphQL no matter their frontend and backend architecture. It makes the most sense to make a direct comparison between "Apollo" and "Relay", but they should both be considered a subset of "GraphQL", which is really the core technology that everyone…

Do you guys know something loke Apollo but on top of RxJS? I'm not a big fan of Redux anymore since I discovered observable streams.

Apollo returns the data in observable form. You never have to deal with Redux directly if you don't want to. Check out the Angular docs for more details.

Re: The State of JavaScript – Survey results

#237

Post by davidjnelson »

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.

It's complex but it's worth learning. You can do a lot with it; transpiling, bundling, source maps, css modules, autoprefixing, concatenation, minification, etc. Along with npm scripts and a little shell scripting you can pretty much do whatever your project needs, including auto Dev deploy, ci, one touch versioned stage/prod deploys with rollback etc. And it seems to be the common base people are building the best plugins for these days. It's far less verbose than grunt or gulp, and plugins are not needed for every little thing as a wrapper. But when you need plugins, there is a great system for them, and a ton of community plugins available.

Re: The State of JavaScript – Survey results

#238

Post by morgante »

bdr wrote: post #163
morgante wrote: post #56

It's nice to see some love for Apollo here. It's leagues better than Relay and has definitely been the biggest boon to my development stack in a while. That being said, the article should make it clearer that Apollo is perfectly usable just as a frontend client—you don't have to adopt the backend at all. The Meteor team really deserves commendations for learning from some of the mistakes in building Meteor. Apollo sp…

I'm curious: how do you think about client vs server side rendering? What happens where?

For apps which need it, everything generally happens in both places. The server-side render fetches all the appropriate data and displays a fully rendered version of the page.

That being said, I think you should carefully consider whether server-side rendering is necessary for your application before adding it. It does complicate your stack and is not worth it unless either first-load performance or SEO are important to you.

Re: The State of JavaScript – Survey results

#239

Post by OhSoHumble »

tiglionabbit wrote: post #220
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…

Huh? Why should I use Ember instead of React or Polymer? Does it have a better story for cache management or something?

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 simple requirements. I just know that I ran a couple commands, changed a few configuration values, and then got going with what I wanted to do.

Ember had a low barrier to entry for me. There are a lot of community resources for how to integrate it with my back ends of choice, it has a rigorous set of conventions that are easy to cognitize, and the practices around Ember haven't changed for a long time.

Take a look at this Reddit /r/programming thread: https://www.reddit.com/r/programming/comments/55okik/how_it_...

The top two comments are about how difficult it is to determine what is an appropriate stack. A lot of programmers solve small problems that benefit from simple solutions. My anecdotal comment was that I found Ember to be a simple, stable, all-in-one solution that worked well with Ruby on Rails - which is the framework and language that best solved the problem that I was addressing.

For a React specific comment, I think Facebook recognizes this problem and it's why they rolled out their React starter CLI tool. WalmartLab's Electrode platform also looks like an admirable attempt to address the "I'm not that great at this so please configure this for me so I can just start learning and being productive" crowd.

I also really like it when a front end framework shows strong preference for and coupling with a back end framework. Vue, for example, has a strong linking to Laravel. The communities for each overlap and it's easy to get going with both. The Laravel generator, for example, sets up a Vue example so it's easier to get started even though Vue is a wholly separate project that can be used with any back end.

Re: The State of JavaScript – Survey results

#240

Post by wstrange »

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.

> "optional types" means "no types"

While it is possible to write Dart code without using types (hence "optional") - the vast majority of Dart code is written using types.

The new Dart compiler also provides a "strong mode" which enforces strong typing in order to generate cleaner Javascript code.

Post reply on HN