8 ms·

I thought the article started strong and skipped around serious issues so it could focus on a pretty nice history of JS, but the conclusion was horrible. > Bab

I thought the article started strong and skipped around serious issues so it could focus on a pretty nice history of JS, but the conclusion was horrible. > Babel has worked it’s way into the standard Javascript toolchain, and now most builders include it as a first-class plugin Which version of Babel, 5? or 6? Because there's a lot of incompatibility issues right there and I think it is just as symptomatic of the typical JS fatigue issues which aren't really discussed. I'm not as optimistic as the author about the future. The fatigue is real - and the value proposition of having to throw code away every year isn't that great. The JS build toolchain and steps are just plain old insane; and neither durable nor resilient. 4-6 month old code bases become antiquated vs a few years ago when you could expect 4-6 years max. BTW, I'm pretty sure C had the same kind of explosion 30+ years ago... Obj-C started off as a set of macros in the late 80's/early 90's. But it wouldn't be proper JS engineering if a wheel wasn't reinvented along the way.

zdragnar 11y ago
> Which version of Babel, 5? or 6 I'm not really familiar with any popular build toolchain libraries written for 5 that haven't been updated to work with 6. It's not like a Python 2/3 scenario, or even an Angular 1/2.
cptskippy 11y ago
I've stopped using fancy framework or tools and stuck with pure JavaScript, CSS, HTML5 for personal projects and I'm loving it. I know that isn't always possible, especially with legacy applications, but it's incredibly liberating to have full control over a page and not have to dance with shitty partners.
- orvr 11y ago
  Amen
cubano 11y ago
No, I lived the C-explosion of 30 years ago and it was absolutely nothing like what I see these days. It utterly nuts how we are expected a learn a full-stack like Mongo/Angular/Backbone and then 6 months later is like NO we need AWS/React/Redux now! It's my oldman opinion that IT has become too much like fashion and not enough like engineering, but that's what oldmen think so who cares.
- wonnage 11y ago
  You can either shut yourself off from it and cement yourself into "oldman" oblivion, or actually try to understand why these tools exist.
  - LoSboccacc 11y ago
    We old coot understand well why such inane tools exists and it's because there are too many people worrking in a hurry and can't be bothered to look back at sound engineering solution that already exists.
  - manyxcxi 11y ago
    > You can either shut yourself off from it and cement yourself into "oldman" oblivion, or actually try to understand why these tools exist. For other languages/ecosystems I would agree. However, in the JS world there is a lot of stuff that exists simply to exist. There are typically multiple libraries to do the same thing (in general) but with someone else's opinionated take on it. Sometimes I feel like the developer of framework B was having a hard time grokking framework A and just decided to roll their own, like framework A, except for the parts they didn't like or understand. Then someone came along and realized that framework B had gaping security issues and was horrifically slow- so they created framework C which is the more secure and performant opiniated take on framework B that was an opinionated take on framework A. But then after four long months the devs behind C no longer maintain it because they've moved on to WebAssembly so a team spins off a fork of C in Coffeescript. In a lot of other communities they would've just evolved framework A, or C would've pushed some patches back to B. Or D would've taken over for C and there would've been a handoff. It's effing ridiculous that if I go back to a 5 month old project I will spend all damn day getting a build from source to work. It's not just the libraries and packages. It's the toolchain, the build pipeline (heaven forbid you look like a grandpa and still use Grunt!), the transpilers. I love that people are creating cool shit all the time, but it really seems like if the code didn't come from their team, they're going to iterate the idea and put out a competing package instead of contributing back to the original. And then we wind up with two unmaintained projects 6 months later... It really feels like there aren't many people (at least making headlines) that have had to maintain an actual live production system for more than a year or two. It'll be interesting to see what these people are doing 5 years down the road...
