8 ms·

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

• serve_yay 11y ago
  Yikes! Don't blame ES6 for this mess :P
• Strilanc 11y ago
  Nit: single line lambdas can be written like `a => a + 1` instead of `a => { return a + 1 }`. Cuts the amount of bracket nesting.
  • gravity13 11y ago
    After working with es6 for a bit (with babel), I still think I prefer CoffeeScript mostly because it's annoying to ensure brackets/parenthesis are closed properly.
    • cnp 11y ago
      Its funny, I used to really enjoy CoffeeScript but since Babel / ES6 has come out I can't stand it anymore! ES6 has just the right amount of syntax, with lots of optionals too (semicolons, no brackets when writing function expressions, etc).
    • notNow 11y ago
      I compile JS files to CoffeeScript now only for the readability boost when I need to understand the code very quickly without all those parentheses or brackets getting in my way.
• _greim_ 11y ago
  Is "@inject(HttpClient)" ES6 too? I don't recognize it but I haven't memorized all the new capabilities yet.
  • serve_yay 11y ago
    Those are decorators, a feature planned for ES7. This code sample is, uh, kinda weird.
• peter_l_downs 11y ago
  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?
  • deleted 11y ago
    [deleted]
  • serve_yay 11y ago
    "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&loose=false&spec=false&code= http://babeljs.io/repl/#?experimental=true&evaluate=true&loo...
    • pjmlp 11y ago
      In this side of the galaxy still looks like JSF with RichFaces and ASP.NET WebForms.
    • eltaco 11y ago
      There's currently a issue for "speed": https://github.com/babel/babel/issues/1486 https://github.com/babel/babel/issues/1486. Looks like it complied ember core from 50s to 18s now.
      • serve_yay 11y ago
        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.
    • unoti 11y ago
      Whoa, thanks for introducing me to Babel. It looks like user plugins could be wildly, astonishingly powerful for doing compile-time code execution.
• casus 11y ago
  > "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.
  • cnp 11y ago
    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.
    • rspeer 11y ago
      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 the time I make any progress, one of those has made a compatibility-breaking update, or even been abandoned and replaced by something better. Great that things keep getting better, but at some point I want to get off the ride.
      • woah 11y ago
        You can get off the ride right now.
      • RodgerTheGreat 11y ago
        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.
        • 11y ago
• rattray 11y ago
  It's even better if you use `yield` or `async/await`: activate(params) { let fabric_response = yield this.http.get(`${ this.url_base }/fabrics`) return fabric_response.content.map( fabric => { let cluster_response = yield this.http.get(`${ this.url_base }/fabrics/${ fabric.name }/clusters`) if(fabric.clusters_exist) { this.fabrics.push({"name": fabric.name, "clusters": cluster_response.content}); } }); } EDIT: note that I am very sleepy and probably did a poor job of this =)
  • mcv 11y ago
    I was at a meetup yesterday where Axel Rauschmayer explained what's new in ES6, and especially the use of generators and yield was to me a mindblowing new way of programming. Yours is a nice example of using yield to turn asynchronous code synchronous.
• wmichelin 11y ago
  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_436939394.jpeg http://photos3.meetupstatic.com/photos/event/4/b/c/2/600_436...
  • bbcbasic 11y ago
    Looks like idiomatic JS code to me.
    • untog 11y ago
      I'd question the need for that many nested callbacks when you're already using Promises.
    • lobo_tuerto 11y ago
      http://tritarget.org/blog/2012/11/28/the-pyramid-of-doom-a-javascript-style-trap/ http://tritarget.org/blog/2012/11/28/the-pyramid-of-doom-a-j...
      • mrweasel 11y ago
        For some reason naming your functions in JavaScript often get meet with strange looks. My colleague just love anonymous functions. I think that at least some like the callback hell, because they think it makes them look clever.
      • antod 11y ago
        'Pyramid of Doom'? Sounds more like something from a certain python web framework to me. ie: http://docs.pylonsproject.org/en/latest/_downloads/pyramid-aliens2-1024X640.jpg http://docs.pylonsproject.org/en/latest/_downloads/pyramid-a...
• coldtea 11y ago
  >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. Oh, the irony...
