Live data from Hacker News

State of the Art JavaScript in 2016

medium.com

211–220 of 306 posts

Re: State of the Art JavaScript in 2016

#211

Disappointing that after months of moaning about the paralysis of choice, few of the comments are positive about a genuine and fairly defensible attempt to cut through that. He proposes a fairly simple stack (and for the sake of argument he assumes you're needs are beyond the 'static html and a touch of jQuery' stage). He spends time explaining them and makes a fairly good attempt to avoid the overly-new or overly-co…

"HN comments needs an on-topic vs off-topic filter. Or a "yes we already know that" filter..." They already do; if something doesn't positively contribute to the discussion, downvote it.

I wasn't entirely serious about the filters but that's a fair point.

I suppose what I'm actually saying is "Can we all downvote the more worn-out type of comments a bit more actively?".

Which now I'm come out and said it sounds overly optimistic. ;-)

Re: State of the Art JavaScript in 2016

#212
post #209

> Avoid CoffeeScript. Most of its better features are now in ES6, a standard. This argument against CoffeeScript isn't very objective. One of CoffeeScript's best features is the minimalistic and expressive syntax. "CoffeeScript (#6) appears dramatically more expressive than JavaScript (#51), in fact among the best of all languages."[1] "CoffeeScript is #1 for consistency, with an IQR spread of only 23 LOC/commit comp…

I'm using LiveScript for private stuff and ES6/JSX in production. LS is a pleasure to write. But the tooling on ES6 is nicer I must admit :/

Out of curiosity, what tools are you referring to that are nicer on ES6 and not applicable to LS? Could you give examples?

Re: State of the Art JavaScript in 2016

#213
post #84

Why not mithril? https://lhorie.github.io/mithril/ Seems to be way faster, and easier to learn than any of those other framework/libs. For example: How is Mithril Different from Other React: Source: https://lhorie.github.io/mithril/comparison.html "The most visible difference between React and Mithril is that React's JSX syntax does not run natively in the browser, whereas Mithril's uncompiled templates do. Both can…

Mithril is really nice, I've been following its progress since the beginning. If I had to use a framework, Mithril would be my first choice.

lichess.org is a very busy application built around Mithril.

Re: State of the Art JavaScript in 2016

#215
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 really nice with a very good much to common JS patterns. Among other things it types the usage of string literals making possible to typecheck and refactor code that contains if (foo === 'bar').

Re: State of the Art JavaScript in 2016

#216

Because of all this chaos i heavily lean towards Angular 2 and TypeScript. It's a good common ground for larger apps imo and has good best practices.

I think the same. I don't understand the react hype. Yes, it is easy to learn but it doesn't even have basic features such as routing. Maybe I am more a framework guy but I think on such a basic level of software development a framework does better than a fragmented ecosystem.

Re: State of the Art JavaScript in 2016

#217

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

? I always just install `isomorphic-fetch` or the browser-only version. Works fine. Why load jQuery instead of that?

fetch does not support cancellation or onprogess events.

Re: State of the Art JavaScript in 2016

#218
post #209

Earlier quoted context omitted.

I'm using LiveScript for private stuff and ES6/JSX in production. LS is a pleasure to write. But the tooling on ES6 is nicer I must admit :/

Out of curiosity, what tools are you referring to that are nicer on ES6 and not applicable to LS? Could you give examples?

all the auto-complete stuff in atom.

Re: State of the Art JavaScript in 2016

#219

Earlier quoted context omitted.

It's also more than a little frustrating when you come to HN and people say "Angular/Node/whatever is bad, and you're a bad person if you use it" all while I'm actually making neat stuff using the aforementioned tools. Well, I thought they were neat before at least.

While other people are busy writing blog posts, I've been shipping successful projects with Angular. I'm getting paid to write code, and I don't get paid to write blog posts defending Angular, so I don't bother. Also, I've shipped some very complex apps built with Angular, and it's very obvious to me that many of the common complaints about it are nonsense written by people who have just used it for a few days.

> While other people are busy writing blog posts, I've been shipping successful projects with Angular.

I've got no dog in the Angular fight, but I will point out a problem with the 'while others have been arguing I've been shipping' line: while it does optimise for productivity ('shipping'), it ignores correctness. Imagine someone writing, 'while others were fighting over crypto, I was shipping [ROT13-using code].'

My problem is that these arguments are important: e.g. we know that the halting problem is not generally computable, so a product which relies on computing it cannot be right. And oftentimes 'just shipping' ignores the lessons learnt by those with more experience than oneself: 'I've been shipping' can really mean 'I've been busy putting myself in a position to learn' and 'others writing blog posts' can really mean 'folks who've learnt the hard way trying to warn others.'

Like I said, I really have no clew if Angular is a problem or not; I don't really write any JavaScript these days. My only concern is the form of your argument.

Re: State of the Art JavaScript in 2016

#220

Earlier quoted context omitted.

Your "obvious" problem is based on the premise that whoever has the most money will win a lawsuit in the US. In that case, almost no-one using React needs to worry about this, because either Facebook is going to come after them and they will lose but that could happen regardless of how they act, or Facebook is going to decide they don't want to come after them and it doesn't matter.

This. I get that there's a few corporates that might have a patent portfolio they'd conceivably want to enforce against Facebook. But for the rest of humanity this is just a non-argument. If FB want to pick a fight with you, you're in a fight whether you use React or not.

It's just that with using react you leave your castles gate wide open.
Post reply on HN