Live data from Hacker News

The State of JavaScript – Survey results

stateofjs.com

341–350 of 357 posts

Re: The State of JavaScript – Survey results

#341
post #310

Earlier quoted context omitted.

Here's a little bit for you. Most people prefer the semantics of `let` to `var` for variable declarations in JavaScript. It's how JavaScript should have been designed from the start. It has been officially standard for a year or two and became available in some browsers even earlier. I want to use `let` (and `const`) for everything and never use `var` again, but I couldn't even do that on my own PRIVATE website (for…

I get "const", but is "let" really that big a deal? Are your functions so deeply nested that you need block scope inside of if statements and for loops? (vs forEach callbacks or IIFE blocks or simply splitting complicated stuff into smaller functions) There is some cool stuff in ES6, but "let" is kind of a yawn, and "class" most definitely is NOT something I really needed. But I'm still running ES5 on IE11 at work, s…

Sometimes you just need to do something the old way:

  let element = document.getElementById('some-element');
  while (element) {
    // do something
    element = element.parentElement;
  }
let doesn't get in the way with behavior such as hoisting, and the code will break if you redeclare a variable.

Re: The State of JavaScript – Survey results

#342

Earlier quoted context omitted.

I love the promise of Ember too. But if you look at the stats, along with Angular & Backbone it has pretty terrible satisfaction ratings. And in my personal experience, it also has some of the worst word of mouth of any JS frameworks. Which I believe is the reason why so many people haven't tried it yet. Most former Ember devs I know have moved onto React. When I mention Ember to them, I often get the response "you'r…

Awh, I'm pretty sad to hear that from an experienced Ember dev. I've heard some pretty bad things about Angular and I've seen some horrible Angular codebases. It's entirely possible that I'm looking at Ember through the eyes of a Rails developer who wants a better front end experience. There is a good chance that I'll run into Ember's warts later on but just how easy it was to get started made me so happy. If I do co…

Rails dev who likes Ember, here. Well, maybe "likes" is too strong a word. Prefers, maybe?

Basically, you're right on the money. I like Ember CLI because it's the closest thing to replicating the ease of Rails development in the Javascript world that I've seen thus far. I'm keeping a keen eye on Angular CLI, but it's not ready for primetime yet.

Re: The State of JavaScript – Survey results

#343

Earlier quoted context omitted.

>"everything that happens in your Ember app is deeply tangled in Ember internals which are very complex." and >"it's fundamentally at odds with what I would consider the Node Ethos, which is small packages that do one thing cleanly." You could substitute "Ember" with "Microsoft Windows" and "Node" with "UNIX" and be just as correct. I wonder how frequently this design/philosophy decision comes up.

I hear very distinct echos of Rich Hickey's talk, Simple Made Easy. In that talk, "easy" is defined as being nearby, familiar, or otherwise "at hand" to the person who is involved. This is different than "simple", which is presented as an orthogonal concept meaning roughly "one operation" not tangled or interleaved with neighboring concepts. This is a clear and useful way to think about simplicity in software (1). I…

> When we talk about a product being simple, what we usually mean is that it integrates (folds together) many complex dimensions such as ergonomics, manufacturing, aesthetics, cultural signs, etc. into a single solution.

I would argue that in order for that to happen, the design and internals of the product need to follow principles of simplicity and separation of concerns. You can't just wrap a pretty layer around a snarl of insanity and get a usable product.

For example, a common design mistake is to use several visual indicators for one piece of information: this warning text is bold, a different color, and placed inside a box. Once you've done that, you have used up three visual "slots" that can't be used as effectively for other information.

Great design like you describe requires thinking about single uses for single mechanics. It requires thinking about how things fit together while remaining functionally distinct, rather than just adding more and more complexity to solve problems that come up.

Re: The State of JavaScript – Survey results

#344

Earlier quoted context omitted.

> But on a team doing a complex spa, you'd need someone who's a tooling expert right? I would argue no. Granted not everyone needs to be an expert on the tool chain and this ends up happening probably a majority of the time anyway but if most are ignorant how the tool chain works I don't think that's a good position to be in either. When a bug / misconfiguration issue rears its ugly head you need more than a few peop…

I agree with what you're saying. You don't want to get stuck in a corner. That's smart and pragmatic. Perhaps an expert that mentors the rest of the team? I just don't see how we can do without software build tools. They are so common in almost every language/platform I've used.

> I just don't see how we can do without software build tools. They are so common in almost every language/platform I've used.

