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

331–340 of 357 posts

Re: The State of JavaScript – Survey results

#331

Post by Roboprog »

SiVal wrote: post #310
foo101 wrote: post #298

Earlier quoted context omitted.

Thanks for the answer. I was not doubting the survey methodology or results. My question was simply out of curiosity. I would like to request more details on your answer. 1. What kind of ES6 requires transpiling to ES5. I mean, I once tried using Promise and something like Promise.resolve("foo") works just fine. Are there any ES6 constructs that would require transpiling, to work fine on, say, Chrome or Firefox? 2. I…

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, so it's academic :-(

Re: The State of JavaScript – Survey results

#332

Post by Roboprog »

labrador wrote: post #70

I would respect the JavaScript so much more if there wasn't so much faddishness - somehow JS devs have decided switch statements are bad, indenting with 2 spaces is the only way to go, semi-colons should be banished and "boilerplate" code should be hidden in libraries the magically wipe it away so your code looks "clean," if barely understandable without reading through a bunch of libs. Edit: forgot to add that these…

C and its descendants does have a somewhat "broken" case statement. Pascal's was much less error prone.

Putting in semicolons won't make the language NOT terminate a statement if you split a line in the wrong spot. (I suppose one solution would be just to put everything on one giant line, and separate the statements with semis, but, YUCK)

Repetitive boilerplate should indeed be pushed down a level or two in any language, so the top of your program reads in terms of the business logic / problem space, not a bunch of code management noise. This is less traumatic if your functions have actual documentation for an IDE to display when a symbol is clicked on, rather than buying into the "self documenting" fairy tale.

However, 2 spaces per level isn't visually very much. I don't need to nest things so deeply that I begrudge a few spaces per level.

- - - -

Static OOP was the shizzle back in the 80s (when we were learning about clones, often bad clones, of Simula 67). The last 10 years or so, though, I have really started to appreciate much (if not all) of what Lisp offered back in the day. Javascript is an acceptable Lisp.

Re: The State of JavaScript – Survey results

#333

Post by Roboprog »

BinaryIdiot wrote: post #83
labrador wrote: post #70

I would respect the JavaScript so much more if there wasn't so much faddishness - somehow JS devs have decided switch statements are bad, indenting with 2 spaces is the only way to go, semi-colons should be banished and "boilerplate" code should be hidden in libraries the magically wipe it away so your code looks "clean," if barely understandable without reading through a bunch of libs. Edit: forgot to add that these…

> somehow JS devs have decided switch statements are bad Nonsense. Though sometimes using an object can look cleaner depending on your use case. > indenting with 2 spaces is the only way to go I love 4 spaces and I use 4 in my JavaScript projects. Just because you've seen some subset of people use 2 doesn't mean it's the majority, what you have to use, etc. > semi-colons should be banished Absolutely, positively NO.…

I think the semicolon requirement is more for broken minifiers than actually making the unpacked code clear/correct. But that's just me, I guess, as I have worked with many line oriented languages, and have no reverence for C syntax.

Re: The State of JavaScript – Survey results

#334

Post by k__ »

djmashko2 wrote: post #290
k__ wrote: post #243

Earlier quoted context omitted.

It's also written in TypeScript, nice! A few days ago I was thinking about using GraphQL in future projects and didn't even find out about Apollo. So it combines data retrieval via GraphQL with client side state management via Redux?

That's exactly right. We're working on refactoring it as well so that it can be used outside of Redux, here is one of the resulting projects: https://github.com/apollostack/graphql-anywhere

you just stole my heart :)

Re: The State of JavaScript – Survey results

#335

Post by spion »

aidos wrote: post #224
spion wrote: post #210

Earlier quoted context omitted.

The right way to get rid of mutable state is to replace it with a stream abstraction, which declaratively models how the state changes in response to events. That would be cyclejs: http://cycle.js.org/ Too bad that this model doesn't work well with React. React models the UI as a (mostly pure) function from props/state input to DOM output, however in reality the UI is a stream containing both DOM states and input eve…

Why do you say that's the right way? Is there something intrinsically better about having the state modelled as a stream of changes? Is that really getting rid of mutable state? [EventA, EventB] is a mutation of [EventA], sure it's a WAL style, but the combined final state is a mutated version of the original state. Presumably the concrete state model (like MobX) is a realisation of the event stream at a moment in ti…

I'm saying its the right way to get rid of it, not that its right to get rid of it :)

MobX does really, really well in minimising the complexity of mutable state. Its the best there is out there.

Where MobX does worse is when there is more complexity then a simple direct map function to calculate derivations: debouncing key input, doing async requests, creating animated transitions, etc. Its a great model, but it needs some more work to be truly amazing.

The user does care about the past. For example if the state of the input box changed too many times during the last second, they don't want every change to cause a slowdown in response time due to too many requests being sent to the server, and they want only results from the last request they sent, not the last one that was processed.

