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

91–100 of 357 posts

Re: The State of JavaScript – Survey results

#91

Post by nekitamo »

wstrange wrote: post #79
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…

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.

Correct me if I'm wrong, but I thought that the majority of the Adwords frontend is still written in GWT?

Re: The State of JavaScript – Survey results

#92

Post by morgante »

shabda wrote: post #88
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…

What part does Graphene play (assuming you mean https://github.com/graphql-python/graphene ). Are you building graphql based apis rather than rest ones?

> Are you building graphql based apis rather than rest ones?

Yes. The Django models are exposed through a GraphQL API (using Graphene), which I query using Apollo.

Re: The State of JavaScript – Survey results

#93

Post by dntrkv »

matthewmacleod wrote: post #40
Klathmon wrote: post #25

Earlier quoted context omitted.

Could it be that you are still just new to it (in the grand scheme of things)? Because all of those things sound very similar to the complaints I hear from web developers on their first foray into desktop development. There are so many tools it's impossible to know them all (or to even know which one is best to use in which situation), so much legacy code out there it's tough to learn what the "right" way to do thing…

See, I'm not sure that's the case. When I started writing apps using Cocoa, for example, I had a pretty good experience. Yeah, I fought some of the tooling that I wasn't really used to, but given that it was quite different from my backgrounds in web and embedded development, I was overall quite pleased with how easy and more importantly how obvious everything was. I found this to be the same when I wrote application…

My experience is the opposite. I've been working on the web for over a decade now and only until a couple years ago have I really been happy with my stack.

My usual stack looks something like: Express / React / Redux / Webpack / Enzyme / CSS Modules

I do SSR / Universal JS whenever possible and it works great. The only problem on my stack nowadays is the CSS. Still haven't figured out a good flow. I currently use CSS Modules, but without dead code elimination, it just doesn't do exactly what I would like to (feed in the whole CSS library I use and let it pick and choose the classes that are used in my components, throwing the rest away)

Getting up to speed on all these tools hasn't been easy, but at this point, most of my projects are a breeze. No worrying about browser JS support. No worrying about CSS support. No more choosing between server side and client side rendering. Linting that works great and keeps the projects looking clean. Testing that doesn't make me wanna blow my brains out. Combining and minifying projects is a piece of cake. HMR + Autorefresh is like magic.

I'm really enjoying working on the web now.

Re: The State of JavaScript – Survey results

#94

Post by ng12 »

majormajor wrote: post #58
ng12 wrote: post #9

Earlier quoted context omitted.

I see this same, tired old meme in every thread about web technologies. It's funny to me that certain people are so disdainful of the churn in web development on a forum dedicated to "hackers". Web application development is hard, and the reason why there's so much churn is because smart, inventive people are constantly finding better ways to do things. Things aren't just resetting from scratch every 18 months. The w…

> The web apps I'm working on today are way more modular, composable, testable, and maintainable than the ones I was writing as little as two or three years ago. The better question is: are the apps someone with two or three fewer years of experience than you more modular, etc? My experience is on the backend rather than the frontend, but in that domain, at least, system quality is still way more about developer matu…

I think the problem was the hard-to-maintain lazy way was usually the most obvious. There was so much momentum behind the quick-and-dirty imperative DOM approach that it was hard to do anything else. For example, you could totally use Backbone to construct modular, refactorable views -- but in practice everything would devolve into DOM-munging event-driven spaghetti.

Re: The State of JavaScript – Survey results

#95

Post by joshowens »

DarkTree wrote: post #82
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.

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.

What did ES5 change to then? I never heard. Honestly, ES2015 just seems odd to me.

Re: The State of JavaScript – Survey results

#97

Post by timdorr »

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.

Totally agree. Just switched to it on Redux and this was all that was involved: https://github.com/reactjs/redux/pull/1951/files

Most of that is just find-and-replace kinds of changes. But we dropped 3 dependencies to one and sped everything up in the process. It's just a fantastic tool! I finally feel like I've got a good Rspec equivalent in the JS world.

Re: The State of JavaScript – Survey results

#98

Post by tboyd47 »

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 got swept along in the React zeitgeist. Few people who use it really take the time to understand it.

It's a pretty slow way to build a project, but that's actually not the main sell. The main sell is in smart asset chunking, and it's pretty darn good at it. That alone earned it a place in my skillset.

Re: The State of JavaScript – Survey results

#99

Post by cloverich »

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…

Yeah just to add-on to what other people are saying in replies, another happy mobx user. If I could guess at a complaint, I've worked on Ember projects (which have some similar observer / mutable capabilities) and have seen how "clever" observer / mutable-state code can turn out (overly complex). Which is to say -- it gives you some really awesome capabilities but no pre-set architecture for setting up your data modeling layer.

At any rate, I really expect this library to take-off in the next year or two, and love introducing it to people who have not heard of it (normal response: "What? Whoa"). If you already have a lot of React experience, I think their 25-line timer example is a great place to see what it can do for you: https://jsfiddle.net/mweststrate/wgbe4guu/

Re: The State of JavaScript – Survey results

#100

Post by ng12 »

mountaineer22 wrote: post #65
ng12 wrote: post #9

Earlier quoted context omitted.

I see this same, tired old meme in every thread about web technologies. It's funny to me that certain people are so disdainful of the churn in web development on a forum dedicated to "hackers". Web application development is hard, and the reason why there's so much churn is because smart, inventive people are constantly finding better ways to do things. Things aren't just resetting from scratch every 18 months. The w…

What is your current recommended or dream stack?

Currently my go-to is: React, Redux, Typescript, CSS Modules (optionally with Less) built/managed via npm and Webpack. The real beauty is that everything is well-encapsulated. If I decide one component absolutely needs to use jQuery for some reason there's nothing stopping me as long as the top-level API is still React.
Post reply on HN