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

191–200 of 306 posts

Re: State of the Art JavaScript in 2016

#191

Post by z3t4 »

err4nt wrote: post #64
z3t4 wrote: 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…

How does it look on retina/hiDPI displays?

I've never had the chance to use a hiDPI display. But it will probably be upscaled and look the same as on a normal screen. It would be an easy fix to increase the canvas context scale though.

Re: State of the Art JavaScript in 2016

#192

Post by Sacho »

alextgordon wrote: post #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 nee…

Meh. I think a better reason to use something over $.ajax is the functionality and the API, not because "you don't need jQuery". $.ajax is very general purpose, whereas in most cases you simply need to be able to get and post json. Also, jQuery's promise implementation is one of the least-featured and most awkward to use, which drags down the $.ajax API.

Re: State of the Art JavaScript in 2016

#194

Post by noir_lord »

girvo wrote: post #183
utku_karatas2 wrote: post #123

Earlier quoted context omitted.

JS scene desperately needs a moratorium on tooling just like Python did on language features 5-6 years ago. Actually the language also needs a total freeze in features. ES5, ES6, transpilers, this and that and bla bla. I used to love language geekery, not so much after a few years of JS exposure. And now there is WebAssembly which is supposed to be a "game changer". Fuck that. I don't want the game to change anymore,…

I don't understand this argument at all. You don't have to be on the bleeding edge. In fact I recommend against it for nearly all cases. If you want to write standard ES5, and skip all this stuff, you can! There is no one holding a gun to your head telling you to keep up "or else". I pick and choose the tools I need. Some are new, some are old. This goes for any language I use, too, not just JavaScript.

I'm still using browserify, knockout and lodash for all my projects, been using knockout for over a year and it has been rock solid, had zero issues that where traced back to knockout, browserify has worked very well for me same with lodash.

I keep an eye on what is coming down the pipe but I don't buy into anything until it's been around long enough for me to get a good grasp on what the lay of the land is.

In the meantime I have a working stack that allows me to accomplish anything I reasonably need to and I know it'll work.

For those not au fait with Knockout, recent releases add HTML components, deferred and pure computeds and in 3.4 they increased performance through hot paths over 100% making it insanely faster.

I like it a great deal.

Re: State of the Art JavaScript in 2016

#195

Post by andybak »

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

We've had all the obvious reactions:

1. This isn't my stack of choice

2. React is flawed

3. Don't use frameworks at all

4. I hate dynamic typing

5. Javascript is broken beyond repair

6. It will have changed by next week

All of these are valid discussions to have but they get wheeled out every time and - maybe with the exception of point 1 - they are only indirectly related to the topic of this post.

So every js discussion becomes a meta-discussion. Same thing with Google posts ('oh they'll close that down next week'), ORMs ('they suck'), Python ('Python 3 was a mistake') etc.

HN comments needs an on-topic vs off-topic filter. Or a "yes we already know that" filter...

(The irony of the above statements when this is also a meta-post is duly noted)

My own feeling is that everyone should avoid jumping on complex frameworks until they are really needed. jQuery, Pjax or intercooler.js can take you a long way and save a lot of headaches. But when you do need a proper MVC-like framework then this article is a valuable guide of the sort that people have been asking for for months.

Re: State of the Art JavaScript in 2016

#197

Post by thenomad »

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…

I'd assume the reactions in this thread are part of the reason why people have been asking for a guide like this for months, and one hadn't been forthcoming.

The "if I write an article expressing my opinion on this controversial issue I believe is important, 99.7% of the responses will be attacks, more or less regardless of the amount of time I put into writing it or the extent to which it's 75%, 95%, or 99% accurate" issue is a problem Internet-wide.

Of course, criticism is valuable, but the balance seems a little skewed right now.

Re: State of the Art JavaScript in 2016

#199

Post by Galaxeblaffer »

akamaka wrote: post #176
CalRobert wrote: post #138

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.

This !!!!

Re: State of the Art JavaScript in 2016

#200

Post by kenOfYugen »

> 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 compared to even #4 Clojure at 51 LOC/commit. By the time we’ve gotten to #8 Groovy, we’ve dropped to an IQR of 68 LOC/commit. In other words, CoffeeScript is incredibly consistent across domains and developers in its expressiveness."[1]

Using the author's train of thought I could state: "Avoid Bluebird[2]. Most of its better features are now in ES6 promises, a standard."

Yes promises are in the ES6 standard, but that's not the best feature of bluebird. There were and are many promise based libraries, but bluebird was built for unmatched performance. One will use it if performance matters.

Even today it's faster than the native implementations of promises [3].

> Tooling (such as CoffeeLint) is very weak.

Maybe because, as it turns out, in CoffeeScript you don't need a lot of tooling. Why would that be a bad thing?

> Electron is the foundation of the great Atom editor and can be used to make your own applications.

Atom is written in CoffeeScript [4].

[1] http://redmonk.com/dberkholz/2013/03/25/programming-language...

[2] https://github.com/petkaantonov/bluebird

[3] http://programmers.stackexchange.com/questions/278778/why-ar...

[4] https://github.com/atom/atom

Post reply on HN