8 ms·

What I hate is that you don't even write JavaScript anymore. You write fantasy future JavaScript. Sure, it will be available in ECMAScript 23, scheduled to dr

by hakfoo 3y ago

What I hate is that you don't even write JavaScript anymore. You write fantasy future JavaScript. Sure, it will be available in ECMAScript 23, scheduled to drop in real browsers in 2092. But for now, here's a convoluted mess of polyfills, Babel, and WebPack, that we HOPE papers over the real behaviour of browsers, and suddenly your test-and-debug cycle has introduced a flow-shattering 15-second build cycle each time you change a file.

The_Colonel 3y ago
There's actually no need for that anymore. JavaScript as is supported right now in the latest Chrome, Firefox and Safari is already pretty good. You can get quite far without any backend tooling these days. The only thing which I believe is still needed is a bundler when your project grows to a certain size. Fetching a complex graph of thousands of files will likely never be fast.
- number6 3y ago
  Do you still use gulp or is it webpack nowadays?
  - arcanemachiner 3y ago
    It's JavaScript. Everyone is moving on to Turbopack. Or Vite. Or ESBuild. Or Bun.
    - sroussey 3y ago
      I definitely like the batteries included and speed of bun.
      - arcanemachiner 3y ago
        Please don't tempt me.
  - brabel 3y ago
    You're outdated. Everyone is using Parcel now.
    - zelphirkalt 3y ago
      Funny, how even the sibling comment states something different. Maybe there are a lot of bundler bubbles in the JS world?
      - brabel 3y ago
        sorry, I said that 9 hours ago... now we're using Bun actually :D
  - dmix 3y ago
    Gulp is extremely out of date these days. Using webpack resulted in some of the most painful experiences of supporting serious production software in my career. The progress and maturity of JS tooling/DX as a result of stuff like esbuild and Vite, or Typescript more generally, can not he understated. For people not doing frontend it can seem like a neverending series of new stuff but there is a very rational and tangible level of progress being made. Especially for serious JS devs not jumping on hype trains. I don't miss the days of gulp and webpack at all and I don't blame anyone for hating on JS if they experienced using them professionally.
    - number6 3y ago
      Gulp / Babel and then transition to webpack was my introduction to JS. Now Vite seems to be all the rage? But is it a bundler? Wepack seems to be very hard to configure. Looks like nginx config vs caddy config.
      - drkstr 3y ago
        Tools such as babel, webpack, esbuild, postcss, etc. are now considered a bit low-level, and usually do not need to be set up manually these days. Rather, one would opt for something like vite, the spiritual successor to react-scripts, that bundles all of these tools together with some good defaults/plugins, a means to configure them, and usually also some kind of dev server with hot module reloading, for a complete developer experience using your preferred toolchain. Check out 'parcel' for something pretty modern, universal, and low effort, IMHO.
    - theK 3y ago
      > Using webpack resulted in some of the most painful experiences of supporting serious production software in my career. I never invested too much time in understanding webpack but it does feel like fighting it a lot of the time when I want to change something in my personal projects. Care to share some anecdotes of those painful experiences?
- noduerme 3y ago
  Even bundlers can be pretty stupid and simple. I still just use r.js for even large apps. Webpack isn't hard to set up, either. But my frontend code has almost no dependencies... I refuse to deal with React, Angular, etc etc. I have a very nice, simple component-building / screen scaffolding system that's about 1000 LOC. You extend the component and load up some HTML and just work with it directly in JS when you want to update data, resize it, etc. There's no need for all these frameworks that try to plant logic back into HTML. I love having the HTML templates pure and the logic unbound from them.
- theK 3y ago
  > The only thing which I believe is still needed is a bundler And a type system... And maybe a styling system... Oh and let's have some nice Rx data flows! But, jokes aside, even if you go that Route you still end up with a complex npm project that involves dozens of libraries. I've been at that point every year since starting doing npm spas in 2014ish (mostly as side projects, my work is typically more serverside). At some point I just decided that the upkeep wasn't worth it any more as you create the same stack every year but with wildly different libs. For me the solution was to switch to an elm+sass+webpack boilerplate that hasn't changed since 2018 or there abouts.
inbx0 3y ago
Out of curiosity, what features are you using that aren't already supported by all major browsers?
- eimrine 3y ago
  Maybe the tail-call optimization?
