Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

State of the Art JavaScript in 2016

medium.com

Post reply on HN
Print view View original

261–270 of 306 posts

Re: State of the Art JavaScript in 2016

#261

Post by spankalee »

nzonbi wrote: post #53
STRML wrote: 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 d…

Note that style scoping comes with Shadow DOM, so once browsers support that (it's happening now), you can get scoping with no libraries.

Polymer also adds a CSS custom properties polyfill and a CSS mixins (@apply) polyfill. Custom properties are implemented in FF and Chrome already, @apply is being worked on in Chrome.

Polymer always tries to be forward compatible with actual web standards, one of it's main benefits :) Eventually Polymer will mostly be just templating and convenience helpers on top of native standards.

Re: State of the Art JavaScript in 2016

#262

Post by jjawssd »

BillyParadise wrote: post #157
jjawssd wrote: post #133

Earlier quoted context omitted.

Not sure if sarcasm or serious, but this sums up everything that is wrong with the Javascript community succinctly

I'd place a small bet on the former, but I wouldn't go all in. I agree with you - those javascript folks are more ADHD than me. And that's saying a lot.

Good point

Re: State of the Art JavaScript in 2016

#263

Post by akamaka »

wtbob wrote: post #219
akamaka wrote: post #176

Earlier quoted context omitted.

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].' M…

You're entirely correct about the form of my argument being weak. Too busy shipping code to make a more coherent argument. :P

I definitely do worry sometimes that spending too much time getting things done takes away from time spent learning how to do things better. I hope that I've found a good balance between the two, but it's easy to get it wrong, and your point is an important one.

Re: State of the Art JavaScript in 2016

#264

Post by bbcbasic »

t1amat wrote: post #230
bbcbasic wrote: post #193

I have found using Elm a real joy, albeit for hobby projects. I do hope pure functional languages become state of the art by 2026.

Elm has a lot of beauty to it. I would definitely promote anyone interested in learning FRP in web development to look here first. They really nailed the essence of the architecture, and getting some experience with ML-family languages is bonus, as they are likely more approachable than Lisp-family languages for many. I'm really hoping Evan and the community can make this a more viable solution in the coming years. T…

I agree I am learning Elm mainly to learn FRP and do some 'haskell with my hands tied behind my back' because I believe you can get a lot done without resorting to the advanced language features of Haskell.

So for me it's a kata for learning how to be a better functional programmer. Once I feel I 'get' the FRP model used I may just go and do the same stuff in another language, see how it plays out in Haskell or Purescript.

I feel FP will remain a hobby though and the best I can hope for is to convince .NET colleagues to make immutable classes, use code contracts to avoid null problems, and generally try to minimize state and maybe use Rx. Even F# would be too much of a push for most .NET shops. I have a mortgage and fixing bugs caused by ridiculous state and null references in .NET code pays it and then some :-)

Re: State of the Art JavaScript in 2016

#265

Post by jbergens »

xirdstl wrote: post #239
anantzoid wrote: post #184

Earlier quoted context omitted.

> You've a choice of 25 frameworks, libraries, tools that change every day and break between versions. And this is what the author has said too, and then presented a list of tools for different purposes to one doesn't fall into analysis-paralysis. Since past few months, JS community and settling down and tools are getting stable and long lasting. Surely, new ones are being developed everyday, but a standard is being…

It is extremely hard to believe that anything in the JavaScript ecosystem will be a standard or 'here to stay' for any timeframe greater than a year or so.

Both React and Angular has existed for more than a year. Angular is a couple of years old and still works although they have new version.

Re: State of the Art JavaScript in 2016

#266

Post by andybak »

lomnakkus wrote: post #253
andybak wrote: post #195

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…

Well, I guess I can count myself amongst the "haters". Specifically, I noticed your > 4. I hate dynamic typing ... but I absolutely disagree with the phrasing. Your underlying assumption seems to be that "dynamic typing" is a Good Thing, by definition. I want to challenge that. Thing is... I don't hate dynamic typing[1] as long as everyone is being "consenting adults" about it (GvR)... I just LOVE static type checkin…

Yes. But my point is that not every discussion needs to be dominated by the well-known split between two factions who both have strong feelings about type systems.

You have every right to evangelise - but try and try and avoid making top level comments on the matter unless it's on a post that specifically is discussing static vs dynamic typing. The subject gets enough airtime and it's good for other topics to get a look in. :-)

Re: State of the Art JavaScript in 2016

#267

Post by andybak »

gotchange wrote: post #258
andybak wrote: post #211

Earlier quoted context omitted.

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

Yes we can and I started by yours. Sorry not adding to the discussion.

I actually edited my top level comment immediately after writing it to try and engage more directly with the topic at hand and tone down the 'meta-ness' of my post.

Even so I'm slightly embarrassed that it's the top voted comment. I'd prefer it if a more strictly on-topic comment was above me.

Re: State of the Art JavaScript in 2016

#268

Post by arxpoetica »

andybak wrote: post #196
arxpoetica wrote: post #128

No mention of WebSockets...

What percentage of projects need them? Surely it's not a core requirement outside of actual real-time apps (and not 'lets play with realtime on my shiny blog').

WebSockets are one of the most underestimated value-adds in modern browsers. Pub-sub. Real time. Ease of data transfer and client-to-server synchronization. I can't think of a modern project that wouldn't benefit from sockets, unless the site is literally 100% static. But then, why use most of the stack outlined in the article?

Re: State of the Art JavaScript in 2016

#269

Post by vmware505 »

Ember.js is already proved, the best framework out there nowadays. Corporate ready, production ready, future proof. I'm really looking forward, that Type Script support will be landing soon in the framework, so it will be a concrete solid environment. The whole addon ecosystem, with Ember Data and Ember CLI is just top-notch.

You can check here with this tutorial, how easy to write a complex application with Ember.js: http://yoember.com

Re: State of the Art JavaScript in 2016

#270

Post by RobertKerans »

kenOfYugen wrote: post #200

> 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 think the key point he makes (even though it's almost throwaway at the end of the paragraph) is that the community is rapidly declining. I agree with you completely on the syntax: it's not my bag (I prefer writing plain [ES6] JS), but idiomatic CoffeeScript is remarkably expressive. But the decline, which is undoubtedly accelerating, is problematic. I'm busy ripping CS code out of several big Rails apps simply for the sake of maintainability going forward. Good CoffeeScript code is not quite 1-to-1 translatable to/from JS; it's a simple language, but it is an actual language with its own constructs. I feel it's important to make it as easy as possible for others to maintain code I've written, and using JavaScript makes that easier than having it written in another language.

The Bluebird comparison I think is off for that reason - Bluebird is a JS library: you only need to know the API, it's still JS. If a developer understands promises, there's no great step between native and Bluebird.

(I totally agree with what you're getting at btw, I just think [maybe for the worse, maybe not] that it is pragmatically better, with the advent of ES6, to stick to JS; TypeScript maybe gets a let-off here as it's just a thin layer on top, not a different language).

Post reply on HN