Live data from Hacker News

The State of Babel

babeljs.io

31–40 of 109 posts

Re: The State of Babel

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

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.

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.

Re: The State of Babel

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

Re: The State of Babel

#34

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

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…

Someone could really do a service to the community by coming up with a library that smooths out all of those criteria. Maybe call it "jBabel."

Re: The State of Babel

#35

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!

+1

babel completely changed my pov on javascript

Re: The State of Babel

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

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.

Re: The State of Babel

#37
post #36
post #29

Earlier quoted context omitted.

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

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.

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.

Re: The State of Babel

#39
post #30

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

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.

What? That it has a huge focus on backwards compatibility because it can't just rely on having the correct language version installed?

Re: The State of Babel

#40
post #37
post #36

Earlier quoted context omitted.

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.

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

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.

Post reply on HN