Live data from Hacker News

State of the Art JavaScript in 2016

medium.com

51–60 of 306 posts

Re: State of the Art JavaScript in 2016

#51
post #48

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. :)

Understood :).

Re: State of the Art JavaScript in 2016

#52
post #33
post #19

Earlier 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

TS has string types starting from 1.8, although they can't be used for narrowing down the type yet in the way that Flow can.

http://bit.ly/1LhA5id

Re: State of the Art JavaScript in 2016

#53
post #18

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

Polymer (https://www.polymer-project.org) is a solution for the styles problem. You can pack each component with its own styles, complete with all its functionality. This allows for a very clean separation of concerns among components. Better than all other libraries that I have tried. I hope that web components take off, because it is a great way to build apps. Currently they are only supported in Chrome.

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

#54
At work we've turned an ember-cli ember app into a react redux app in place using immutable.js and ramda for everything. It's been a huge boon.

PS 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

#55
In a development world that is already rife with planned obsolescence, the Javascript world is the shining jewel. Reminds me of trying to construct the killer Yu Gi Oh deck. By the time you get all the cool cards, paying a small fortune for them of course, a new ban list comes out, new decks come out, and you have to start all over again. Is the game improved through all of this? Maybe it is, maybe it isn't, but I would say that this question becomes beside the point for many players...

Re: State of the Art JavaScript in 2016

#57
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…

The author seems a bit conflicted on whether he likes or dislikes types.

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

#58

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…

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.

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

#59
Ember barely gets mentioned and includes each "piece of modern web applications" OUT OF THE BOX with a great support community. I love not making all of those decisions and doing all the integration BS work. Ember feels like the worst kept secret.

Re: State of the Art JavaScript in 2016

#60
> Unless you’re working on a legacy application or have 3rd party libraries that depend on it, there’s no reason to include it. That means you need to replace $.ajax.

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

Post reply on HN