14 ms·

The State of Babel

241 points by BenjaminCoe 10y ago

xwowsersx 10y ago
As an outsider to FE development, when I see posts like this, I just shudder at the complexity of the ecosystem.
- ng12 10y ago
  It's no worse than any other ecosystem. Modern Java development is just as prickly -- the only difference is the complexity is more established. JS is still very "wild-west" because the community is still making rapid progress towards an ideal environment.
  - xwowsersx 10y ago
    You may be right, but I'm not sure I totally agree. Maybe this is exactly what you meant, but I think the complexities are different. Java is inherently complex, I'll give you that, but in JS and FE development in general, it seems like the most basic building blocks are constantly being reinvented...large, open questions on basic stuff.
    - vcarl 10y ago
      > large, open questions on basic stuff. I've commented on this subject before[0], I think the past few years of web development has largely been about answering basic questions. Now there are well tested answers to those questions. I'm sure people will still reinvent these wheels, but now you don't have to when working on a large project. Babel, Webpack et al are more useful when you're building a web-app, something generally comparable to a native app. The toolchain is complex, sure, but no more complex than what xcode or Android Studio do for you. I think the difference is that this has been a community effort, rather than a corporation assembling a product, so a) there are more people sharing opinions and b) the disagreements and exploration has been more public. [0] https://news.ycombinator.com/item?id=12828042 https://news.ycombinator.com/item?id=12828042
    - seangrogg 10y ago
      The issues with FE are twofold: browser incompatibilities and user expectations. The first is becoming easier over time (stop using IE, please). The second is an ongoing arms race. Writing front end code is like writing a CLI. It starts off really easy - you have a use case (whether that's a page about your cat or a script that echoes "meow"), you solve for it, you show it off. But then people ask for it to do other things. So you have to extend the code - perhaps we need to add flags so users see dog stuff instead of cat stuff. Oh, now users want an actual ascii animal to see so we cater to that. Now they want to name it so let's accept input somehow. They want to issue commands to it so let's deal with parsing and conditional branches. The problem is that we have to deal with constant changes from browsers, from stakeholders, and from users. Stakeholders want certain features from our programs, users expect a certain standard of performance, and browsers hamper us with incompatibilities. So we build libraries that solve some of these problems. jQuery helped us build websites, but then web apps became a thing. Backbone/Ember/Angular helped us build web decent web-apps, but then performance became a thing. React/Angular2/Ember2/Vue help us build performant applications... until the next thing. I think the real problem are the choices people opt-in to. I use React and don't have JavaScript fatigue - but I've also chosen not to use JSX, Babel, Webpack, SSR, live reloading, linting, typing, automated deployment, trello, TravisCI, Docker, k8s, etc. Just libraries imported with script tags, writing ES5 (current standard, 100% implementation), using React.createElement and I've had no issues. People may opt-in to reinvention and questioning basics, but there are plenty of individuals that get by just fine.
  - deleted 10y ago
    [deleted]
  - mhd 10y ago
    Java and C++ always end up as the baselines for comparisons, besides both not being exactly being the poster boys of their respective fields. Just because C++ compiles even slower or a non-standard Maven setup is more inscrutable doesn't exactly praise the alternative. We should stop being so content with not being/using the worst.
  - ern 10y ago
    I disagree that the constant churn in FE/JS is necessarily a sign of "rapid progress", rather than a lack of strong stewardship/leadership leading to people reinventing the wheel. I haven't worked with Java for a long time, but from what I've been hearing from colleagues who are exploring writing production software with it, .NET Core is currently a bit of a mess, showing that even coherent dev stories can easily slip into disorder.
    - ng12 10y ago
      > a lack of strong stewardship/leadership leading to people reinventing the wheel There's lots of strong leadership. React, Angular, Vue, Ember, etc. all have very intelligent, hard-working people backing them. These frameworks aren't "reinventing the wheel", it's the complete opposite: the community has finally freed itself of jQuery/global scope/imperative DOM and these frameworks are all pushing the border in one way or another.
    - gotofritz 10y ago
      > I disagree that the constant churn in FE/JS is necessarily a sign of "rapid progress", It's the field that is progressing rapidly. Browsers are constantly adding new APIs, problems are being solved, etc. The difference is that it's open source > a lack of strong stewardship/leadership You can't have leadership in a field which has no owner. It's not like Oracle owning Java and deciding what happens with it. > people reinventing the wheel. This is a stereotype by people who don't really know the subject. Every new tool improves on the previous one. For example, grunt was the first JS build tool, it had some issues (huge configurations, and speed) some someone invented gulp, which uses streams for speed and code instead of configuration. But streams don't handle splitting files in bundles and other problems so well, so webpack was invented. There are overlaps but they all solve different problems, and all improve on the previous generation. They are not "reinventing the wheel"
      - douche 10y ago
        How many times do we have to rewrite make in nodeJS?
  - flukus 10y ago
    > JS is still very "wild-west" because the community is still making rapid progress towards an ideal environment. Most of the churn seems to come from people reinventing the wheel over and over again.
    - ng12 10y ago
      Could you elaborate? I hear that a lot but I suspect it only comes from people who don't do a lot of web development.
      - flukus 10y ago
        Look at the number of binding/UI frameworks, look at the package managers, look at the number of unit test libraries, look at the number of build tools. Many get reinvented in a bubble when there are plenty of options already. Now half (maybe more) of the libraries are being written in languages that aren't javascript so now there are multiple competing ecosystems on top of javascript. And then you have things like angular creating churn within the framework.
        ng12 10y ago
        So the argument is essentially "there's a lot of stuff I don't really understand, a lot of it must be redundant"? React isn't just Angular with a different name -- they have fundamentally different views on how web development should be done. They also fit different use cases (Angular is a one-stop-shop, React is minimalist by design). Same thing with the build systems. Add in the fact that a lot of this wasn't possible until recently (i.e. Webpack is fundamentally enabled by ES6-style imports) and of course things are going to change rapidly. > Now half (maybe more) of the libraries are being written in languages that aren't javascript so now there are multiple competing ecosystems on top of javascript. I'm not sure what you mean by this. Elm-html is the only example I can think of that is non-Javascript. If you're referring to Angular2 being Typescript you can still use it just fine with regular JS.
        flukus 10y ago
- gotofritz 10y ago
  As a insider to FE development, I'm tired of hearing comments about JS fatigue and all the rest. FE development is made of many moving parts and standards managed by different players. JS, for example, has to work on a variety of browsers, from obsolete to bleeding edge, from desktop to game consoles to mobile phones. Imagine if you had to write SQL that needs to run on ALL versions of ALL major databases, paired with code that needs to run on every possible JVM. It's unavoidable that it be like that. I'd rather have that than going back to the days of Flash where everything was closed source and in Macromedia's (or even worse, Adobe's) hands. If it's not your thing, just keep clear of it (I don't mean OP specifically)
  - xwowsersx 10y ago
    > It's unavoidable that it'd be like that. Why is that? > If it's not your thing, just keep clear of it. I don't currently do FE development, but like to keep abreast of changes. Why can't I make an observation about the apparent state of the ecosystem? Also, I didn't mention anything about fatigue. You're projecting that.
    - gotofritz 10y ago
      > If it's not your thing, just keep clear of it. It wasn't directed specifically at you, it just read better than "if it's not ONE's thing, ..." > Also, I didn't mention anything about fatigue. You're projecting that. I didn't say you mentioned it. It is a common complaint and one I have seen far too often (here on HN a popular article on the subject was posted and reposted almost daily for a couple of weeks), so I made an observation which was spurred by your comment.
    - gotofritz 10y ago
      >> It's unavoidable that it'd be like that. >Why is that? Because everything is open source and developed by different players at their own pace, and nobody can force anyone to do things a certain way. Plus everything evolves very quickly. Right now, for example, we need Babel because we are in the middle of transitioning from ES5 to ES6. Unlike, say, Python, we can't just take 6 years or more for that process.
- chowes 10y ago
  Babel is doing a great service at making such complexities painless from a user's perspective.
  - ad-hominem 10y ago
    I thought hacker news was not the place for joke comments¿
  - Ajedi32 10y ago
    Indeed. `babel-preset-env` in particular looks pretty amazing. Just tell it what browsers you want to support and it'll automatically apply whatever transformations are needed to target those versions? Yes, please!
- acemarke 10y ago
  There was a recent Reddit thread entitled "Modern JS dev workflow makes me sad" ([0]). The complaint was reasonably well-written, and I wrote a lengthy response in return ([1]). I'll quote part of my comment here: > Another thing to keep in mind is that those tools constitute an entire compiler toolchain. If I was trying to compile, say, a Qt application on a Linux system, half of the headers and libraries would have been preinstalled on the system, as well as GCC. The Qt develop package may or may not be preinstalled, but would also constitute a pretty hefty chunk of dependencies. With Javascript, you're basically pulling down an entire compiler+linker+libraries chain for each project, which is both good and bad. I also gave a presentation a couple months ago that gives an overview of what some of these tools are and what problems they're trying to solve ([2]), and my React/Redux links list ([3]) has links to a number of other similar overview articles that can help clarify why these tools exist ([4]). [0]: https://www.reddit.com/r/javascript/comments/5fphiw/modern_js_developer_workflow_makes_me_sad/ https://www.reddit.com/r/javascript/comments/5fphiw/modern_j... [1]: https://www.reddit.com/r/javascript/comments/5fphiw/modern_js_developer_workflow_makes_me_sad/dam6cwh/ https://www.reddit.com/r/javascript/comments/5fphiw/modern_j... [2]: http://blog.isquaredsoftware.com/2016/10/presentation-modern-web-dev-overview/ http://blog.isquaredsoftware.com/2016/10/presentation-modern... [3]: https://github.com/markerikson/react-redux-links https://github.com/markerikson/react-redux-links [4]: https://github.com/markerikson/react-redux-links/blob/master/basic-concepts.md https://github.com/markerikson/react-redux-links/blob/master...
  - xwowsersx 10y ago
    Thanks for the link to your presentation. Very interesting to see the history in one place. I'm not totally clear on the primary cause of the mess once we get to npm, bower, grunt, etc. Is the main issue the shortcomings of JS itself or something else..?
    - acemarke 10y ago
      I'll go ahead and quote the most relevant slides from my presentation: > Javascript/Client Challenges: > - No built-in module definition system > - No encapsulation > - Prototypal-based inheritance system unlike most languages > - No static type declarations or compilation > - Dynamically modified objects and data > - Minimal standard library > - Variations in browser capabilities > - Document layout model repurposed for application layouts > Javascript/Client Dev Goals > - Minimize bytes sent over the wire > - Handle browser compatibility issues > - Fill in gaps in JS standard library and language spec > - Reuse and share code between apps > - Build increasingly complex full-blown applications that just happen to live inside a browser So, it's all those aspects together. People want to use the latest syntax, patch holes in the language, standardize behavior, share code, and run full-blown compilation pipelines that parse, transform, link, and optimize, and use all that to build complex applications. That's a completely different world than just using jQuery to toggle some divs. In addition, these pieces have really only come together in the last 6 years or so. The C ecosystem has been around since the late 70s, Java is over 20 years old, and so on. Those ecosystems have had time to build out tools and conventions, and the underlying platforms have been more stable as well. In the front-end world, browsers and runtime capabilities are constantly changing, and as people are pushing the limits of the language and ecosystem, others are inspired by those ideas. So, there's a lot of catch-up and iteration going on. I'm not going to say that it's easy to keep up with or that everything about these changes is perfect and wonderful. That said, I _do_ think that the rate of change is slowing down somewhat, and that the situation is stabilizing. I think the last year and a half of "Javascript Fatigue" complaints have also raised awareness of the churn, and that there's a big emphasis on improving developer experience going on right now. For example, the Webpack team has made a huge effort to rewrite their docs from scratch ([0]), and there's several utilities out there that try to make it easier to write Webpack configs without having to fiddle with every last option yourself ([1], [2]). There's also tools like Create-React-App ([3}), which try to encapsulate the entire build tool process for you ([4]). So, yeah - everyone's still trying to sort things out a bit, but ultimately the tools and technologies now available are letting people do a lot of things they couldn't do before. [0] https://webpack.js.org/ https://webpack.js.org/ [1] https://github.com/andywer/webpack-blocks https://github.com/andywer/webpack-blocks [2] https://github.com/webpack-flow/webpack-flow https://github.com/webpack-flow/webpack-flow [3] https://github.com/facebookincubator/create-react-app https://github.com/facebookincubator/create-react-app [4] https://www.reddit.com/r/reactjs/comments/5gt2c4/you_dont_need_a_boilerplate/davn6e8/?context=1 https://www.reddit.com/r/reactjs/comments/5gt2c4/you_dont_ne...
- kylec 10y ago
  This is a point that is brought up a lot, and I'm happy that our community is having these discussions, but I don't think that this is the best place to bring it up again. This post is intended to convey a lot of technical, inside information about this tool to people who are already using it. If you don't know where to begin with Babel, this is not a good resource. Also, constant negative feedback discourages the creators and maintainers of projects like this from continuing to work on them: https://medium.com/@thejameskyle/dear-javascript-7e14ffcae36c https://medium.com/@thejameskyle/dear-javascript-7e14ffcae36...
  - ggregoire 10y ago
    By the way, it's absolutely painless to setup Babel. To use ES6/ES7/ES8 (e.g. async/await), it's just: npm install --save-dev babel-cli babel-preset-latest And then in the package.json: "scripts": { "build": "babel src -d dist --presets latest" }
    - bostonvaulter2 10y ago
      That's definitely not the impression given by the setup page: http://babeljs.io/docs/setup/ http://babeljs.io/docs/setup/ I'm an experienced front-end developer and I must say that that list is intimidating.
      - shriek 10y ago
        You really don't have to use all of them of course. Pick one and that should be good for the environment that's specified there.
    - bostonvaulter2 10y ago
      That's definitely not the impression given by the setup page: http://babeljs.io/docs/setup/ http://babeljs.io/docs/setup/ I'm an experienced front-end developer and I must say that that list is intimidating.
    - zodiac 10y ago
      To be fair that assumes you have node and npm set up properly, including making them upgradable, making sure node_modules is in PATH, etc. I think it's easy to forget "obvious" knowledge like this that (for me at least) had to be figured out with some trial and error.
- flukus 10y ago
  From the babel web page: > Babel transforms your JavaScript, You put JavaScript in, And get JavaScript out That says all you need to know about the javascript ecosystem.
  - pitaj 10y ago
    What? That it has a huge focus on backwards compatibility because it can't just rely on having the correct language version installed?
    - flukus 10y ago
      You can rely on having the correct version installed. This is an unwillingness to accept that it's not the version you want. You work out the minimum requirements and write to that, you don't start out with the latest and greatest and work backwards.
      - gotofritz 10y ago
        That's not the way FE works. You want to focus on the latest browser APIs as possible, to build more complex interfaces more efficiently. For the unlucky ones stuck on old browsers, you provide a fall back. Luckily modern browsers all auto-update, it's just those stuck with IE10 you need to worry about.
        coldtea 10y ago
        >That's not the way FE works. FE having a specific way of working, doesn't preclude that way being broken.
        gotofritz 10y ago
        Only if you insist on judging it with BE criteria
        coldtea 10y ago
- deleted 10y ago
  [deleted]
Ajedi32 10y ago
Codemods support with Recast looks really impressive. I wonder how hard it'd be to use that to write a `gofmt` for JavaScript.
- hzoo 10y ago
  I know jlongster started https://github.com/jlongster/jscodefmt https://github.com/jlongster/jscodefmt https://twitter.com/jlongster/status/804888882408026113 https://twitter.com/jlongster/status/804888882408026113 which uses recast/babylon
ggregoire 10y ago
Good occasion to thanks all the people who have been working on Babel. Among other things, Babel allows me to use ES6/ES7/ES8 (e.g. async/await), to write my components in JSX and to type my code with Flow. It would be so painful to work without Babel. Thanks guys!
- andreasklinger 10y ago
  +1 babel completely changed my pov on javascript
  - karmajunkie 10y ago
    Ditto... still not my favorite but now I use es6 and friends preferentially to a few other options that would have won out before.
- inglor 10y ago
  For what it's worth, the TypeScript compiler can do all that for you and in my experience is giving me more informative warnings. Babel is great, I think returning the issues to GH is a big win.
maaaats 10y ago
Interesting points. Good ideas for features I would like, and laid out in a way that makes me want to contribute.
- hzoo 10y ago
  Awesome! What's one of them? Hope to see you around then!
brentm 10y ago
I just want to say these people do amazing work. It's truly been a pleasure to work with JS in 2016. Thank you to everyone working on Babel and the countless other great OSS projects. One of my goals for 2017 is to find a way to get involved.
atomical 10y ago
Is this where CoffeeScript left off? How would you compare it to CoffeeScript?
- hyperdunc 10y ago
  There are many differences. One is that CoffeeScript will always need to be compiled. Code written in, e.g. ES7, will not have to be compiled down with Babel anymore once browsers in the wild all support ES7. Also, AFAIK CoffeeScript restricts you to using JS features found in ES5.
  - spraak 10y ago
    CoffeeScript is most similar to ES6 but with some slight differences in syntax and style
  - 6t6t6t6 10y ago
    I have the intuition that the plans of the developers of the future version of JS are that you will always have to transpille the code. https://youtu.be/3pKNRgResq0 https://youtu.be/3pKNRgResq0 On the other hand, I think that the time of CoffeeScript has passed. It made some sense before Babel but now, IMHO, it is only for Ruby developers who don't like the syntax of JavaScript.
    - douche 10y ago
      At this point, JavaScript is inching closer and closer to just being assembly language for the web. I think things will get very interesting indeed once WebAssembly really starts to be a real thing.
      - 6t6t6t6 10y ago
        And this day maybe we will not need JavaScript anymore... ;)
        seanparsons 10y ago
wmichelin 10y ago
> 6to5 did exactly that: easily turn ES6 code into ES5 codee
- hzoo 10y ago
  Haha fixed - or it can be a joke on the output being larger.
hzoo 10y ago
Author here, if anyone had questions or wanted to know more about how to help out! Personally, I'm most excited about babel-preset-env, and fixing how we work with the TC39 process via experimental plugins, and working with the community more. For anyone wanting to get started in OSS or Babel I just started a year ago from knowing nothing about it!
bradleyprice 10y ago
I second (third?) the fact that I'm so thankful for these packages and contributors. Reading this article puts into perspective the amount of alignment within the community that it takes to be able to depend on external libraries to make our day-to-day easier. It's very humbling. I'm just here standing on the shoulders of giants.
rattray 10y ago
Not only is Babel great as a tool for transpiling JavaScript, I've found the plugin system to be splendid for building a compile-to-JS language as well. The tools are terrific to work with.
SimonSelg 10y ago
Thanks to everyone working on these tools! They improve the DX sooo much!

The State of Babel

241 points by BenjaminCoe 10y ago

xwowsersx 10y ago

As an outsider to FE development, when I see posts like this, I just shudder at the complexity of the ecosystem.

ng12 10y ago
It's no worse than any other ecosystem. Modern Java development is just as prickly -- the only difference is the complexity is more established. JS is still very "wild-west" because the community is still making rapid progress towards an ideal environment.
- xwowsersx 10y ago
  You may be right, but I'm not sure I totally agree. Maybe this is exactly what you meant, but I think the complexities are different. Java is inherently complex, I'll give you that, but in JS and FE development in general, it seems like the most basic building blocks are constantly being reinvented...large, open questions on basic stuff.
  - vcarl 10y ago
    > large, open questions on basic stuff. I've commented on this subject before[0], I think the past few years of web development has largely been about answering basic questions. Now there are well tested answers to those questions. I'm sure people will still reinvent these wheels, but now you don't have to when working on a large project. Babel, Webpack et al are more useful when you're building a web-app, something generally comparable to a native app. The toolchain is complex, sure, but no more complex than what xcode or Android Studio do for you. I think the difference is that this has been a community effort, rather than a corporation assembling a product, so a) there are more people sharing opinions and b) the disagreements and exploration has been more public. [0] https://news.ycombinator.com/item?id=12828042 https://news.ycombinator.com/item?id=12828042
  - seangrogg 10y ago
    The issues with FE are twofold: browser incompatibilities and user expectations. The first is becoming easier over time (stop using IE, please). The second is an ongoing arms race. Writing front end code is like writing a CLI. It starts off really easy - you have a use case (whether that's a page about your cat or a script that echoes "meow"), you solve for it, you show it off. But then people ask for it to do other things. So you have to extend the code - perhaps we need to add flags so users see dog stuff instead of cat stuff. Oh, now users want an actual ascii animal to see so we cater to that. Now they want to name it so let's accept input somehow. They want to issue commands to it so let's deal with parsing and conditional branches. The problem is that we have to deal with constant changes from browsers, from stakeholders, and from users. Stakeholders want certain features from our programs, users expect a certain standard of performance, and browsers hamper us with incompatibilities. So we build libraries that solve some of these problems. jQuery helped us build websites, but then web apps became a thing. Backbone/Ember/Angular helped us build web decent web-apps, but then performance became a thing. React/Angular2/Ember2/Vue help us build performant applications... until the next thing. I think the real problem are the choices people opt-in to. I use React and don't have JavaScript fatigue - but I've also chosen not to use JSX, Babel, Webpack, SSR, live reloading, linting, typing, automated deployment, trello, TravisCI, Docker, k8s, etc. Just libraries imported with script tags, writing ES5 (current standard, 100% implementation), using React.createElement and I've had no issues. People may opt-in to reinvention and questioning basics, but there are plenty of individuals that get by just fine.
- deleted 10y ago
  [deleted]
- mhd 10y ago
  Java and C++ always end up as the baselines for comparisons, besides both not being exactly being the poster boys of their respective fields. Just because C++ compiles even slower or a non-standard Maven setup is more inscrutable doesn't exactly praise the alternative. We should stop being so content with not being/using the worst.
- ern 10y ago
  I disagree that the constant churn in FE/JS is necessarily a sign of "rapid progress", rather than a lack of strong stewardship/leadership leading to people reinventing the wheel. I haven't worked with Java for a long time, but from what I've been hearing from colleagues who are exploring writing production software with it, .NET Core is currently a bit of a mess, showing that even coherent dev stories can easily slip into disorder.
  - ng12 10y ago
    > a lack of strong stewardship/leadership leading to people reinventing the wheel There's lots of strong leadership. React, Angular, Vue, Ember, etc. all have very intelligent, hard-working people backing them. These frameworks aren't "reinventing the wheel", it's the complete opposite: the community has finally freed itself of jQuery/global scope/imperative DOM and these frameworks are all pushing the border in one way or another.
  - gotofritz 10y ago
    > I disagree that the constant churn in FE/JS is necessarily a sign of "rapid progress", It's the field that is progressing rapidly. Browsers are constantly adding new APIs, problems are being solved, etc. The difference is that it's open source > a lack of strong stewardship/leadership You can't have leadership in a field which has no owner. It's not like Oracle owning Java and deciding what happens with it. > people reinventing the wheel. This is a stereotype by people who don't really know the subject. Every new tool improves on the previous one. For example, grunt was the first JS build tool, it had some issues (huge configurations, and speed) some someone invented gulp, which uses streams for speed and code instead of configuration. But streams don't handle splitting files in bundles and other problems so well, so webpack was invented. There are overlaps but they all solve different problems, and all improve on the previous generation. They are not "reinventing the wheel"
    - douche 10y ago
      How many times do we have to rewrite make in nodeJS?
- flukus 10y ago
  > JS is still very "wild-west" because the community is still making rapid progress towards an ideal environment. Most of the churn seems to come from people reinventing the wheel over and over again.
  - ng12 10y ago
    Could you elaborate? I hear that a lot but I suspect it only comes from people who don't do a lot of web development.
    - flukus 10y ago
      Look at the number of binding/UI frameworks, look at the package managers, look at the number of unit test libraries, look at the number of build tools. Many get reinvented in a bubble when there are plenty of options already. Now half (maybe more) of the libraries are being written in languages that aren't javascript so now there are multiple competing ecosystems on top of javascript. And then you have things like angular creating churn within the framework.
      - ng12 10y ago
        So the argument is essentially "there's a lot of stuff I don't really understand, a lot of it must be redundant"? React isn't just Angular with a different name -- they have fundamentally different views on how web development should be done. They also fit different use cases (Angular is a one-stop-shop, React is minimalist by design). Same thing with the build systems. Add in the fact that a lot of this wasn't possible until recently (i.e. Webpack is fundamentally enabled by ES6-style imports) and of course things are going to change rapidly. > Now half (maybe more) of the libraries are being written in languages that aren't javascript so now there are multiple competing ecosystems on top of javascript. I'm not sure what you mean by this. Elm-html is the only example I can think of that is non-Javascript. If you're referring to Angular2 being Typescript you can still use it just fine with regular JS.
        flukus 10y ago
gotofritz 10y ago
As a insider to FE development, I'm tired of hearing comments about JS fatigue and all the rest. FE development is made of many moving parts and standards managed by different players. JS, for example, has to work on a variety of browsers, from obsolete to bleeding edge, from desktop to game consoles to mobile phones. Imagine if you had to write SQL that needs to run on ALL versions of ALL major databases, paired with code that needs to run on every possible JVM. It's unavoidable that it be like that. I'd rather have that than going back to the days of Flash where everything was closed source and in Macromedia's (or even worse, Adobe's) hands. If it's not your thing, just keep clear of it (I don't mean OP specifically)
- xwowsersx 10y ago
  > It's unavoidable that it'd be like that. Why is that? > If it's not your thing, just keep clear of it. I don't currently do FE development, but like to keep abreast of changes. Why can't I make an observation about the apparent state of the ecosystem? Also, I didn't mention anything about fatigue. You're projecting that.
  - gotofritz 10y ago
    > If it's not your thing, just keep clear of it. It wasn't directed specifically at you, it just read better than "if it's not ONE's thing, ..." > Also, I didn't mention anything about fatigue. You're projecting that. I didn't say you mentioned it. It is a common complaint and one I have seen far too often (here on HN a popular article on the subject was posted and reposted almost daily for a couple of weeks), so I made an observation which was spurred by your comment.
  - gotofritz 10y ago
    >> It's unavoidable that it'd be like that. >Why is that? Because everything is open source and developed by different players at their own pace, and nobody can force anyone to do things a certain way. Plus everything evolves very quickly. Right now, for example, we need Babel because we are in the middle of transitioning from ES5 to ES6. Unlike, say, Python, we can't just take 6 years or more for that process.
chowes 10y ago
Babel is doing a great service at making such complexities painless from a user's perspective.
- ad-hominem 10y ago
  I thought hacker news was not the place for joke comments¿
- Ajedi32 10y ago
  Indeed. `babel-preset-env` in particular looks pretty amazing. Just tell it what browsers you want to support and it'll automatically apply whatever transformations are needed to target those versions? Yes, please!
acemarke 10y ago
There was a recent Reddit thread entitled "Modern JS dev workflow makes me sad" ([0]). The complaint was reasonably well-written, and I wrote a lengthy response in return ([1]). I'll quote part of my comment here: > Another thing to keep in mind is that those tools constitute an entire compiler toolchain. If I was trying to compile, say, a Qt application on a Linux system, half of the headers and libraries would have been preinstalled on the system, as well as GCC. The Qt develop package may or may not be preinstalled, but would also constitute a pretty hefty chunk of dependencies. With Javascript, you're basically pulling down an entire compiler+linker+libraries chain for each project, which is both good and bad. I also gave a presentation a couple months ago that gives an overview of what some of these tools are and what problems they're trying to solve ([2]), and my React/Redux links list ([3]) has links to a number of other similar overview articles that can help clarify why these tools exist ([4]). [0]: https://www.reddit.com/r/javascript/comments/5fphiw/modern_js_developer_workflow_makes_me_sad/ https://www.reddit.com/r/javascript/comments/5fphiw/modern_j... [1]: https://www.reddit.com/r/javascript/comments/5fphiw/modern_js_developer_workflow_makes_me_sad/dam6cwh/ https://www.reddit.com/r/javascript/comments/5fphiw/modern_j... [2]: http://blog.isquaredsoftware.com/2016/10/presentation-modern-web-dev-overview/ http://blog.isquaredsoftware.com/2016/10/presentation-modern... [3]: https://github.com/markerikson/react-redux-links https://github.com/markerikson/react-redux-links [4]: https://github.com/markerikson/react-redux-links/blob/master/basic-concepts.md https://github.com/markerikson/react-redux-links/blob/master...
- xwowsersx 10y ago
  Thanks for the link to your presentation. Very interesting to see the history in one place. I'm not totally clear on the primary cause of the mess once we get to npm, bower, grunt, etc. Is the main issue the shortcomings of JS itself or something else..?
  - acemarke 10y ago
    I'll go ahead and quote the most relevant slides from my presentation: > Javascript/Client Challenges: > - No built-in module definition system > - No encapsulation > - Prototypal-based inheritance system unlike most languages > - No static type declarations or compilation > - Dynamically modified objects and data > - Minimal standard library > - Variations in browser capabilities > - Document layout model repurposed for application layouts > Javascript/Client Dev Goals > - Minimize bytes sent over the wire > - Handle browser compatibility issues > - Fill in gaps in JS standard library and language spec > - Reuse and share code between apps > - Build increasingly complex full-blown applications that just happen to live inside a browser So, it's all those aspects together. People want to use the latest syntax, patch holes in the language, standardize behavior, share code, and run full-blown compilation pipelines that parse, transform, link, and optimize, and use all that to build complex applications. That's a completely different world than just using jQuery to toggle some divs. In addition, these pieces have really only come together in the last 6 years or so. The C ecosystem has been around since the late 70s, Java is over 20 years old, and so on. Those ecosystems have had time to build out tools and conventions, and the underlying platforms have been more stable as well. In the front-end world, browsers and runtime capabilities are constantly changing, and as people are pushing the limits of the language and ecosystem, others are inspired by those ideas. So, there's a lot of catch-up and iteration going on. I'm not going to say that it's easy to keep up with or that everything about these changes is perfect and wonderful. That said, I _do_ think that the rate of change is slowing down somewhat, and that the situation is stabilizing. I think the last year and a half of "Javascript Fatigue" complaints have also raised awareness of the churn, and that there's a big emphasis on improving developer experience going on right now. For example, the Webpack team has made a huge effort to rewrite their docs from scratch ([0]), and there's several utilities out there that try to make it easier to write Webpack configs without having to fiddle with every last option yourself ([1], [2]). There's also tools like Create-React-App ([3}), which try to encapsulate the entire build tool process for you ([4]). So, yeah - everyone's still trying to sort things out a bit, but ultimately the tools and technologies now available are letting people do a lot of things they couldn't do before. [0] https://webpack.js.org/ https://webpack.js.org/ [1] https://github.com/andywer/webpack-blocks https://github.com/andywer/webpack-blocks [2] https://github.com/webpack-flow/webpack-flow https://github.com/webpack-flow/webpack-flow [3] https://github.com/facebookincubator/create-react-app https://github.com/facebookincubator/create-react-app [4] https://www.reddit.com/r/reactjs/comments/5gt2c4/you_dont_need_a_boilerplate/davn6e8/?context=1 https://www.reddit.com/r/reactjs/comments/5gt2c4/you_dont_ne...
kylec 10y ago
This is a point that is brought up a lot, and I'm happy that our community is having these discussions, but I don't think that this is the best place to bring it up again. This post is intended to convey a lot of technical, inside information about this tool to people who are already using it. If you don't know where to begin with Babel, this is not a good resource. Also, constant negative feedback discourages the creators and maintainers of projects like this from continuing to work on them: https://medium.com/@thejameskyle/dear-javascript-7e14ffcae36c https://medium.com/@thejameskyle/dear-javascript-7e14ffcae36...
- ggregoire 10y ago
  By the way, it's absolutely painless to setup Babel. To use ES6/ES7/ES8 (e.g. async/await), it's just: npm install --save-dev babel-cli babel-preset-latest And then in the package.json: "scripts": { "build": "babel src -d dist --presets latest" }
  - bostonvaulter2 10y ago
    That's definitely not the impression given by the setup page: http://babeljs.io/docs/setup/ http://babeljs.io/docs/setup/ I'm an experienced front-end developer and I must say that that list is intimidating.
    - shriek 10y ago
      You really don't have to use all of them of course. Pick one and that should be good for the environment that's specified there.
  - bostonvaulter2 10y ago
    That's definitely not the impression given by the setup page: http://babeljs.io/docs/setup/ http://babeljs.io/docs/setup/ I'm an experienced front-end developer and I must say that that list is intimidating.
  - zodiac 10y ago
    To be fair that assumes you have node and npm set up properly, including making them upgradable, making sure node_modules is in PATH, etc. I think it's easy to forget "obvious" knowledge like this that (for me at least) had to be figured out with some trial and error.
flukus 10y ago
From the babel web page: > Babel transforms your JavaScript, You put JavaScript in, And get JavaScript out That says all you need to know about the javascript ecosystem.
- pitaj 10y ago
  What? That it has a huge focus on backwards compatibility because it can't just rely on having the correct language version installed?
  - flukus 10y ago
    You can rely on having the correct version installed. This is an unwillingness to accept that it's not the version you want. You work out the minimum requirements and write to that, you don't start out with the latest and greatest and work backwards.
    - gotofritz 10y ago
      That's not the way FE works. You want to focus on the latest browser APIs as possible, to build more complex interfaces more efficiently. For the unlucky ones stuck on old browsers, you provide a fall back. Luckily modern browsers all auto-update, it's just those stuck with IE10 you need to worry about.
      - coldtea 10y ago
        >That's not the way FE works. FE having a specific way of working, doesn't preclude that way being broken.
        gotofritz 10y ago
        Only if you insist on judging it with BE criteria
        coldtea 10y ago
deleted 10y ago
[deleted]

Ajedi32 10y ago

Codemods support with Recast looks really impressive. I wonder how hard it'd be to use that to write a `gofmt` for JavaScript.

hzoo 10y ago
I know jlongster started https://github.com/jlongster/jscodefmt https://github.com/jlongster/jscodefmt https://twitter.com/jlongster/status/804888882408026113 https://twitter.com/jlongster/status/804888882408026113 which uses recast/babylon

ggregoire 10y ago

Good occasion to thanks all the people who have been working on Babel. Among other things, Babel allows me to use ES6/ES7/ES8 (e.g. async/await), to write my components in JSX and to type my code with Flow. It would be so painful to work without Babel. Thanks guys!

andreasklinger 10y ago
+1 babel completely changed my pov on javascript
- karmajunkie 10y ago
  Ditto... still not my favorite but now I use es6 and friends preferentially to a few other options that would have won out before.
inglor 10y ago
For what it's worth, the TypeScript compiler can do all that for you and in my experience is giving me more informative warnings. Babel is great, I think returning the issues to GH is a big win.

maaaats 10y ago

Interesting points. Good ideas for features I would like, and laid out in a way that makes me want to contribute.

hzoo 10y ago
Awesome! What's one of them? Hope to see you around then!

brentm 10y ago

I just want to say these people do amazing work. It's truly been a pleasure to work with JS in 2016. Thank you to everyone working on Babel and the countless other great OSS projects. One of my goals for 2017 is to find a way to get involved.

atomical 10y ago

Is this where CoffeeScript left off? How would you compare it to CoffeeScript?

hyperdunc 10y ago
There are many differences. One is that CoffeeScript will always need to be compiled. Code written in, e.g. ES7, will not have to be compiled down with Babel anymore once browsers in the wild all support ES7. Also, AFAIK CoffeeScript restricts you to using JS features found in ES5.
- spraak 10y ago
  CoffeeScript is most similar to ES6 but with some slight differences in syntax and style
- 6t6t6t6 10y ago
  I have the intuition that the plans of the developers of the future version of JS are that you will always have to transpille the code. https://youtu.be/3pKNRgResq0 https://youtu.be/3pKNRgResq0 On the other hand, I think that the time of CoffeeScript has passed. It made some sense before Babel but now, IMHO, it is only for Ruby developers who don't like the syntax of JavaScript.
  - douche 10y ago
    At this point, JavaScript is inching closer and closer to just being assembly language for the web. I think things will get very interesting indeed once WebAssembly really starts to be a real thing.
    - 6t6t6t6 10y ago
      And this day maybe we will not need JavaScript anymore... ;)
      - seanparsons 10y ago

wmichelin 10y ago

> 6to5 did exactly that: easily turn ES6 code into ES5 codee

hzoo 10y ago
Haha fixed - or it can be a joke on the output being larger.

hzoo 10y ago

Author here, if anyone had questions or wanted to know more about how to help out! Personally, I'm most excited about babel-preset-env, and fixing how we work with the TC39 process via experimental plugins, and working with the community more. For anyone wanting to get started in OSS or Babel I just started a year ago from knowing nothing about it!

bradleyprice 10y ago

I second (third?) the fact that I'm so thankful for these packages and contributors. Reading this article puts into perspective the amount of alignment within the community that it takes to be able to depend on external libraries to make our day-to-day easier. It's very humbling. I'm just here standing on the shoulders of giants.

rattray 10y ago

Not only is Babel great as a tool for transpiling JavaScript, I've found the plugin system to be splendid for building a compile-to-JS language as well. The tools are terrific to work with.

SimonSelg 10y ago

Thanks to everyone working on these tools! They improve the DX sooo much!