• merb 11y ago
  i dislike the import part. without writing the from part first you can't evaluate the import..
  • altano 11y ago
    Yeah, the creator of TypeScript was complaining about this in a presentation. I think the existing syntax "import X from Y" reads more naturally than "from Y import X" but obviously the latter is better for tooling and autocomplete/intellisense. Oh well!
• frik 11y ago
  The only downside seems that if one uses new keywords like "class" one has to use a transpiler back to JS5 to avoid syntax errors in IE11 and other older still supported browsers&devices that will never receive an update (like Android 2x/4, Blackberry, WinPhone7/8, etc). A fallback solution like JQuery isn't possible for new keywords. Try-catch keywords were previously introduced too, but are rarely used because their implementation is known to be slow. Beside that JS5 code with fallback functions still works fine in very old browsers like IE5.
• SiVal 11y ago
  Actually I do recognize those final six lines. That's what I used to get on my terminal screen decades ago when I was trying to pull the phone out of the accoustic coupler and hang up.
• erikpukinskis 11y ago
  It's funny to me, I used to merely tolerate JavaScript... I came from Ruby (and PHP/Java/C# before that) where you could create these super complex control flow structures and JavaScript felt so verbose and unwieldy and limited. I mean, no inheritance? No method_missing? How do you write humane, readable DSLs with just functions and prototypes? I've explored all kinds of tricks since then: OO libraries, promises, fibers, CoffeeScript classes and all its other sugar. What's interesting is I've swung fully back in the other direction. I find myself increasingly drawn to very simple, very JavaScripty JavaScript. Functions. Variables. Constructors. Prototypes. Closures. Arrays. Objects. I think almost all of the new JavaScript features are more trouble than they're worth. Take promises for example. Here's some junky callbacky JavaScript: libraryStuff(function() { moreLibraryStuff(function() { thirdLibraryStuff(function() { console.log("done!") }) }) }) Gross. Nesting. With promises you can do this lovely bit of magic: libraryStuff() .then(moreLibraryStuff) .then(thirdLibraryStuff) .then(function() { console.log("done!") }) Which certainly fixed the nesting problem. But you made your stack almost incomprehensible, and you made your execution thread harder to trace. And now the runtime is popping back and forth between your code and the promise library every step. But the scariest thing of all is you created a bunch of these promise objects that you could, like, return, and some totally unrelated code could interact with it and totally fudge up the control here. You took something that had really well bounded semantics and turned it into something that is wide open to be messed with in bizarre ways. That's what power is. That's why people love promises, you have power to do all manner of outlandish control flow. Except I really don't want to have to debug your bizarre circus of promises. Don't get me wrong, I am certainly capable of debugging your circus of promises. I just really would prefer not to. And anyway there's a way easier solution. Because JavaScript uses function scope, you can just do this: libraryStuff(yourResponse) function yourResponse() { moreLibraryStuff(yourNextResponse) } function yourNextResponse() { thirdLibraryStuff(finish) } function finish() { console.log("done!") } It's easily traceable. You get a real call stack no matter where you crash in that flow. And yeah, I doubled the number of symbols here, but that just means I was forced to actually label my application code. Which might not be such a bad idea anyway. In my production code all of these functions are going to be several lines anyway, and it's quite nice to be reminded that I should give them a good label. Of course if this was CoffeeScript, your stacktrace wouldn't have function names because CoffeeScript threw away that feature in exchange for being able to type "->" instead of "function". I've noticed this pattern over and over: someone gets frustrated because JavaScript doesn't give you insane tools to quickly spin up bafflingly complex flow structures. They find this frustrating, because they're used to baffling flow structures from all of the crappy code they've been forced to get comfortable with, so they write some insane library that lets you do crazy stuff in JavaScript. The same thing happened to me in Ruby. I was so entranced by the power and magic of DSLs that I was constantly looking for excuses to return chainable objects from functions and all of this stuff. I would build things like that in production code, and feel proud of myself that I made this super powerful thing with a complicated implementation and a simple, prose-like interface. But almost every time, after living with the interface for a while, I would realize that I could've solved the problem with just functions, literals, and arrays, and structs if I had actually taken the time to figure out the right abstractions. Less and less do I think I need some fancy new kind of function. More and more I think I need to be more thoughtful about what the function actually does.