extrapickles 11y ago
At least with the C explosion you could check all the libraries into source control or other asset management system (filing cabinet, etc). Most of the JS library tools seem to encourage keeping code outside of source control which is pure crazy. It might work tolerably for a evergreen SaaS application, but you still have way too common complaints from developers that they couldn't build because someone else's server was down (NPM has trouble weekly). What is even worse is the encouragement to use a library/font/etc that is hosted in a CDN so the uptime of the app is also dependent on the uptime of the CDN hosting the library.
- madeofpalk 11y ago
  > NPM has trouble weekly Interesting. We deploy daily, always fresh from NPM at each deployment stage and have never had an issue with NPM. We had one legacy dependency downloading from github (ugh) which caused an issue the last time it went down, but we quickly sorted that out.

zdragnar 11y ago

> Which version of Babel, 5? or 6 I'm not really familiar with any popular build toolchain libraries written for 5 that haven't been updated to work with 6. It's not like a Python 2/3 scenario, or even an Angular 1/2.

cptskippy 11y ago

I've stopped using fancy framework or tools and stuck with pure JavaScript, CSS, HTML5 for personal projects and I'm loving it. I know that isn't always possible, especially with legacy applications, but it's incredibly liberating to have full control over a page and not have to dance with shitty partners.

orvr 11y ago
Amen

cubano 11y ago

No, I lived the C-explosion of 30 years ago and it was absolutely nothing like what I see these days. It utterly nuts how we are expected a learn a full-stack like Mongo/Angular/Backbone and then 6 months later is like NO we need AWS/React/Redux now! It's my oldman opinion that IT has become too much like fashion and not enough like engineering, but that's what oldmen think so who cares.

wonnage 11y ago
You can either shut yourself off from it and cement yourself into "oldman" oblivion, or actually try to understand why these tools exist.
- LoSboccacc 11y ago
  We old coot understand well why such inane tools exists and it's because there are too many people worrking in a hurry and can't be bothered to look back at sound engineering solution that already exists.
- manyxcxi 11y ago
  > You can either shut yourself off from it and cement yourself into "oldman" oblivion, or actually try to understand why these tools exist. For other languages/ecosystems I would agree. However, in the JS world there is a lot of stuff that exists simply to exist. There are typically multiple libraries to do the same thing (in general) but with someone else's opinionated take on it. Sometimes I feel like the developer of framework B was having a hard time grokking framework A and just decided to roll their own, like framework A, except for the parts they didn't like or understand. Then someone came along and realized that framework B had gaping security issues and was horrifically slow- so they created framework C which is the more secure and performant opiniated take on framework B that was an opinionated take on framework A. But then after four long months the devs behind C no longer maintain it because they've moved on to WebAssembly so a team spins off a fork of C in Coffeescript. In a lot of other communities they would've just evolved framework A, or C would've pushed some patches back to B. Or D would've taken over for C and there would've been a handoff. It's effing ridiculous that if I go back to a 5 month old project I will spend all damn day getting a build from source to work. It's not just the libraries and packages. It's the toolchain, the build pipeline (heaven forbid you look like a grandpa and still use Grunt!), the transpilers. I love that people are creating cool shit all the time, but it really seems like if the code didn't come from their team, they're going to iterate the idea and put out a competing package instead of contributing back to the original. And then we wind up with two unmaintained projects 6 months later... It really feels like there aren't many people (at least making headlines) that have had to maintain an actual live production system for more than a year or two. It'll be interesting to see what these people are doing 5 years down the road...

extrapickles 11y ago

At least with the C explosion you could check all the libraries into source control or other asset management system (filing cabinet, etc). Most of the JS library tools seem to encourage keeping code outside of source control which is pure crazy. It might work tolerably for a evergreen SaaS application, but you still have way too common complaints from developers that they couldn't build because someone else's server was down (NPM has trouble weekly). What is even worse is the encouragement to use a library/font/etc that is hosted in a CDN so the uptime of the app is also dependent on the uptime of the CDN hosting the library.

madeofpalk 11y ago
> NPM has trouble weekly Interesting. We deploy daily, always fresh from NPM at each deployment stage and have never had an issue with NPM. We had one legacy dependency downloading from github (ugh) which caused an issue the last time it went down, but we quickly sorted that out.