I think the reverse criticism applies for cyclejs: while it can do everything thanks to RxJS, it needs a better component composition model. The current one is too tedious and alien for my taste. (For example, why isn't the same DOM selector syntax used for component-event selection?)

Re: The State of JavaScript – Survey results

#336

Post by saosebastiao »

DonHopkins wrote: post #321
somlor wrote: post #306

Earlier quoted context omitted.

I think I see where you're coming from, but I also think you might be moving the target a bit. I suspect you'd garner less debate if you said, I dunno, just "a dynamic UI app needs a way to model state changes ". "Mutate" has a specific meaning, in my mind at least, when discussing variables and data structures. React enables avoidance of direct DOM manipulation, Redux obviates direct state mutation.

Also, "finite state machine" has a very specific meaning, and that isn't just any machine that has a finite bunch of variables that you call state. If React lets you execute arbitrary JavaScript code (which it does), then you're no longer using just a finite state machine, you're using a Turing machine, which is something different, and more powerful. It may have many finite state machines embedded in it, but to refe…

React, as it is presented to the programmer and for all practical reasoning, is programming with finite state machines. Sure, javascript is Turing complete and capable of much more (behind the scenes in React there is plenty going on that does not qualify as FSMs), and within a react application or even a component you might use Turing complete semantics to describe actions, data structures, effects, or whatever...but constrained to the API and idioms of react it is perfectly acceptable to call it FSM programming. In fact, Facebook already says this about react, that UIs are state machines and react is a way to declaratively describe them that way.

A better analogy for the equivalence of Finite State Machines and User Interfaces is the equivalence of human arms and levers. Just because it is one doesn't mean it isn't the other. One is abstract and the other is concrete, but there is still an equivalence. And not just computer user interfaces either...you could take pretty much any real world user interface: analog, mechanical, digital, whatever. Hell, tubas and vending machines are finite state machines. They fit the definition of a finite state machine because they are.

Re: The State of JavaScript – Survey results

#337

Post by shados »

z3t4 wrote: post #122
ng12 wrote: post #94

Earlier quoted context omitted.

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.

I think one reason why React is so popular is that it forced you into an object oriented approach whereas before many developers used innerHTML everywhere. It is possible to write object oriented, structured "class" based vanilla JavaScript with imperative DOM manipulations though, witch is more performant then popular frameworks.

"I think one reason why React is so popular is that it forced you into an object oriented approach"

And yet React's claim to fame is that it popularized techniques other than OOP, which was plaguing the JS world up until recently.

Re: The State of JavaScript – Survey results

#338

Post by triangleman »

austincheney wrote: post #107
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".

ES6 refers to ECMAScript version 6, which was the official name of the latest version up until around December 2014. I believe ECMAScript 2015 was coined by Dominic Denicola to put additional pressure on TC39 to publish that year.

You are right, ES6 has a lot more traction than I thought. The reason I posted that was because I had a lot of trouble understanding what ES6 was referring to when I first started researching it, and it seemed like an amorphous standard with varying features depending on who you ask. But no, it's an actual standard published as "version 6".

Incidentally I misspelled "ECMA" in my original comment, so now it's easier to see why it won't catch on anytime soon.

Re: The State of JavaScript – Survey results

#339

Post by pauljaworski »

ggregoire wrote: post #194
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.

The survey should separate unit testing and e2e testing. I don't know what the general feeling about e2e testing in the JS community, but in my last job we had to write, fix and maintain hundreds of e2e tests and it was a nightmare. Our stack was Angular 1 and the de facto Angular e2e tool, Protractor. We wrote tons of helpers, like waitToBeVisible & waitToBeHidden, most of them copy/pasted from StackOverflow because…

Yeah, I've been putting off e2e testing while I pray for a decent tool to come out before I really need it.

I think the benefits come when you're really making use of reusable components. I have about 20 views that all make use of the same Redux container component, and e2e tests would definitely help me sleep better at night.

Re: The State of JavaScript – Survey results

#340

Post by nine_k »

aidos wrote: post #324
nine_k wrote: post #288

Earlier quoted context omitted.

Mutable state is fundamentally harder to reason about. You get aliasing bugs, stale cached values, etc. With immutable data in an append-only stream this is simply impossible.

I've done plenty of work with immutable data, and I tend to code in a way that minimizes the amount of state I have to manage. I guess that's what I was saying about mobx though - I can have a much smaller set of core data and then pure functions for the layers of derived data. And it's a) easy to reason about and b) super performant at managing the calculations. Aliasing bugs don't really apply in JS, unless there's…

Saying about "aliasing bug" I meant something like this:

    var my_data = {"foo": null}

    function innocuous(input) {
      var data = {"one": input, "two": something()};
      data.input.foo = data.input.foo || "foo"  // set a default value
      // do something with data
    }

    var result = innocuous(my_data)

    // Oops, now my_data.foo has changed.
Post reply on HN