hardwaregeek 3y ago
With evergreen browsers, you can write modern JavaScript and it'll run in the browser just fine. And it's not like TC39 is pumping out lots of wild changes. The largest recent change is what, top level await? That's not exactly a wildly different language feature. A lot of this JavaScript criticism was appropriate circa 2017, but these days JavaScript's gotten a lot more stable.
- yawaramin 3y ago
  Sure. With evergreen browsers. For anyone using old devices with outdated hardware--tough luck! They can, I guess, go buzz off and leave you in peace to write Modern JS. After all, that's the most important thing.
  - hardwaregeek 3y ago
    At this point you'd need a 10 year old never-updated browser to run into this issue. Which, sure, maybe you need to cater to people who use browsers 10 years out of date. I don't think it's a huge market frankly and 10 year old browsers have larger issues like security.
    - yawaramin 3y ago
      I mean, JavaScript doesn't just run in browsers. Some older forms of JavaScript run in all kinds of software--embedded in Windows (JScript), embedded JavaScript engines in other runtimes (Java, Qt Quick), older Node.js software that people are stuck on for whatever reason. I'm sure many people don't care about making all of those devices obsolete but maybe with a slight amount of effort we can try to slow down the inevitable filling of landmines with perfectly workable devices?
      - hardwaregeek 3y ago
        Okay, those cases seem like situations where you'd need to be explicitly targeting those devices. Like if you're shipping new code to users that is being run on an old runtime, then sure, you should make sure that code is legacy JS. I don't see how that is unreasonable?
Uehreka 3y ago
This is my problem with a lot of HN comments about JS: they read like they were written in 2014 (see also the “a new framework every week!” jokes) ES2015 was the one big language update, and although it took a while to all roll out and for older browsers to die off, at this point we’re now living in “the future” and almost all language changes are incremental. Like, you can write ES modules with async/await and run it in all modern browsers without any compilation. If you add an HTML import-map element you can even import node_modules by name. Now, most people still prefer to use a bundler so that their users can load a single script instead of dozens of tiny ones, but that’s optional, and the gap between “the code you write” and “code that runs in the browser” hasn’t been this small in years.
- hakfoo 3y ago
  Part of it could be different audiences. Not everyone is on a greenfield project with full authority to grab the freshest and latest. Some of us are effectively living in 2014-- they can't say "no, you can't use IE11" to paying customers, or committed to a platform at the wrong phase of maturity, and remain stuck around a state-of-the-art-in-2014 build process.

by hakfoo 3y ago

The_Colonel 3y ago

There's actually no need for that anymore. JavaScript as is supported right now in the latest Chrome, Firefox and Safari is already pretty good. You can get quite far without any backend tooling these days. The only thing which I believe is still needed is a bundler when your project grows to a certain size. Fetching a complex graph of thousands of files will likely never be fast.

number6 3y ago
Do you still use gulp or is it webpack nowadays?
- arcanemachiner 3y ago
  It's JavaScript. Everyone is moving on to Turbopack. Or Vite. Or ESBuild. Or Bun.
  - sroussey 3y ago
    I definitely like the batteries included and speed of bun.
    - arcanemachiner 3y ago
      Please don't tempt me.
- brabel 3y ago
  You're outdated. Everyone is using Parcel now.
  - zelphirkalt 3y ago
    Funny, how even the sibling comment states something different. Maybe there are a lot of bundler bubbles in the JS world?
    - brabel 3y ago
      sorry, I said that 9 hours ago... now we're using Bun actually :D
- dmix 3y ago
  Gulp is extremely out of date these days. Using webpack resulted in some of the most painful experiences of supporting serious production software in my career. The progress and maturity of JS tooling/DX as a result of stuff like esbuild and Vite, or Typescript more generally, can not he understated. For people not doing frontend it can seem like a neverending series of new stuff but there is a very rational and tangible level of progress being made. Especially for serious JS devs not jumping on hype trains. I don't miss the days of gulp and webpack at all and I don't blame anyone for hating on JS if they experienced using them professionally.
  - number6 3y ago
    Gulp / Babel and then transition to webpack was my introduction to JS. Now Vite seems to be all the rage? But is it a bundler? Wepack seems to be very hard to configure. Looks like nginx config vs caddy config.
    - drkstr 3y ago
      Tools such as babel, webpack, esbuild, postcss, etc. are now considered a bit low-level, and usually do not need to be set up manually these days. Rather, one would opt for something like vite, the spiritual successor to react-scripts, that bundles all of these tools together with some good defaults/plugins, a means to configure them, and usually also some kind of dev server with hot module reloading, for a complete developer experience using your preferred toolchain. Check out 'parcel' for something pretty modern, universal, and low effort, IMHO.
  - theK 3y ago
    > Using webpack resulted in some of the most painful experiences of supporting serious production software in my career. I never invested too much time in understanding webpack but it does feel like fighting it a lot of the time when I want to change something in my personal projects. Care to share some anecdotes of those painful experiences?
