Live data from Hacker News

The State of Babel

babeljs.io

91–100 of 109 posts

Re: The State of Babel

#91
post #46

Earlier quoted context omitted.

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.

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.

>That's not the way FE works.

FE having a specific way of working, doesn't preclude that way being broken.

Re: The State of Babel

#92
post #89

Earlier quoted context omitted.

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…

Don't you have to have node_modules in PATH to be able to run `babel ...`?

npm puts node_modules/.bin/ on the PATH when running scripts, or you can just run node_modules/.bin/ if you're not using npm scripts.

Re: The State of Babel

#93
post #30

Earlier quoted context omitted.

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.

I am a Ruby dev so I definitely don't pretend to know, however it does seem wild that something like Babel is even needed. It seems to me that it's like trying to mix Ruby 1.8.7 and 2x in the same project and needing a tool to translate it into 1.9.3. Why not just write in 1.9.3 if that's the required target? I clearly don't know what I'm talking about but what's wrong with actually just writing the JavaScript that B…

If you are required to support legacy browsers (which is just the nature of the beast for certain projects), Babel makes it relatively simple to use a new version of JS that may not be supported by those older browsers. Newer versions of JS come with helpful features that reduce bloat and aid developer experience

Re: The State of Babel

#94

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!

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.

Re: The State of Babel

#95
post #29
post #3

Earlier quoted context omitted.

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.

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

The wheel design of today is far superior to the first wheels invented. Why is reinventing the wheel a bad thing?

Re: The State of Babel

#96

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

Fun fact: Javascript was originally intented to have scheme-inspired syntax, until Sun marketing team decided that it should have Java-like syntax (and name). Luckily the semantics survived. So in a sense CoffeeScript respects more the true origins of "javascript" with its everything-is-expression idiom.

Personally, my strongest dislike with ES6 is its afterthought C-like syntax from 40 years ago. Nowadays, hardware is fast enough so that we don't need redundant {()}; hints for quick parsing, instead we should focus on human readability.

I wish there was an editor plugin which enabled alternative syntax (without dividing the community). Syntax is really a reprentational layer thing, just like color theme, and should be personally customizable.

Re: The State of Babel

#97
post #91

Earlier quoted context omitted.

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.

> That's not the way FE works. FE having a specific way of working, doesn't preclude that way being broken.

Only if you insist on judging it with BE criteria

Re: The State of Babel

#99
post #90

Earlier quoted context omitted.

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 wit…

> 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. Both things are entirely possible -- and much simpler than the current state of FE.

I imagine you would write the "lowest common denominator" SQL which run on all of the database. You can do that with JS too. But then you miss out on all the browsers latest APIs.

Re: The State of Babel

#100
post #91

Earlier quoted context omitted.

> That's not the way FE works. FE having a specific way of working, doesn't preclude that way being broken.

Only if you insist on judging it with BE criteria

I maintain that it holds as a general principle, whether you judge it with BE criteria or not. I basically said this:

"That some field (e.g. FE) has a specific way of working is orthogonal to that way being broken or not".

Otherwise there would never be any brokenness conceivable ever, and everything would be a matter of different ways/conventions.

I don't see why brokenness shouldn't be a possibility in FE or anywhere else though. Sure, I might be wrong, and FE might NOT be broken. But that would not be the case merely because "it has its own way for doing things" -- it would have to be inherently not broken, whereas "has its own way" merely tells us that it's idiomatic.

Post reply on HN