All depends on your use case. Honestly if you're working on a web app you actually don't need any build tools if you really didn't want to.

But ultimately I wasn't advocating for zero build tools. The way JavaScript works you can write your own scripts (I wrote my own, barely one page of code for minifying, packing, versioning, testing, etc) or use any of the systems if you want to. It's all not that hard. But I don't think only one (or small handful) of people should know how to use them and I think we can vastly simplify what some of them do today (looking at you, babel and webpack).

Re: The State of JavaScript – Survey results

#345
When I finally ended on the IDE page, I realized how the vast majority of these "5-10"+ year veterans were very primitive developers. If you're using Sublime or Atom for Javascript development, I would say that you've spent too long working in and around these ever-changing tools without a useful IDE.

Re: The State of JavaScript – Survey results

#346
post #345

When I finally ended on the IDE page, I realized how the vast majority of these "5-10"+ year veterans were very primitive developers. If you're using Sublime or Atom for Javascript development, I would say that you've spent too long working in and around these ever-changing tools without a useful IDE.

I'm happy coding in WordPad, GEdit, etc, and use Sublime today.

My view is that if you need an IDE to maintain your code effectively; if your volume of edits is such that macros and navigation tricks make a meaningful impact on your pace of development, then your code probably has serious architectural problems¹.

You see all impediments to action as debilitating, but I think impediments, carefully curated, can provide useful constraints on my development process. Friction helps me see where my interfaces are getting strained.

¹ I feel bad writing this because I know, if I step back from my own preferences, that your approach to development probably works great too. But your claim was so insulting, I'll leave this as is to match your tenor.

Re: The State of JavaScript – Survey results

#347

Earlier quoted context omitted.

I get "const", but is "let" really that big a deal? Are your functions so deeply nested that you need block scope inside of if statements and for loops? (vs forEach callbacks or IIFE blocks or simply splitting complicated stuff into smaller functions) There is some cool stuff in ES6, but "let" is kind of a yawn, and "class" most definitely is NOT something I really needed. But I'm still running ES5 on IE11 at work, s…

Sometimes you just need to do something the old way: let element = document.getElementById('some-element'); while (element) { // do something element = element.parentElement; } let doesn't get in the way with behavior such as hoisting, and the code will break if you redeclare a variable.

How does var/hoisting get in the way of that, or at least, that particular, construct?

FWIW, that would also be a nice "for" loop :-)

    var el
    for (
        el = document.getElement... ;
        el ;
        el = el.parentElement
    ) {
        // do something
    }

Re: The State of JavaScript – Survey results

#348

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…

Have you tried riot? Or mithril? Small and simple.

Regarding react I don't think there is anything in react itself that says that you have to use es6 and an advanced module bundler (like webpack). Just use es5 code, place everything in one file or just concatenate the files before using them in the browser and everything should work. You mainly loses out on how easy it will be to copy from tutorials that are written for es6 code with modules, and that some 3rd party things are written as modules.

Re: The State of JavaScript – Survey results

#349

Earlier quoted context omitted.

I agree with what you're saying. You don't want to get stuck in a corner. That's smart and pragmatic. Perhaps an expert that mentors the rest of the team? I just don't see how we can do without software build tools. They are so common in almost every language/platform I've used.

> I just don't see how we can do without software build tools. They are so common in almost every language/platform I've used. All depends on your use case. Honestly if you're working on a web app you actually don't need any build tools if you really didn't want to. But ultimately I wasn't advocating for zero build tools. The way JavaScript works you can write your own scripts (I wrote my own, barely one page of code…

Ya that's true. I'd just really hate to ever see another 10,000 line jquery monstrosity ever again shudder lol.

Re: The State of JavaScript – Survey results

#350

Earlier quoted context omitted.

I agree with what you're saying. You don't want to get stuck in a corner. That's smart and pragmatic. Perhaps an expert that mentors the rest of the team? I just don't see how we can do without software build tools. They are so common in almost every language/platform I've used.

> I just don't see how we can do without software build tools. They are so common in almost every language/platform I've used. All depends on your use case. Honestly if you're working on a web app you actually don't need any build tools if you really didn't want to. But ultimately I wasn't advocating for zero build tools. The way JavaScript works you can write your own scripts (I wrote my own, barely one page of code…

I agree with you that writing build scripts and using build tools both are not very hard. Who finds them hard? I'm sure Babel and webpack could be improved. What would you propose for how to improve them? Thanks.
Post reply on HN