Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of Babel

babeljs.io

Post reply on HN
Print view View original

71–80 of 109 posts

Re: The State of Babel

#71

Post by Klathmon »

zodiac wrote: post #66
ggregoire wrote: post #27

Earlier quoted context omitted.

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" }

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.

But npm comes with node, so it's just installing the language at that point. And you don't need `node_modules` in the PATH, npm-run scripts will search the local node_modules first before hitting the path.

But I do agree with your point. The "bootstrapping" process of getting started in a new ecosystem is always extremely exhausting. When i was first learning python, it took me 2 solid weeks of an hour or so a night to build my first package. From getting the right version installed, having to eventually compile it myself, getting pip installed, accidentally using setuptools directly, learning about virtualenvironments, trashing everything and starting over with a venv, getting told by people on stack-overflow that I shouldn't try messing with packages at all as I don't need them and should just install from git, etc...

And just recently I did something similar while revisiting an older PHP codebase. I realized that just getting it in a position where I could run it on the dev machine meant installing a database, language, server, setting up a web root, a shitton of apache config files, and more just to get to a point where I could print hello-world.

That part always sucks, and to be completely honest node-js was the one that sucked the least to me when I first started in that world. At least for windows, it was "download this MSI installer and run it, and now you can npm install stuff". It might be different on other platforms, but it was definitely a breath of fresh air there.

Re: The State of Babel

#72

Post by jonny_eh »

dominotw wrote: post #13
xwowsersx wrote: post #8

Earlier quoted context omitted.

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

>Why is that? Different browser vendors with different motivations, vision and priorities as to what a web browser should do. As simple as that.

Not to mention old browsers and the companies/users that don't upgrade them.

Re: The State of Babel

#73

Post by pselbert »

atomical wrote: post #33

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

Many of the great features of modern js (destructuring, fat arrows, splats) came directly from CoffeeScript. As much as I loved the comparative power of CoffeeScript (list comprehensions, everything is an expression), its time has past. There is very little active development and it has lost all momentum. It also never started addressing the biggest issue facing large JS projects, typing and static analysis. Refactoring a CS project is a fragile process that I won't miss.

Re: The State of Babel

#74

Post by bradleyprice »

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.

Re: The State of Babel

#77

Post by 6t6t6t6 »

douche wrote: post #70
6t6t6t6 wrote: post #64

Earlier quoted context omitted.

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

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.

And this day maybe we will not need JavaScript anymore... ;)

Re: The State of Babel

#78

Post by flukus »

Klathmon wrote: post #69
flukus wrote: post #61

Earlier quoted context omitted.

Sure react and angular are different, what about the dozens of others? I posted elsewhere the number of crappy make clones alone: https://www.npmjs.com/search?q=make+build

For starters, why is that a problem? You aren't forced to use them all, you aren't forced to use any of them. But secondly, what makes them crappy? I've used make, and IMO it's pretty crappy itself. Have you had to maintain a recursive makefile? It's a complete nightmare to say the least. And i'm far from the only one to think make is worthy of a "remake". In fact even in just the C/C++ world there is cmake, qmake, a…

> For starters, why is that a problem? You aren't forced to use them all, you aren't forced to use any of them.

It's a problem because every time I need $tool I might have to evaluate dozens of choices, check for compatibility, investigate the ones that suit, hope to god the rest of the community is familiar with it, hope it is supported in future, etc. And then with the rate of churn you might have to do the same in a year. Make has been supported for 30 years, I know it's not going anywhere.

> In fact even in just the C/C++ world there is cmake, qmake, autotools, scons, ninja, bazel, premake, waf, shake, tup, etc...

So there's already dozens of tools, why reinvent them in javascript? Every ecosystem does this but it least most seem to settle on one or two tools, this doesn't seem to be happening in the javascript world.

Re: The State of Babel

#79

Post by Klathmon »

flukus wrote: post #78
Klathmon wrote: post #69

Earlier quoted context omitted.

For starters, why is that a problem? You aren't forced to use them all, you aren't forced to use any of them. But secondly, what makes them crappy? I've used make, and IMO it's pretty crappy itself. Have you had to maintain a recursive makefile? It's a complete nightmare to say the least. And i'm far from the only one to think make is worthy of a "remake". In fact even in just the C/C++ world there is cmake, qmake, a…

> For starters, why is that a problem? You aren't forced to use them all, you aren't forced to use any of them. It's a problem because every time I need $tool I might have to evaluate dozens of choices, check for compatibility, investigate the ones that suit, hope to god the rest of the community is familiar with it, hope it is supported in future, etc. And then with the rate of churn you might have to do the same in…

Well you don't need to evaluate dozens of choices, a few at most. Hell if you just wanted to go by your search above 2 of the top 3 are the 2 biggest build systems in JavaScript (grunt and gulp), and the other isn't a build system.

Maybe it's me, but I've never looked at a list of tools and thought "this is too many!". The more the merrier IMO, and if they are good then they will rise to the top over time. If you don't want to choose, just pick the most popular and deal with it, it'll feel the same as another platform where there's only one to choose from.

But you could also just use make, it's all about your needs. Do you want your project to still build in a few decades with very little change? Then choose the tools for that. You just making a pet project that just needs to live until the domain expires? Try out something new! Afraid of change? Stick with make!

>Every ecosystem does this but it least most seem to settle on one or two tools, this doesn't seem to be happening in the javascript world.

For the most part JS has settled. When it comes to "stuff like make" it's basically gulp or grunt (or make and friends). Yeah there are other smaller players, but there's also a few dozen Java build tools that you've probably never heard of.

Re: The State of Babel

#80

Post by fnovd »

6t6t6t6 wrote: post #64
hyperdunc wrote: post #42

Earlier quoted context omitted.

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.

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

As a Ruby developer who doesn't like the syntax of JavaScript, Babel and ES6+ have changed my perspective. After the initial hurdle of figuring out what the hell webpack, babel, and npm (now yarn) were doing, I've found Javascript to be outright pleasant to use.
Post reply on HN