Live data from Hacker News

ECMAScript 2015 Approved

ecma-international.org

51–60 of 108 posts

Re: ECMAScript 2015 Approved

#51
post #47
post #38

Earlier quoted context omitted.

Once you do it once, its done. Also, tons of scaffolds out there to choose from / tweak. This sort of flexibility is a good thing.

Eh. JS is a very useful language but something has to get us out of this explosion of tools eventually. For the last couple of projects I've worked on, I've had to choose: - The scaffold - The build tool - The actually-good language variant that compiles to JS that a browser can run - The tool that makes the build tool work with the scaffold - The tool that makes the build tool work with the language variant And by t…

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. Framework churn is a symptom of invented problems that don't need solving.

Re: ECMAScript 2015 Approved

#52
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.

The list of things you're seeing above appears to be a compiler, two package managers, a build runner, a module implementation, and an app framework. Which languages do you work in building apps of any complexity where you don't need any of those?

Saying you "have to use" any of those things (except for the compiler/runtime) is an overstatement at best. As in other languages, if something solves a problem for you, use it. If not, well, you don't have to use it, unless you're stuck on a team who uses things because This Is How We Do Things Now(TM), which is not a JS specific affliction.

I think one could reasonably argue that two package managers is not only overkill it's a problem (in fact, I sometimes do argue that browser-specific package management shouldn't be part of projects I'm on), and that most languages don't have to deal with competing module implementations because they came baked in (fair).

I think one could also possibly argue that the explosion of JS libs/tools seems to be near-cambrian in its proportions and it's hard to keep up with, but from where I sit this looks like a consequence of (a) the expanding reach of the browser as a platform (b) second-order magnifying effects of popularity (c) where npm is involved a tilt towards smaller libraries and lots of dependencies and (d) the fact that making a library is a way to make a name for yourself (incentivizing lots of libraries).

Re: ECMAScript 2015 Approved

#55

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?

"Everyone" is using Babel now. A lot of ES6 features are making their way into browsers and node, but there's so much variation that a transpile step is needed. Babel is nice but currently quite slow. Babel has a REPL you can play with here: http://babeljs.io/repl/#?experimental=true&evaluate=true&loo...

Whoa, thanks for introducing me to Babel. It looks like user plugins could be wildly, astonishingly powerful for doing compile-time code execution.

Re: ECMAScript 2015 Approved

#56
For anyone interested in using ES2015/ES6 in production, I'd highly recommend checking out jspm and SystemJS.

It handles all the transpilation work for you (at runtime for development, or during a manual build/bundling for production) using either Babel, Traceur or Typescript, and allows you to seamlessly use ES6 everywhere in your code and even load third party code on Github and NPM as ES6 modules.

https://github.com/jspm/jspm-cli

https://github.com/systemjs/systemjs

EDIT: Some more info copied from another post:

SystemJS (jspm's module loader) has the following main advantages compared to competing module loaders:

- Able to load any type of module as any other type of module (global, CommonJS, AMD, ES6)

- Can handle transpilation and module loading at runtime without requiring a manual build step

However, jspm itself is primarily a package manager. Its main advantages over existing package management solutions include:

- Tight integration with the SystemJS module loader for ES6 usage

- Maintains a flat dependency hierarchy with deduplication

- Ability to override package.json configuration for any dependency

- Allows loading of packages from just about any source (local git repos, Github, NPM) as any module format

Re: ECMAScript 2015 Approved

#57
post #47

Earlier quoted context omitted.

Eh. JS is a very useful language but something has to get us out of this explosion of tools eventually. For the last couple of projects I've worked on, I've had to choose: - The scaffold - The build tool - The actually-good language variant that compiles to JS that a browser can run - The tool that makes the build tool work with the scaffold - The tool that makes the build tool work with the language variant And by t…

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

Re: ECMAScript 2015 Approved

#58
post #13

What does it mean for a spec to be approved? Is it like a peer-review?

Yes - TC39 is responsible for updating the standard ( http://www.ecma-international.org/memento/TC39.htm ), meaning that they all voted to approve the current draft ES2015. You can see several years of the drafts here http://wiki.ecmascript.org/doku.php?id=harmony:specification...

And TC = Technical Committee.

Re: ECMAScript 2015 Approved

#59
post #46

Earlier quoted context omitted.

"Everyone" is using Babel now. A lot of ES6 features are making their way into browsers and node, but there's so much variation that a transpile step is needed. Babel is nice but currently quite slow. Babel has a REPL you can play with here: http://babeljs.io/repl/#?experimental=true&evaluate=true&loo...

There's currently a issue for "speed": https://github.com/babel/babel/issues/1486 . Looks like it complied ember core from 50s to 18s now.

Yep, saw that. I don't think it's enough of an issue to not use Babel (my team uses it and we all think it's great), but it is suboptimal.

Re: ECMAScript 2015 Approved

#60
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.

i dislike the import part. without writing the from part first you can't evaluate the import..
Post reply on HN