Live data from Hacker News

The State of Babel

babeljs.io

101–109 of 109 posts

Re: The State of Babel

#101
post #86

Earlier quoted context omitted.

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…

> Maybe it's me, but I've never looked at a list of tools and thought "this is too many!". There is the problem of diffraction of efforts, and spreading knowledge too thin. You see some of the problems in the way linux distros do packaging - every major distro family has its own packaging system, born from NIH syndrome. The result is less portability of both packages and skills. Some competition is good, but there is…

I disagree with that premise though. Just because I made a package that's in the same realm as make doesn't mean that I could have or would have contributed to make instead.

And there's something to be said about smaller single-purpose tools. Adding a ton of features to something like make to support every possible option isn't a good idea IMO. Sometimes a small opinionated package with a "correct" way to use it is best for some circumstances.

Regardless, I really think that the market will sort itself out. If it's oversaturated then some big players will rise to the top and the rest forgotten. Unlike a Linux distro package manager, anyone can add anything to NPM with zero oversight. It makes the "floor" of quality much lower, but fragmentation isn't that big of a deal as the effort to publish is so low.

Re: The State of Babel

#102
post #77
post #70

Earlier quoted context omitted.

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

Literally can't wait for this.

Re: The State of Babel

#103

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

Ditto... still not my favorite but now I use es6 and friends preferentially to a few other options that would have won out before.

Re: The State of Babel

#104

Earlier quoted context omitted.

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

The criteria you use it to judge it determine whether it's assessed as broken or not. I maintain it is NOT broken; it's your broken-assessing criteria that are wrong.

Re: The State of Babel

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

This is a pretty terrible attitude, and is a sad explanation of the churn in the JS community. FE does not work like this and I really wish some of the less professional crowd would stop keep spouting this sort of nonsense.

You start with the damn requirements and then look at how the application may need to be built.

The latest browser APIs are not useful for 99% of the FE work going on out there. Yes, I know it's more satisfying to pretend that it is important, but it really isn't. Just because you can hook something up to a users webcam, or post annoying browser notifications about the latest cat picture a user uploaded doesn't mean you need to or even should.

FE is not a special snowflake. It's no different from most software development (and yes, other, non-FE developers have to figure out cross platform issues as well). If you want to be taken seriously in software development, then stop with the unprofessional attitude and learn how to do something useful for your users, like Progressive" rel="nofollow">https://en.wikipedia.org/wiki/Progressive_enhancement">Progr... enhancement.

Re: The State of Babel

#107

Earlier quoted context omitted.

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

The criteria you use it to judge it determine whether it's assessed as broken or not. I maintain it is NOT broken; it's your broken-assessing criteria that are wrong.

The broken-assessing criteria cannot be altered willy-nilly based on the domain.

Re: The State of Babel

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

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

It's fine if you keep the good, throw out the bad and make some improvements. But very often the good parts get forgotten, like the roundness.

Re: The State of Babel

#109

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

This is a late reply, but...

Are you sure CoffeeScript has lost momentum? It now supports ES2015 imports and exports, and I've seen quite a bit of work on the 2.0 branch (and various forks where contributors are adding new work before merging back to 2.0) to add support for extending ES2015 classes. It looks like that PR will be merged soon.

Also, how much momentum does it need? The language is complete and usable as it is.

I write this as someone who does lots of professional work in ES2015, and very little in CoffeeScript. But every time I come across CoffeeScript in a project, I find myself admiring how nice it looks, and realizing how ugly ES2015 looks in comparison.

Post reply on HN