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

11–20 of 109 posts

Re: The State of Babel

#11

Post by xwowsersx »

gotofritz wrote: post #10
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.

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

I hear what you're saying kinda. It sort of comes with the territory since the web is a completely open platform, not a controlled/contained ecosystem like Java or even an open-source language like Python.

Re: The State of Babel

#12

Post by [deleted] »

ng12 wrote: post #3
xwowsersx wrote: post #2

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

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.

[deleted]

Re: The State of Babel

#13

Post by dominotw »

xwowsersx wrote: post #8
gotofritz wrote: post #4

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…

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

Re: The State of Babel

#14

Post by xwowsersx »

acemarke wrote: post #7
xwowsersx wrote: post #2

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

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…

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

Re: The State of Babel

#15

Post by ad-hominem »

chowes wrote: post #6
xwowsersx wrote: post #2

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

Babel is doing a great service at making such complexities painless from a user's perspective.

I thought hacker news was not the place for joke comments¿

Re: The State of Babel

#18

Post by mhd »

ng12 wrote: post #3
xwowsersx wrote: post #2

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

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.

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.

Re: The State of Babel

#19

Post by Ajedi32 »

chowes wrote: post #6
xwowsersx wrote: post #2

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

Babel is doing a great service at making such complexities painless from a user's perspective.

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!

Re: The State of Babel

#20

Post by acemarke »

xwowsersx wrote: post #14
acemarke wrote: post #7

Earlier quoted context omitted.

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…

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

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/

[1] https://github.com/andywer/webpack-blocks

[2] https://github.com/webpack-flow/webpack-flow

[3] https://github.com/facebookincubator/create-react-app

[4] https://www.reddit.com/r/reactjs/comments/5gt2c4/you_dont_ne...

Post reply on HN