Live data from Hacker News

ECMAScript 2015 Approved

ecma-international.org

71–80 of 108 posts

Re: ECMAScript 2015 Approved

#71
post #11

It's about fricken time! Talk about procrastination! Now I have to wait for browsers to get off their little snowflake asses and update. Oh wait then there is all those paranoids who use WinXP with IE8. Damn it, I'll be dead by the time this stuff is available universally.

One of the reasons why I'll go with Dart or TypeScript or whatever anyway. ;)

Or just use a transpiler.

Re: ECMAScript 2015 Approved

#72
post #29
post #16

If you've been focusing on another language for a few years, you might not recognize JavaScript anymore. It's pretty awesome now. Here's an example of what it looks like: http://pastebin.com/raw.php?i=yEB4mrty As someone who usually works with C, Scala, and Java -- I'm currently working on a small app built on ec6/7 babel, npm, jspm, system.js, aurelia, gulp, etc. It's been a great experience so far.

> "a small app built on ec6/7 babel, npm, jspm, system.js, aurelia, gulp, etc" Part of the problem with the Javascript ecosystem is that you have to use so many different tools/libraries to create a "simple" app.

it's called don't reinvent the wheel and let you focus on real problems while delegating the rest to 3rd party libraries!

Re: ECMAScript 2015 Approved

#73
post #16

If you've been focusing on another language for a few years, you might not recognize JavaScript anymore. It's pretty awesome now. Here's an example of what it looks like: http://pastebin.com/raw.php?i=yEB4mrty As someone who usually works with C, Scala, and Java -- I'm currently working on a small app built on ec6/7 babel, npm, jspm, system.js, aurelia, gulp, etc. It's been a great experience so far.

You could write that code to be a little more human readable. That appears to be complicated for the sake of being complicated. Elegance doesn't have to be complexity, or trying to write as few lines as possible. http://photos3.meetupstatic.com/photos/event/4/b/c/2/600_436...

Looks like idiomatic JS code to me.

Re: ECMAScript 2015 Approved

#75
post #61

Earlier quoted context omitted.

Every language these days has its "stack" for development. Sure you could sit down with vim and javac and write a "simple app". But once you use Gradle/Maven to handle dependencies and build process. Once you use a nice unit testing framework... Why on earth would you not just fire it up and tune it for every project? Ruby, C# and every other language I've used has this "development stack" mentality, and now when I t…

Compare to go, where you can go a very long way using "go get", "go build", "go run" etc.

Node.js apps can be even easier than that (only two necessary commands): `npm install` for `go get` and `node [script.js]` for `go run`.

If you want to do compilation there are various solutions available to you as well!

Re: ECMAScript 2015 Approved

#76
post #29
post #16

If you've been focusing on another language for a few years, you might not recognize JavaScript anymore. It's pretty awesome now. Here's an example of what it looks like: http://pastebin.com/raw.php?i=yEB4mrty As someone who usually works with C, Scala, and Java -- I'm currently working on a small app built on ec6/7 babel, npm, jspm, system.js, aurelia, gulp, etc. It's been a great experience so far.

> "a small app built on ec6/7 babel, npm, jspm, system.js, aurelia, gulp, etc" Part of the problem with the Javascript ecosystem is that you have to use so many different tools/libraries to create a "simple" app.

I actually like this feature of Javascript. Much better than being stuck with a small number of monolithic tools or rarely-updated standard libraries, in my experience.

Re: ECMAScript 2015 Approved

#77

Earlier quoted context omitted.

At some point, you just need to stop caring about those people. I know some of you can't professionally, but personally, there's no need to even pretend to support IE <= 11. If they want to run an old os and old browser, they don't get to use my service. No sweat off my balls.

Finding actual numbers seems to be harder than it should be, but this page: https://www.netmarketshare.com/browser-market-share.aspx?qpr... ...suggests that IE 8, 9 and 10 combined have about ~28% market share. Of course, I don't know what they're measuring --- somewhere like github is going to see a very different balance of browsers than, say, Amazon --- but that's a hell of a lot, roughly equal to the IE 11 market…

> That suggestions that netmarketshare are consistently measuring IE high

That's because those tables arae

StatCounter (and the W3Counter/Wikimedia things in the tables you cite) are measuring website visits.

NetApplications/netmarketshare is measuring unique users.

So what that data shows is likely several things going on at once:

1) Chrome (and Firefox, for that matter, if you look at te the tables)) users load more webpages than IE users.

2) Chrome does some webpage prerendering stuff that can get counted as "visits" if you're not very careful; not sure how well StatCounter accounts for this.

3) Likely some differences in the actual base data, though I expect this is really minor compared to item #1.

Of course I couldn't agree more with your general claim that web-wide statistics are a poor replacement for specific statistics for a particular site. But even there the question of "visits" vs "unique users" might be an important one.

Re: ECMAScript 2015 Approved

#78
post #65

Earlier quoted context omitted.

I've been away from JS for about 10 months and... cool, but, fuck, that changed quickly. Time to get caught back up to speed. Is ES6 now actually viable, in that it's supported by most users' browsers? If not, are there popular compilers for ES5?

To answer your browser compatibility question: https://kangax.github.io/compat-table/es6/

[deleted]

Re: ECMAScript 2015 Approved

#79

Earlier quoted context omitted.

You could write that code to be a little more human readable. That appears to be complicated for the sake of being complicated. Elegance doesn't have to be complexity, or trying to write as few lines as possible. http://photos3.meetupstatic.com/photos/event/4/b/c/2/600_436...

Looks like idiomatic JS code to me.

I'd question the need for that many nested callbacks when you're already using Promises.

Re: ECMAScript 2015 Approved

#80

Earlier quoted context omitted.

That's an interesting definition of "had to". If you don't like the complexity all that tooling and boilerplate adds to your project, why not just write your application in vanilla CSS, HTML and JavaScript? It still works fine. Most of the time I'd much rather work with imperfect but standard tools than waste time learning the "hot new stuff" and constantly fix what flighty other developers break or abandon. Framewor…

Because vanilla CSS, HTML and JavaScript sucks? Hence all the tools, frameworks and scaffolds...

It would be helpful to quantify "sucks" in there. Otherwise it's simply an opinion. As an exercise, just write your own XMLHttpRequest interface. It will take you about 20 lines or less, even doing it in the most naive way. I'm serious, go do this. It will make anyone a better developer.

Frameworks rarely give you much for all the baggage that comes with it. I say this as an angular user specifically, but I haven't used any others that don't have this problem.

It might, MIGHT, be that these standard setups suck, but if they do, adding a complicated toolchain without a reason doesn't seem like a very pragmatic approach to why the suck or how to fix them.

Post reply on HN