1. 14
  1.  

  2. 5

    I disagree with the articles opinion on Typescript. I think even if you stick to ES6 features Typescript is a great consideration over Babel as it gives you better tooling.

    Also, its clear the author is a React Fan. I would not discount Angular 2 as a consideration either.

    1. 2

      State of the Art or Flavor of the Month? It still seems like the JS/front end world isn’t close to settling down.

      1. 2

        This article seems to put forth as settled a number of issues that are still being hotly debated. This is not to say that the options they suggest aren’t usable (really, you can make wonderful things with them), but that the problem is not as cut and dried as it is made out to be here.

        In particular, I think Ember.js is a strong option that has done a lot of work to bring in the best ideas and features from other frameworks. This includes a number of changes inspired by React.

        The Ember team also takes versioning really seriously. In fact, the transition from 1.13 to 2.0 did nothing but remove deprecated features. No new additions at all! This means that if your code ran on 1.13 without warnings, it runs in 2.0.

        The biggest advantage it offers is that it is a unified system. You don’t have to worry about picking from a bunch of different frameworks for every portion of your application, you can just use what Ember provides (all interaction handled with a single CLI), and everything should just work. This is, I think, an appealing option, particularly given the overabundance of choice in the JavaScript ecosystem.

        All of this isn’t to say that Ember is the greatest, most perfect framework in existence, or to suggest that everyone should use it and only it. The point is that there is a lot of good work being done in the world of JavaScript, and the decision of what to use is not so easy as this article makes it out to be.

        In the end, it may be that the JavaScript community coalesces around popular stacks, similar to Steve Klabnik’s “two default stacks” for Rails. This would, I think, go a long way to taming the complexity zoo of the ecosystem as it stands today.

        1. 1

          Testing: Mocha + Chai + Sinon (but it’s not that simple)

          Ava is a possibility if you’re willing to ride towards 1.0 for running in a browser.

          enzyme is cool too.

          Just use fetch!

          Fetch’s api is nice, but it’s still based in promises which leads to some situations like cancelling requests being hard or impossible so it’s good to be aware if you need such things.

          Styling … One drawback: css-loader with CSS modules enabled is REALLY slow

          It seems like there are a high percentage of people using sass speaking up about this. Would be interesting to see a sass vs postcss comparison (and raw css, etc).

          PostCSS and CSSModules are definitely the way to go these days. Might even solve the author’s “reference imports” issue (CSSModules values)

          Universal (Isomorphic) JavaScript: Make sure you need it.

          I’d lean on the side of make sure you don’t need it if you choose to not use it. I have some significant experience in the area though, so my opinion could be biased. These days with React-Router, etc it’s much easier to get up and running. That said I’ve met quite a few people who feel like it’s still as difficult as it was N years ago because they haven’t looked into it recently.

          The API: There’s still no true answer.

          REST doesn’t really live up to it’s promise IMO. GraphQL far exceeds REST in introspective ability, etc. Still for early adopters though. Setting up the GraphQL endpoint isn’t comparatively harder than picking up any other new tool.

          1. 0

            Great article, really helped me pick out the best of JS right now.