Live data from Hacker News

State of the Art JavaScript in 2016

medium.com

31–40 of 306 posts

Re: State of the Art JavaScript in 2016

#31
post #15

I 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 bi…

Although the article covers a lot of things and provides some arguments (credit where it's due), the fashion in which the choices are made suffers from a kind of tunnel-vision favoritism. Claims like, "Everyone should use React. Period. Now!" just make me question the merits of its proponents. The JavaScript community is really infamous for this...

Re: State of the Art JavaScript in 2016

#32
I'm making web apps/clients in the browser, servers using node.js and desktop "native" apps using nw.js. All in vanilla JavaScript, and I love it. If you need additional functionality, there's always a module for it (npmjs.com)

The interesting part is maybe that most apps look like this:

  
And the rest is JavaScript!

It does seem a bit stupid to load the browser just for the canvas element though, so if someone know a better solution, please post!

Re: State of the Art JavaScript in 2016

#33
post #19

I 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.

For comparison, Flow supports tagged unions like this:

http://flowtype.org/blog/2015/07/03/Disjoint-Unions.html

Re: State of the Art JavaScript in 2016

#34
post #30
post #2

I 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.

If you mean old jQuery plugins or libraries that aren't CommonJS compatable, Webpack even has your back on that via its various plugins. I was able to take an extremely large node-incompatible app and "webpackify" it through the tooling in a way that would have been impossible any other way. Highly disagree.

I'm trying to program an application, not Webpack. If there are plugins that solve some problems then why aren't they part of the default config of webpack?

I'm not programming for the fun of programming build tools, I just want the damn thing to work. Zero interest in working out how to make webpack work. This is the problem with javascript build tools - they think I care enbough to want to work out how to configure them. I just want the module that I need to function.

Re: State of the Art JavaScript in 2016

#35
post #28

The 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…

if you make any sort of patent claim against Facebook My understanding (and I'm asking for correction, if I'm wrong) is that last year FB changed this provision to only cover patents on technologies within React itself, not "any sort of patent claim against Facebook", which WAS the situation before they changed it. So, the current state is a grant of "you are licensed to use our React patents at no cost as long as yo…

Not exactly. The diff is here: https://github.com/facebook/react/commit/b8ba8c83f318b84e429...

The old grant terminated if, among other things, you argued that any Facebook patent was invalid or unenforcable. This meant that if Facebook sued you over an unrelated patent, you couldn't defend yourself without the React patent grant terminating.

The new grant specifically exempts any counterclaims; you can't lose your patent grant just because you defend yourself. You can still lose it if you sue Facebook over unrelated patents.

Re: State of the Art JavaScript in 2016

#36
post #28

The 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…

if you make any sort of patent claim against Facebook My understanding (and I'm asking for correction, if I'm wrong) is that last year FB changed this provision to only cover patents on technologies within React itself, not "any sort of patent claim against Facebook", which WAS the situation before they changed it. So, the current state is a grant of "you are licensed to use our React patents at no cost as long as yo…

No, that's incorrect. It is any patent assertion against Facebook. Read it for yourself: https://github.com/facebook/react/blob/master/PATENTS
Post reply on HN