Live data from Hacker News

State of the Art JavaScript in 2016

medium.com

41–50 of 306 posts

Re: State of the Art JavaScript in 2016

#41

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…

> TypeScript has has union types i.e. "number | string" which are similar to algebraic data types. I understand that you said "similar", but there's actually a big difference that should be mentioned explicitly, namely that algebraic data type (ADT) sums always have "constructors" which you can use to disambiguate with. That means that you can meaningfully do the equivalent of "int | int" whereas for union types that…

Flow has pretty good support for tagged unions like this which act like ADTs:

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

Re: State of the Art JavaScript in 2016

#42
I'm a little bit bummed that the author seems to think there's "No API solution." Nodal [1] was released in early January to a great response, and I'd hope that more people are paying attention. Our most recent announcement was that we're focusing on being API-first [2]. We also have out-of-the-box GraphQL support [3].

[1] http://nodaljs.com/

[2] https://medium.com/@keithwhor/realtime-doesn-t-belong-everyw...

[3] http://graphql.nodaljs.com/

Re: State of the Art JavaScript in 2016

#43

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…

> TypeScript has has union types i.e. "number | string" which are similar to algebraic data types. I understand that you said "similar", but there's actually a big difference that should be mentioned explicitly, namely that algebraic data type (ADT) sums always have "constructors" which you can use to disambiguate with. That means that you can meaningfully do the equivalent of "int | int" whereas for union types that…

Thanks for elaborating on the distinction. User defined type guards can get you some of the way there to distinguishing "int | int", but you don't get it for free-- the reality of being a superset of JavaScript. https://gist.github.com/RikkiGibson/74fa3dbfdb1b2d7ab86d

Re: State of the Art JavaScript in 2016

#44
post #41

Earlier quoted context omitted.

> TypeScript has has union types i.e. "number | string" which are similar to algebraic data types. I understand that you said "similar", but there's actually a big difference that should be mentioned explicitly, namely that algebraic data type (ADT) sums always have "constructors" which you can use to disambiguate with. That means that you can meaningfully do the equivalent of "int | int" whereas for union types that…

Flow has pretty good support for tagged unions like this which act like ADTs: http://flowtype.org/blog/2015/07/03/Disjoint-Unions.html

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 state exactly which bits of the state machine would propagate to $NEXT_STATE at every step... and have the compiler double-check for me that I got it right.

EDIT: I accidentally a accidentally.

Re: State of the Art JavaScript in 2016

#45
post #41

Earlier quoted context omitted.

> TypeScript has has union types i.e. "number | string" which are similar to algebraic data types. I understand that you said "similar", but there's actually a big difference that should be mentioned explicitly, namely that algebraic data type (ADT) sums always have "constructors" which you can use to disambiguate with. That means that you can meaningfully do the equivalent of "int | int" whereas for union types that…

Flow has pretty good support for tagged unions like this which act like ADTs: http://flowtype.org/blog/2015/07/03/Disjoint-Unions.html

This is great. Seems less cumbersome than TypeScript's user defined type guards for distinguishing cases of a union. The sentinel value concept is something you could at least steal when creating user defined type guards to make them simpler, at least.

Re: State of the Art JavaScript in 2016

#46
Mainly used angular and node. Someone was telling me about ember.js, I wondered why I would use broccoli over browserify. 6 months later. Was comparing browserify vs webpack. 1 month later.

Go to terminal

ember new app

ember server

start writing code.

Re: State of the Art JavaScript in 2016

#47

Earlier quoted context omitted.

> TypeScript has has union types i.e. "number | string" which are similar to algebraic data types. I understand that you said "similar", but there's actually a big difference that should be mentioned explicitly, namely that algebraic data type (ADT) sums always have "constructors" which you can use to disambiguate with. That means that you can meaningfully do the equivalent of "int | int" whereas for union types that…

Thanks for elaborating on the distinction. User defined type guards can get you some of the way there to distinguishing "int | int", but you don't get it for free-- the reality of being a superset of JavaScript. https://gist.github.com/RikkiGibson/74fa3dbfdb1b2d7ab86d

Oh, wow, that's pretty evil code! :)

Re: State of the Art JavaScript in 2016

#48
post #41

Earlier quoted context omitted.

Flow has pretty good support for tagged unions like this which act like ADTs: http://flowtype.org/blog/2015/07/03/Disjoint-Unions.html

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

Re: State of the Art JavaScript in 2016

#49

We all have our opinions and I would say take this article with a huge grain of salt (as well as my comment). State of the art javascript should still be considered a browser + editor + files. There is no need to overcomplicate things, and unfortunately Webpack and Babel do. It is terrifying to see javascript turn into the new Java - build steps and compile steps and configuration and everything you don't need except…

You're downvoted but I for one agree. KISS. If you really NEED all that stuff, fine, but it's quite clear why modern web pages are so bloated and slow on anything but current-gen hardware and fast networks.

Re: State of the Art JavaScript in 2016

#50
post #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…

Ejecta lets you use Canvas+JS without the browser – at least on iOS. http://impactjs.com/ejecta
Post reply on HN