Earlier quoted context omitted.
That's interesting! I haven't paid much attention to Flow since trying out the initial release and finding it a bit lacking. (But then, I'm used to GHC/Haskell, so everything lacking!) I truly feel that "disjoint unions" is one of those things you don't appreciate the true value of until you've used them for quite a while. The real eye-opener for me was implementing a state machine and finding that I could explicitly…
It's gotten a lot better since the initial release. Obviously no match for GHC but it's not trying to be, either. :)
State of the Art JavaScript in 2016
51–60 of 306 posts
Re: State of the Art JavaScript in 2016
#52Earlier quoted context omitted.
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
#53This 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…
Moving data between components in Polymer, can be done with data binding. The bad thing is that it could get messy for complex applications. Is not terribly bad, but it could be better. What Polymer needs is a better way to move data between components. If that problem is solved, Polymer would be an excellent alternative to create any kind of apps.
Re: State of the Art JavaScript in 2016
#54PS Ramda it eats lo-dash and its imperative API for lunch. It's for power users, everything curried, higher levels of abstractions. Pick it up and learn it, it'll make you a better programmer.
Next stop Clojurescript. Om next is a library where you can get a feel for a Falcor + Relay stack in like 70 lines of code all without the specific tech bloat. David Nolen is a UI profit, just follow him.
Re: State of the Art JavaScript in 2016
#55Re: State of the Art JavaScript in 2016
#56Why is eslint considered better than jshint+jscs? jscs also supports auto-fixing, which is pretty dope.
Re: State of the Art JavaScript in 2016
#57I 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…
First, to say that "Types are not nearly as critical to front end development as some will have you believe" misses the point of types. Every programming language has types, even dynamically typed languages. As a programmer, embracing that types underly the code's meaning affords much more power to write clean, correct, and elegant code. This argument stands regardless of the type of programming; types underly code.
On the other hand, there's his remark, "TypeScript tries too hard to make JavaScript like C# or Java." (You claim that this is an unfair complaint against TypeScript. Would you care to elaborate what you think TypeScript's purpose is?) Personally, I feel similarly when working in TypeScript. Sure, the compiler can catch a few things, and it's certainly a step above only runtime type checks, but the type system itself is fundamentally flawed.
The type systems of Java and TypeScript are actually quite similar, so I'm going to refer to them both here. Neither language has a really good idea of what a sum or union type looks like. Consider doing math, but you can only multiply. Sure, it's possible to hack around some things so that you get the same results, you're doing a huge song-and-dance just to say that what you really want is this plus that.
Type systems like those present in Java or TypeScript (or, as it turns out, most mainstream languages) that lack unions end up leaving this weird aftertaste.
So my takeaway here is that we can do better. Certainly writing Java or TypeScript eliminates classes of bugs that Python or JavaScript are susceptible to, but let's keep pushing. We owe it to ourselves to strive for much better more expressivity in our type systems.
I'll use TypeScript over JavaScript for now, but I'm always keeping an eye out for technologies that raise the bar.
Re: State of the Art JavaScript in 2016
#58The 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…
The obvious next question is: what patents are necessarily infringed in the first place, just because you used React? It's a useful tool, but even if Facebook have successfully acquired relevant US software patents, it's hard to believe there's anything significant in there that had no prior art. GUI programmers have been specifying presentation details declaratively, using templates, and bundling updates for performance since long before the existence of React (or Facebook, for that matter).
Re: State of the Art JavaScript in 2016
#59Re: State of the Art JavaScript in 2016
#60> I like to keep it simple and just use fetch. It’s promise based, it’s built in Firefox and Chrome, and it Just Works (tm). For other browsers, you’ll need to include a polyfill.
I laughed. Is this satire? There's no reason to have X, therefore you need Y and Z to replace X. It just works.