No mention of SystemJS/JSPM?
I found a mention in the comment section (I believe by the author of the article), which said it didn't work all that well for them.
State of the Art JavaScript in 2016
11–20 of 306 posts
Re: State of the Art JavaScript in 2016
#12I find lots of modules that won't build with Webpack and a very solid chunk of my available development time is spent trying to diagnose and fix problems caused by modules that won't build under Webpack. I recommend against it.
I've never run across this, or indeed, heard of anyone have experienced this before. More details? I'm honestly curious.
It happens all the time because most UMD implementations are broken and make incorrect assumptions, so you often have to follow the "Fix broken modules" steps on https://webpack.github.io/docs/shimming-modules.html
And if your package depends on a broken module, you're essentially SoL unless you make assumptions about the path NPM will install stuff and configure webpack to fix -that- one.
That's more a problem with the state of broken UMD modules than Webpack itself though, but I've considered configuring webpack to ignore all AMD syntax quite a few times...
Re: State of the Art JavaScript in 2016
#13Earlier quoted context omitted.
I've never run across this, or indeed, heard of anyone have experienced this before. More details? I'm honestly curious.
It happens all the time because most UMD implementations are broken and make incorrect assumptions, so you often have to follow the "Fix broken modules" steps on https://webpack.github.io/docs/shimming-modules.html And if your package depends on a broken module, you're essentially SoL unless you make assumptions about the path NPM will install stuff and configure webpack to fix -that- one. That's more a problem with…
Yeah the line of thinking seems to be that everything else is broken, not webpack. And the module maintainers say "well it works with everything else except Webpack so webpack is broken, they should fix it." Seriously crap situation.
Re: State of the Art JavaScript in 2016
#14I use all those tools daily, but this article feel patronising to me, I would feel inconfortable to say that whatever I use is the state of the art. Also the author is totally ignorant and bigoted about typescript.
Re: State of the Art JavaScript in 2016
#15I agree with 90% of this. React, Redux, ESLint with airbnb config, npm, webpack, lodash, ramda, fetch, css modules...absolutely.
I disagree with the breezy assertion that types don't matter, and the offhand dismisal of TypeScript. And saying that "TypeScript tries too hard to make JavaScript like C# or Java" reveals, in my view, a fundamental failure to understand what TypeScript does.
I also think the author is a bit too strongly in favour of `mocha`; I don't think `ava` should have been some easily dismissed, and I've recently run across a pretty nice framework called `painless`. And even if you do use `mocha`, I find `expect` to be a better assertion library than `chai`. I think a better answer here might be "use whatever works for you, so long as its not Jest". (The shoutout to `enzyme` was on point though; great library if you need to test React components.)
Re: State of the Art JavaScript in 2016
#16I strongly disagree about TypeScript-- I think it's a huge boon to productivity. TypeScript has has union types i.e. "number | string" which are similar to algebraic data types. TypeScript also has optional interface members and function parameters by putting ? at the end of the name, i.e. "foo?: number". Static types allow for much, much better tooling, particularly autocomplete and the ability to check whether your…
Thanks for posting your thoughts. I was leaning towards TypeScript myself (as opposed to ES6) for an Angular project that will be migrated to version 2.0. Angular 2 was actually written in TypeScript if I am not mistaken, and it's one of the three say, "supported" ways of writing A2 apps (along with ES5 and Dart).
Re: State of the Art JavaScript in 2016
#17The problem with React is its patent rider. React.js comes with a BSD license, but has a patent rider that gives you a license to React's patents. This sounds like a good thing, right? But this rider has a "strong retaliation clause" which says that if you make any sort of patent claim against Facebook this patent license automatically terminates. Which means Facebook can now sue you for patent infringement for using React. You may think this is no worse than not having a patent rider at all. But that's not the case. If there is no patent rider then there is an implicit grant which cannot be revoked.
If you work for a software company and your company has patents then keep in mind that by using React you are giving Facebook a free license to your entire patent portfolio.
More info on weak vs strong retaliation clauses: http://www.rosenlaw.com/lj9.htm
Re: State of the Art JavaScript in 2016
#18This article echoes my experience this year and last, moving from a Backbone app into React + Fluxxor, and eventually into ES6 with Babel + Flow + Webpack.
It's a huge pain to configure and understand all this tooling, but man is it nice once it's all working. It definitely gives me hope for the web as an application platform.
Re: Flow, it's good but nowhere near as developed as TypeScript, but it's getting better. 0.22 of Flow (released just a week ago) brought massive speed improvements that bring it decently on par with any other linter. I found I could finally re-enable it in Sublime Text after this release. It catches all kinds of things linters won't, and the upstart cost is relatively low. On the other hand, TS has the benefit of years of type files available for almost any library; don't underestimate how great that is.
Using React has been great as well. It's what I wish Backbone views had been from the beginning.
We certainly aren't wanting for choice. Between the dozens of Flux implementations, React alternatives like Mithril, interesting languages like ClojureScript (with Om if you want to keep using React) or Elm, multiple typing systems, and even WASM on the horizon - web development is an exciting field. It's also overwhelming, and I say that as someone who keeps his head in it over 12 hours a day.
---
Re: CSS, the story still feels incomplete. I want a way to write a library that will effortlessly import its own styles, so consumers can simply import the component and go to town. Most solutions are severely limited, slow, or both, mostly because they rely on inline styles. Nothing's wrong with inline styles, until you want to do :hover, :active, pseudo elements or the like.
See the React material-ui project for a very real example of how this can go wrong - note how every component has a dozen or more extension points for styles. I built a project with this recently and it was intensely frustrating that I couldn't simply add some CSS to the app to fix styles across the board - I needed to keep a giant file of extensions and be sure to apply them every time I used a component. And, of course, component authors can't possibly anticipate every possible use, so some of my selectors were ugly "div > div > ul > li:first-child" monstrosities.
CSJS (https://github.com/rtsao/csjs) is one of the few solutions I like. I would be very happy to see it, or something like it, go mainstream.
Re: State of the Art JavaScript in 2016
#19I strongly disagree about TypeScript-- I think it's a huge boon to productivity. TypeScript has has union types i.e. "number | string" which are similar to algebraic data types. TypeScript also has optional interface members and function parameters by putting ? at the end of the name, i.e. "foo?: number". Static types allow for much, much better tooling, particularly autocomplete and the ability to check whether your…
Agree.
Typescript doesn't have real algebraic data types becauses at the end of the day, Typescript is just a statically-typed version of Javascript. And Javascript doesn't have adts.
For me, the biggest advantage of static typing is that code is much more self-documenting. Also, refactoring becomes much easier.
Re: State of the Art JavaScript in 2016
#20I strongly disagree about TypeScript-- I think it's a huge boon to productivity. TypeScript has has union types i.e. "number | string" which are similar to algebraic data types. TypeScript also has optional interface members and function parameters by putting ? at the end of the name, i.e. "foo?: number". Static types allow for much, much better tooling, particularly autocomplete and the ability to check whether your…
Strongly agree. Surprised the author felt this way...