noduerme 3y ago
Even bundlers can be pretty stupid and simple. I still just use r.js for even large apps. Webpack isn't hard to set up, either. But my frontend code has almost no dependencies... I refuse to deal with React, Angular, etc etc. I have a very nice, simple component-building / screen scaffolding system that's about 1000 LOC. You extend the component and load up some HTML and just work with it directly in JS when you want to update data, resize it, etc. There's no need for all these frameworks that try to plant logic back into HTML. I love having the HTML templates pure and the logic unbound from them.
theK 3y ago
> The only thing which I believe is still needed is a bundler And a type system... And maybe a styling system... Oh and let's have some nice Rx data flows! But, jokes aside, even if you go that Route you still end up with a complex npm project that involves dozens of libraries. I've been at that point every year since starting doing npm spas in 2014ish (mostly as side projects, my work is typically more serverside). At some point I just decided that the upkeep wasn't worth it any more as you create the same stack every year but with wildly different libs. For me the solution was to switch to an elm+sass+webpack boilerplate that hasn't changed since 2018 or there abouts.

inbx0 3y ago

Out of curiosity, what features are you using that aren't already supported by all major browsers?

eimrine 3y ago
Maybe the tail-call optimization?

hardwaregeek 3y ago

With evergreen browsers, you can write modern JavaScript and it'll run in the browser just fine. And it's not like TC39 is pumping out lots of wild changes. The largest recent change is what, top level await? That's not exactly a wildly different language feature. A lot of this JavaScript criticism was appropriate circa 2017, but these days JavaScript's gotten a lot more stable.

yawaramin 3y ago
Sure. With evergreen browsers. For anyone using old devices with outdated hardware--tough luck! They can, I guess, go buzz off and leave you in peace to write Modern JS. After all, that's the most important thing.
- hardwaregeek 3y ago
  At this point you'd need a 10 year old never-updated browser to run into this issue. Which, sure, maybe you need to cater to people who use browsers 10 years out of date. I don't think it's a huge market frankly and 10 year old browsers have larger issues like security.
  - yawaramin 3y ago
    I mean, JavaScript doesn't just run in browsers. Some older forms of JavaScript run in all kinds of software--embedded in Windows (JScript), embedded JavaScript engines in other runtimes (Java, Qt Quick), older Node.js software that people are stuck on for whatever reason. I'm sure many people don't care about making all of those devices obsolete but maybe with a slight amount of effort we can try to slow down the inevitable filling of landmines with perfectly workable devices?
    - hardwaregeek 3y ago
      Okay, those cases seem like situations where you'd need to be explicitly targeting those devices. Like if you're shipping new code to users that is being run on an old runtime, then sure, you should make sure that code is legacy JS. I don't see how that is unreasonable?

Uehreka 3y ago

This is my problem with a lot of HN comments about JS: they read like they were written in 2014 (see also the “a new framework every week!” jokes) ES2015 was the one big language update, and although it took a while to all roll out and for older browsers to die off, at this point we’re now living in “the future” and almost all language changes are incremental. Like, you can write ES modules with async/await and run it in all modern browsers without any compilation. If you add an HTML import-map element you can even import node_modules by name. Now, most people still prefer to use a bundler so that their users can load a single script instead of dozens of tiny ones, but that’s optional, and the gap between “the code you write” and “code that runs in the browser” hasn’t been this small in years.

hakfoo 3y ago
Part of it could be different audiences. Not everyone is on a greenfield project with full authority to grab the freshest and latest. Some of us are effectively living in 2014-- they can't say "no, you can't use IE11" to paying customers, or committed to a platform at the wrong phase of maturity, and remain stuck around a state-of-the-art-in-2014 build process.