Hacker News Reader

Comment by mmartinson | Hacker News Reader

Honest question, not meant to be inflammatory.

If we still need to target es5 4 years later, and transpilation is standard practice, why bother? Is the evolution of JS not directed in practice by the authors of Babel and Typescript? If no one can confidently ship this stuff for years after, what’s the incentive to even bother thinking about what is official vs a Babel supported proposal.

I like the idea of idiomatic JS with powerful modern features, but in practice every project I’ve seen seems to use a pretty arbitrary subset of the language, with different ideas about best practices and what the good parts are.

View on HN

That's not unique to JS. Some compilers took over a decade to implement C99 features. Most of us C coders were still defaulting to C89 for portability well into the late 00's. But now C99 is mainstream enough that you can (mostly) safely target it.

If you never release new standards you'll never be able to use them. I realize that in JS world 4 years is basically an eternity so it's hard to project that far but I'm sure that if you still have to write javascript code 10 years from now you'll be happy to be able to use the features of ES2019.

Regarding transpilation surely it's not as standard as you make it out to be? It's popular to be sure but handwritten javascript is not that rare nowadays, is it?

Sadly the "mostly" is because threads :(

It is the part I was most excited about C99 and was very disappointed that it is so poorly supported.

Threads are C11, not C99.

> Regarding transpilation surely it's not as standard as you make it out to be? It's popular to be sure but handwritten javascript is not that rare nowadays, is it?

If you are building a modern web "app", not a one off set of web pages, then yes, it is the standard. It would be very weird to not see a compile (transpilation) step.

It's becoming less and less necessary. If you don't care about browsers with tiny usage you can ship ES6 as-is these days. All the main browsers support ES6 modules. And HTTP2 means having all those modules in different files doesn't have the huge performance impact it once did. About the only thing left (that isn't easily solvable) is stripping comments and minifying.

While that's true, dealing with compatibility issues and making sure all of your services are using http2 is arguably more work than just using babel.

Versioning files is still a need too.

I'm just making a handwritten microproject. It's to be included in a very old gigantic internal platform so I didn't want to add any more build steps to it. Everything was going smoothly, until someone said... It's not working in IE11 and some clients are still using it. We ended up converting the js to an older version in a half automated/half manual way with babel... I'm so used to use some of the new features I didn't even remembered they didn't existed before. I used babel before, but only now I realised really out how much pain it saved me over the years.

> It's popular to be sure but handwritten javascript is not that rare nowadays, is it?

Long time front end developer here. In the last couple of years I can't recall seeing even a single project without a build pipeline (not that they don't exist, I just haven't encountered them at my day job, first or third party).

I made this recently just because I wanted to prove to myself that it was possible to have a modern frontend application without all the overhead of build tooling and I have to say I'm pretty happy with it. You can use some of the most important things in browsers today like CSS variables, and ES module imports.

https://gitlab.com/WA9ACE/frontend-starter

That's an interesting project template. Manually managing dependencies and using backbone sounds quite fun!

I was able to create a full web app using Preact with no build pipeline at all. It was not the best experience mostly because of no concatenation.

I ended up adding Parcel for easy Typescript support.

I agree in broad terms, but as a counterpoint, those build pipelines are being created and used primarily by folks who initially learned by handwriting javascript.

While less of a consideration for established teams, it dramatically raises the barrier to entry for those who are learning as well as those who currently have much simpler requirements. Those are the future members of that established team. Adding hurdles to the process of learning will, in the long run, result in a smaller, more homogeneous pool of experienced developers to draw upon. It's a self-perpetuating cycle - making folks learn by using complex build scripts will result in experienced developers who then create further complexity because they've self-selected to be those who happen to think in that mode.

That's not intended to suggest that progress is bad. Rather that it's a bit short-sighted of us, as an industry, not to consider the ramifications of enforcing a workflow that happens to be trivial from the limited perspective of long time front end developers.

{ Edit to try to make the last paragraph sound less accusatory. Sorry! That wasn't my intention. }

There are tools like create-react-app that configure complicated build pipelines for you, and there's parcel, a simple common-case build pipeline.

The biggest issue I've seen with these is that at some point they do break and then you need a knowledgeable person to fix it. The pipeline is basically a black box unless you possess the knowledge of how all the parts work and interact with each other.

I dunno how to put this in a non-controversial way, but...at some point, I switched from thinking a desirable, throw-the-money-at-them developer is somebody who writes a lot of code to somebody who understands things and is capable of understanding new ones when they arise.

I'm not saying that to excuse thrash. Thrash is bad. But like..."oh, at some point you'll have to have somebody who actually understands how the thing we use to make money works"--you should have that person anyway! It's an existential threat to your business not to.

Understanding things is our job. Unless you're somewhere where understanding things isn't valued, and 1) it's gonna eventually fail, and 2) you have better places to be.

> somebody who understands things and is capable of understanding new ones when they arise.

Some of us won't let go of the crazy dream that things should be simpler. I want this not because I'm lazy or because I don't understand them but because - dammit - things should be simpler.

Complex things are complex. Attempting to simplify complex systems below this threshold of complexity invariably ends in lost capability or lost fingers when the sharp edge you didn't know was there sneaks up on you.

And web browsers are very complex beasts by design, by accretion, and by necessity.

Sorry, I guess. Does bemoaning it actually help anything?

But we're not talking about web browsers per se - we're talking about the javascript ecosystem. The complexity of which is only indirectly related to that of the browser.

Again, just for the sake of playing Devil's Advocate, the fact that we rely entirely upon such helpers (and the overwhelming number of mutually exclusive options available) is a potential indicator that we're making it more complex than we have to[1].

The syntactic sugar that we're adding to make our own jobs easier is arguably making things disproportionately more difficult for anyone who doesn't already have the same baseline level of knowledge. That includes those who are trying to learn to do our jobs after we've all moved on. That would notably have also included all of us, earlier in our careers.

I'm just suggesting that it's worth considering whether that seems sustainable in the long run.

[1] ... for relatively simple tasks. Complex tooling happens to be a very good tool for complex tasks, like the sort of professional work that you seem to be referring to. No matter how good our hammer may be, however, not every task always wants to be a nail. create-react-app and parcel are examples of excellent hammers.

The main complex task that's being addressed is making JavaScript that runs on a variety of browsers, not just the latest Firefox.

I'm afraid I don't know what you have in mind as far as syntactic sugar that makes things harder for learners. Every new syntax I can think of makes JS easier to learn and use.

I don't understand what is so appealing about not having a build pipeline for JavaScript, other than the ability to very quickly test and learn things directly in the browser, which of course anyone can still do.

For anything remotely important, you're almost certainly going to already want a build pipeline to do things like concatenating/minifying code, running tests, and deploying. Adding a transpilation step to extend support to older browsers comes with almost no cost to time or maintainability, assuming you're using well-supported things like Babel and its official plugins.

I have no concerns about having a build pipeline per se. My concern is that it's still way too complex and difficult. I think it could be made to be much simpler for 90 percent of cases, while still maintaining optional complexity for the remaining 10 percent of cases that need it.

> Adding a transpilation step to extend support to older browsers comes with almost no cost to time or maintainability

They may be simple concepts, but there's definitely still an added cost with transpilation and minification steps.

If you work with Babel long enough you'll encounter scenarios where the transpiling didn't quite work as expected and breaks in-browser.

When you're debugging minified code in-browser using source maps, it's not all that uncommon to get different line numbers and stack traces than you get when loading up the original unminified source. I can recall a number of occasions where I had to deploy unminified source for in-browser debugging because the source maps were obfuscating the real error.

https://www.joelonsoftware.com/2002/11/11/the-law-of-leaky-a...

>I don't understand what is so appealing about not having a build pipeline for JavaScript

We don't have one at my work (Fortune 100 company), but it has nothing to do with whether it is appealing or not. It has to do with the projects we are working on started years before there was any such thing as a build pipeline in the web world and it's not pragmatic to add one in at this point. Maybe some decade we will get the budget to start over from scratch (haha!) and get modern things like a build pipeline.

The appealing thing about not having a build pipeline is not having it. Not having another thing to maintain and update/upgrade/debug. I've gone through grunt, gulp, webpack and parcel. Somewhere along the way I realized that with es6 imports and css variables I don't really need it.

I've talked with frontend devs who only worked on projects with build steps about this and they often seem perplexed and surprised by just how simple it can be if you don't make it complex.

Can you imagine a modern SoundCloud, Spotify, Facebook, Airbnb or Slack without a build pipeline? There's nothing appealing about that.

It's nice and simple for small projects but let's not act like putting a script tag in HTML is some divine wisdom that newbies don't understand.

Yes I can. All of those except for facebook (because facebook is a sprawling platform) seem reasonable to be able to build without a build system. And with using es6 modules it's not "putting a script tag in HTML", you have a proper module loading system without needing any builds or libs.

I'm not saying it's some sort of lost knowledge like Damascus steel, I'm just saying that many people these days are so caught up into the current dogma of JS that they never consider a simpler but still modern path.

I'm using Webpack + Babel... but literally only for features after async/await. All major, current browsers support it. That's the baseline support for the apps I'm working on now.

The payload to fill promises, regenerator and async are huge, and without them, my payload is significantly smaller. for preset-env...

      {
        loose: true,
        modules: false,
        useBuiltIns: 'usage',
        corejs: 3,
        targets: {
          browsers: ['edge 15', 'safari 10.1', 'chrome 58', 'firefox 52', 'ios 10.3'],
        },
        exclude: ['transform-async-to-generator', 'transform-regenerator'],
      },

from here, I only need the features not part of stage 4 that I want to add. I have the following in a test script...

    try {
      eval('(function() { async _ => _; })();');
      if (typeof fetch === 'undefined') throw new Error('no fetch');
    } catch (e) {
      window.location.replace('/auth/legacy.html');
    }

With async functions, and fetch api available, you get a LOT in the box.

I work for a Fortune 100 company and we still don't have a build pipeline :-(

> That's not unique to JS. Some compilers took over a decade to implement C99 features.

I sometimes wonder what's the point of new versions of C, too.

Also, a new feature I want to use needs only be supported by one C compiler: the one I'm using. With JS, I need all of them to support it.

THat's not right, the same is true of JS. You'd run a "build" step on a system you control to transpile your fancy modern JS back as far as you'd like official support and put the output JS file on your webserver.

Using modern JS features does not require universal support.

> Also, a new feature I want to use needs only be supported by one C compiler: the one I'm using.

I've always had the impression that C programmers also care about standards compliance, and aren't typically willing to marry their project to a particular compiler.

At least, it's the language community where you see "language lawyers". I'm sure there are "language lawyers" in other language communities, but I've never seen discussions about what causes "undefined behavior" or what's "implementation dependent" or discuss interpretations of particular passages of the standard like I do with the C and C++ communities.

>I sometimes wonder what's the point of new versions of C, too.

At this point I'm mostly fine with the feature set of C99 so I can live without the newer standards. Actually there's stuff in newer standards that I find questionable, but that's a different discussion.

C99 on the other hand was sorely needed, if only for standardizing some basic features that up until then were only available as vendor-specific extensions. Things like inline, stdint.h, bools, variadic macros, restrict, compound literals and more[1].

Writing code without these features is often severely limiting. Or rather, you probably won't be limited but you'll have to rely on vendor extensions and write non-portable code. Or maybe you'll use a thousand-line long configure script to make the code portable.

>Also, a new feature I want to use needs only be supported by one C compiler: the one I'm using. With JS, I need all of them to support it.

If you're making proprietary software that makes sense, if you're developing open source code you very much care about portability and compatibility. I care about the compiler I use, the compiler OpenSuse uses, whatever garbage Visual Studio uses, the compiler FreeBSD uses etc...

Besides I have basic code snippets I wrote over a decade ago that I still use today, regardless of the environment. That's valuable too.

[1] https://en.wikipedia.org/wiki/C99

I don't think I ever write C code that I intent to only be compiled using one compiler. One of the primary reasons I use C is to write cross-platform code, so I care about GCC, Clang, and VS, at least.

GCC and Clang are both cross-platform, and users typically don’t care about which compiler you used to produce the binary. At least until the early 2010s plenty of projects used GCC-specific features and wouldn’t compile with Clang. The situation must be better now but I bet GCC is still the only blessed compiler for many maintenance-only code bases.

> Most of us C coders were still defaulting to C89 for portability well into the late 00's. But now C99 is mainstream enough that you can (mostly) safely target it.

Sure, but if C came out with a new standard every year, you'd essentially never be on the latest version. Isn't there at least a valid argument to slowing down a bit to give the implementations a chance to catch up instead of having a new ES 20XX every year?

The implementations that are moving at all are keeping up fine. The biggest question for web developers is whether they support IE. If you do, you're stuck on ES5. If not, you can use most features from ES2015 and up. Once the next release of Edge is out, that will expand greatly.

Even if you support IE, you can still reap the benefits of modern JS if you're willing to do some differential serving. You can use the module/nomodule pattern to serve ES2017 without making changes to the server.

It's a bit different with compiled code though right? If you stop supporting the previous C revision, it means the person compiling your code need to upgrade their compiler, the executable will work for everyone on that platform once built.

Whereas in JS-land, the support for upgrades is even more trailing because it's the end-users who need to upgrade, not just the individual/organization doing the packaging.

Huh? The compiled JS will continue to work just fine for the end-user. Not sure what you're getting at.

Sure, but JavaScript isn't compiled but typically interpreted (or JITed).

Sure, but this is a distinction without a difference from the perspective of the end-user.

If your C code is upgraded from C n to to use C n+1 features, then it breaks compilers that do not support c n+1. This is not a problem for end-users, because most people do not compile the code themselves, but use pre-built binaries. So, it is a problem for the package maintainer to deal with, the package maintainer upgrades their compiler and the new binaries just work for the end user, because once compiled it doesn't matter if the source was C n or C n+1.

If you JS code is upgraded from ES n to ES n+1, you need to polyfill and transpile in perpetuity, otherwise end users with access to only ES n browsers will not be able to run your code at all.

Comparing C spec updates and JS spec updates is comparing apples to oranges.

> If you JS code is upgraded from ES n to ES n+1, you need to polyfill and transpile in perpetuity, otherwise end users with access to only ES n browsers will not be able to run your code at all.

I'm still not seeing the difference. End users of JS applications don't compile their code the same way end users of a C binary don't compile the code.

If you ship an app with ES6 js and a user with a browser that doesn't support ES6 features tries to access it, then it won't work for them.

The user doesn't manually compile anything, but their choice (sometimes lack of choice) of browser determines which version of the spec they can run. So you end up polyfilling forever because some significant chunk of your user base is tied to IE8 or worse.

All the original commenter meant is that the people making the software can't ever guarantee what version of JS the end user's browser can handle.

> If you ship an app with ES6 js and a user with a browser that doesn't support ES6 features tries to access it, then it won't work for them.

Right, but if the developer transpiles their source code and distributes it then the JS end-user is in the same situation as the C binary user. Distributing ES6 code without transpiling it is akin to distributing C source code without compiling: the end-user would need to have an up to date compiler/runtime to execute the code.

> If you stop supporting the previous C revision, it means the person compiling your code need to upgrade their compiler

FYI, this doesn't happen in C, all C versions are backwards compatible - you can compile C89 code on any compiler supporting C99, C11 or C18.

parent means if code starts using C99 features that won't work in C89, then the person with a C89 compiler needs to upgrade their compiler.

Where C11 > C99.

Talk about naming problems / sorting problems. They've adopted Microsofts versioning system where Windows 8 is newer than both Windows 98 and Windows 2000.

Does anyone remember the Y2K problem. Anyone?????

They worked out naming things properly (where computers are involved) was a big problem in the 1960's. But we still only allocated 3 bytes for the version of C or something...?

Different, yes, but the difference is quantitative, not qualitative.

Once a transpile step is required, it doesn't make as much of a difference what is on the other side.

C to a lesser extent does have the same trailing problem with end users as well in libc / VCRUNTIME and other standard lib bundles.

On Windows VCRUNTIME installs are mostly painless, easily backgrounded, and people don't realize they sometimes have as many as 100s of different versions installed side-by-side because every game installed wants a slightly different version.

But on Linux, it's often as much as like three-fourths of the reason that code needs to be rebuilt so often for every possible different Linux distribution because most distributions lock to only a single libc and prefer every app dynamically link that specific libc. Apps get held back by distributions slow to adopt libc updates all the time in Linux, and app devs try to stick to common libc versions based on distribution popularity (user preference), which isn't dissimilar to the lagging browser problem.

(Then there are arguments about statically bundling libc / VCRUNTIME, etc.)

It's not as bad as JS land on average, but that doesn't mean that C is immune to the same problem. As soon as you are dealing with shared libraries / platforms / runtimes, you run into having to deal with what users are willing to install (and practically no platform is immune, depending on trade-offs one is willing to take).

> It's popular to be sure but handwritten javascript is not that rare nowadays, is it?

Even if you’re only targeting evergreen browsers, the popular build tools also perform minification and dependency resolution/linking. There’s so much a tool like webpack can do for you that I imagine it will remain hugely popular even as the need for transpilation wanes.

> Regarding transpilation surely it's not as standard as you make it out to be?

The impression I got from working on various projects over the past couple of years was that if the build doesn't include Babel/Webpack/Packet/etc then you're not doing a 'professional' job.

> ... handwritten javascript is not that rare nowadays, is it?

I love handwriting vanilla javascript, though I only really get the opportunity to do it in my personal projects.

When I made the decision earlier this year to rewrite my canvas library from scratch, I made a deliberate choice to drop support for IE/Edge/legacy browsers. (I can do this because nobody, as far as I know, uses my library for production sites). Being able to use ES6+ features in the code - promises, fat arrows, const/let, etc - has been a liberation and a joy and made me fall in love with Javascript all over again. Especially as the library has zero dependencies so when I'm working on it, it really does feel like working in uncharted territory where reinventing a wheel means getting to reinvent it better than before.

I wish paid work could be such fun.

Agreed! My personal project is vanilla JS, no dependencies, and no attempt to support old browsers, and it's so much fun to work in. And, since Real Life sometimes puts side projects on hold for a year or two, it's nice to know that picking it back up won't involve re-learning, updating or replacing a bunch of stuff I've forgotten the details of.

> The impression I got from working on various projects over the past couple of years was that if the build doesn't include Babel/Webpack/Packet/etc then you're not doing a 'professional' job.

If you have alternative recommendation that's not these tools, I'd be curious to hear it.

> Regarding transpilation surely it's not as standard as you make it out to be? It's popular to be sure but handwritten javascript is not that rare nowadays, is it?

I'd say for the last 5 years 90% of my browser JS projects used Webpack and Babel.

I write small lambdas is JS all the time. Generally it's just a couple of SDK calls so it's not worth the toolchain.

As of VS2017, MSVC still missed a bunch of C99 features (or they're buggy as hell):

> Variable Length Arrays are not supported (although these are now officially optional)

> restrict qualifier is not supported, __restrict is supported instead, but it is not exactly the same

> Top-level qualifiers in array declarations in function parameters are not supported (e.g. void foo(int a[const])) as well as keyword static in the same context

They only started seriously working on actual C99 support (aside from the bits of C99 which were part of C++) for VS2013 or so.

Though to be fair it seems both Clang and GCC are still missing bits and bobs:

> The support for standard C in clang is feature-complete except for the C99 floating-point pragmas.

for GCC I found https://gcc.gnu.org/c99status.html, it's unclear how up-to-date it is, and if GCC is still missing any required feature.

>If we still need to target es5 4 years later, and transpilation is standard practice, why bother? Is the evolution of JS not directed in practice by the authors of Babel and Typescript? If no one can confidently ship this stuff for years after, what’s the incentive to even bother thinking about what is official vs a Babel supported proposal.

For one, not everyone works on the client. I can write for Node and use everything v8 supports without ever touching Babel and Typescript.

>I like the idea of idiomatic JS with powerful modern features, but in practice every project I’ve seen seems to use a pretty arbitrary subset of the language, with different ideas about best practices and what the good parts are.

Good parts/best practices are orthogonal to native features and libs, which is what we're discussing here.

> I can write for Node and use everything v8 supports without ever touching Babel and Typescript.

You totally can do that--but you probably shouldn't, because writing TypeScript is better for you and for future you. ;)

How will TypeScript instead of plain JS help the future me? Unless of-course you meant that as a joke (going by the wink).

Type safe code improves code readability, and the future you will most likely read the code you are writing today.

If you were more comfortable/most familiar with strongly typed languages, then yes. But don't assume everyone has your tastes. Java for example is a very strongly typed language, and I find the verbosity makes it harder to parse.

Good, future proof code can be written in any language. There's lots of still functioning, well maintained js written 10yrs back out there.

"I didn't have to write a test to know that I am passing a data structure correctly across every module of my application" is not a "taste" thing and comparing TypeScript to nominative typing isn't a reasonable and fair tactic.

We have legacy JavaScript dependencies and most of them worry me. I don't stay up at night worrying about the domain and range of TypeScript ones even if their testing is weak. There's a reason for that.cs TypeScript is loose where it should be loose and yet strongly encourages flexible but very clear typing that provides significant resistance to broken contracts and misunderstood semantics. I won't hire a web or Node developer who has a problem with it today because understanding the value of gradual and structural typing is, I strongly think, evidence of baseline competence.

"I write worse code, slower" is defensiveness masked as "a taste thing." We've improved the state of the art and it's better here.

If you write JavaScript with a c# frame of mind, of-course you'll find it akward and hard to test. TypeScript is basically JavaScript written in a c# frame of mind, and there is nothing wrong with that. If it helps some people be more productive, then more power to them. but don't fool yourself that TypeScript is the best way to do JavaScript. If you're finding writing maintainable apps in plain JavaScript hard then you are simply doing it wrong. You can learn how to do it right (hint: its a functional, not a class based language) and add one more tool to your box, or you could stick with Typescript and your comfort zone.

I have worked with TypeScript, and I enjoyed it. It reminded me of ActionScript 3, a language I really enjoyed that's more or less dead now. And I also enjoy plain JS, and its just more powerful and expressive.

> I won't hire a web or Node developer who has a problem with it today because understanding the value of gradual and structural typing is, I strongly think, evidence of baseline competence.

If you think the benefits of "gradual and structural typing" cannot be achieved in JavaScript, you clearly don't understand the language. And that's ok. It is also ok hire people you are comfortable with, rather than those who challenge and disrupt your way. And I wouldnt want to work somewhere where the devs are too rigid or tribal about tools. Am more interested in what I'm building, rather than the tools used.

I don't have a good way to describe this post as anything but not-even-wrong. "Hint, it's a functional language"--types are orthogonal to whatever functional-versus-OO dichotomy you've invented in your head. Gradual and structural typing are components of type systems of either static or inferential basis and JavaScript is neither--so, definitionally, you can't achieve them in JavaScript. And given that TypeScript is a strict superset of JavaScript, it's absolutely bonkers to claim that JavaScript is "more powerful and expressive". Should one need to go outside those gradual type strictures, `any` is right there.

I knew JavaScript cold well before I was using TypeScript and I've shipped both mobile and web applications using JavaScript, as well as writing a solid amount of high-performance backend systems. And I ended up writing an eye-gouging number of tests that go away with TypeScript. It is literally, not figuratively, a way to dismiss entire classes of bugs. I may not understand JavaScript, but I'm not the one making factually inaccurate assertions about stuff up in here and that makes me really wonder how solid your conclusions can possibly be.

But as a gentle observation: people don't usually go on about "tribal" developers when the facts are on their side.

Your problem is the emotional denial that there is an engineering trade-off TypeScript makes by adding strict typing to JS. That trade-off is less flexibility and expression, and the gain is more fool-proof code, thats more familiar and comfortable to those more familiar with languages based on classes and strong typing.

> Gradual and structural typing are components of type systems of either static or inferential basis and JavaScript is neither

Whoa! That's a lot of words to basically say "JavaScript does not have static or inferential/derivable types". Kind of like the way type annotations create all that syntax noise. And I was talking about achieving the BENEFITS of "gradual and structural typing". It is done for the the benefits, not for its own sake. Do you even know the benefits? In proper JS, the same is easily achieved by duck-typing, and run-time checking whenever necessary.

> And given that TypeScript is a strict superset of JavaScript, it's absolutely bonkers to claim that JavaScript is "more powerful and expressive"

I touched on the a bit when talking on trade-offs. A superset does not mean super like superman. it means an added layer of abstraction. You are moving further away from the metal, and leaving some decisions to the TypeScript compiler. That means giving away power, and flexibility to the compiler. A good engineer understands, and is not in denial about the trade-offs they are making.

> But as a gentle observation: people don't usually go on about "tribal" developers when the facts are on their side.

What really happens is that people outgrow their tribal instincts once they realize that this are all just tools that come and go, it is the underlying ideas that matter. JS absorbed all the best ideas from jQuery, and jQuery went. It has integrated all the best ideas from CoffeScript (js with a python frame of mind), and coffee-script is no longer the rage it was a few years back. Same is happening with TS, which is why my money is still on JS. The fact is, js will outlive ts.

Java is verbose because it is Java, not because it is statically typed. Let's look at some more modern and ergonomic language instead, like Typescript which is much more relevant to the OP.

The typing there might add a few extra characters to your function definitions but you gain them back in terms of less need for documenting the argument types in comments. You hardly ever see typing inside of functions in Typescript so it hardly adds any verbosity.

Java was used as an example of strongly typed taken to the extreme. Something YOU can relate to, as a TypeScript user. In terms of verbosity, the difference between Java and TypeScript is like the difference between TypeScript and JavaScript.

I do appreciate the comparison and have suffered enough Java in my life to fully understand it. But i have to tell you again, Java is not verbose because it has "taken strong typing to the extreme" (correlation vs causation), it's just a badly designed language. From the same familiy of languages look at C# and Kotlin for example, they are both much stronger than java (minus checked exceptions) but at the same time very less verbose. There are many other examples of this, C++21 is stronger and less verbose than C++98. Rust can also many times be less verbose than C++ or C and at the same time stronger.

In many cases typescript can also reduce verbosity because of more modern features and transpiling. For example early versions had foreach long before it was in ES and before Babel was as widespread as today. In fact you don't even need to add type annotations at all to run typescript, you can let it try its best on plain javascript, in those places where it's not obvious from context, just add the extra :string.

IMHO the current state of affairs is actually the best possible scenario.

- Experimental language proposals can be tested in the wild

- Real non-ivory-tower feedback is raised to TC39

- Everything feeds into the canonical ES spec (~no splintering)

- Us regular folk are able to harness new syntax immediately

- Users continue to have their old runtimes supported

I agree. 10 years ago I wouldn’t believe the language would be evolving (mostly improving) at the pace it currently is.

I find these to be good points, but there is something missing for me that makes this "best possible scenario" only pretty good.

JS is a notoriously quirky and inconsistent programming language. Clearly it's sufficiently usable for writing complex, powerful and reliable programs, but it's error-prone for non-experts and encourages programming patterns that make importing accidental complexity the norm.

For many programming situations it'd be easy to just pick a different language, but obviously thus isn't the case for writing browser-based programs.

The best possible scenario for me would somehow involve deprecation and removal of the nasty parts of JS, and a path towards a smaller, simpler, more consistent language. Right now it feels like the cost of backwards forever compatibility is paid every day, in every project, and it's completely wasteful, given that transpile and polyfill is widely considered best practice.

Whether this could the job of TC39 or some other institution could go either way for certain.

Typescript removes some of the nastiest Javascript features. Of course that's not it's raison d'être and it includes a bunch of stuff you may not care for. However it is what is currently occupying the niche you're asking for. And it has all the advantages parent mentions.

JavaScript was very simple compared to most languages. Adding a bunch of extra syntax variants, different types of scoping rules, magic syntax has made the language overly complex. Thankfully you can still use the "good parts".

What parts of JS do you suggest removing? JS has its quirks, but it is not a particularly big language.

It is not only the best possible scenario, it's a beautiful elegant solution that 10 years ago nobody would have dreamed of. This really propelled the web as a platform (although opinions vary on whether the web should be a platform at all).

As a purely backend engineer with a passionate hatred for NPM, I love writing ES6 and native javascript. All of the newer features (tbh, I don't know which are new but I guess 'const', 'arrow functions', 'default parameters', 'string interpolations', 'filter/map' are definitely a few of them and made javascript more like the back end language that I work with). I wrote at least a thousand line of native javascript for the monkey scripts and my personal websites and I consider the experience a good one. I applaud the advancement of the javascript language itself and I consider the package management the source of all evil for javascript.

What's your take on Node and backwards compatibility? Since you get to choose your runtime, is it valuable to stick with the same always-add, never remove approach as the browser? NPM taken out of the picture, I get writing one language everywhere would be nice. Do you just consider the bad parts to be the price to pay for not needing to keep track of the distinctions?

I've recently been working in Electron, and I find having app logic in both browser JS and Node to be more of a frustrating uncanny valley than a help. I suspect I'm in the minority on this one though, at least amount people with workaday skill set in client side JS.

I feel like you're mentioning forward compatibility instead of backward compatibility. ES5 code should run fine in ES6 AFAIK, and that's the extend of backward compatibility that should ever be needed. I haven't touched node all that much, and I'm in the camp that while it's good to just write one language everywhere, javascript still exhibits many of the key features of a browser language, which makes running it locally 'unnatural'. Same with trying to get python to run in a browser, maybe we should just embrace that we need to learn more languages as that is generally the case for us software engineers.

From my perspective, it is less about what we can use in the browser without transpilation, but where the js ecosystem is heading. I personally only want to write JS that is in spec because in 5 years something like decorators might not be a thing. Basically when I'm figuring out what language features I care about, I'm thinking about how hard it will be for other engineers to work on the codebase. Things that are not in spec are going to be less familiar and more time to learn. I think there's a lot of momentum with the spec and something to point to where can say "you should learn this syntax/feature because it's in the spec."

> Basically when I'm figuring out what language features I care about, I'm thinking about how hard it will be for other engineers to work on the codebase. Things that are not in spec are going to be less familiar and more time to learn.

I agree, this is super important. My inclination whenever I did into a JS project has been to use lodash/underscore everywhere for everything, assuming that it is popular enough that someone will be able to maintain it without much headache, and I can actually get stuff done without breaking my brain over JavaScript's notorious quirks. I'm curious at what point this stops being a good practice. It certainly was 4 years ago.

I hardly use lodash. What do you use it for? I presume most of your use cases can by easily handled by just using JS from the ECMAScript spec.

Personally, I only lodash for the debounce functionality.

This came up in my teams standup today. We were analyzing old dependencies and Lodash was in the list and none of us could justify why we needed it anymore. So I guess that point is nowish. Same for jQuery.

Different products/teams can move at different speeds if they target a specific market. For example, for internal apps teams can expect that browsers are up-to-date, or that even only a specific browser will ever run the app. Also, people who write JS for back-end (eg node.js) or an embedded engine can control the environment their code runs in, and can use more up-to-date features.

It’s similar to all the new tweaks and elements in HTML or DOM. If you’re working on Wikipedia, you will likely never get to use them. But if you work on a more niche app, they become quite useful. Over time, old browsers die out, and the amount of people who can use new features expands; early adopters do the testing for the late majority.

> we still need to target es5 4 years later,

This is a dramatic improvement over the 10 year lifespan of IE6 with es3. Once the need to target es5 drops, the next level gets even shorter - I don't think we'll get less than 2 years as a practical matter, but even at a 2 year delay, that's still regularly progress.

> a pretty arbitrary subset of the language

Best practices don't come from a mathematical model - programming is about communication and being compatible with user/business demands (which keep changing). Thus, best practices come about from a lot of experimentation and retrospective. That's ongoing. This doesn't mean it won't settle down. Heck, as it is, a lot of dynamic best practices influence the direction of non-dynamic languages - all of which arises from time and experimentation.

> If we still need to target es5 4 years later, and transpilation is standard practice, why bother?

Your “we” isn’t everyone else’s. Some places need to support very old browsers but even in places like that usually not every app does. Those people are pushing the state of the art forward since they do real work outside of the standards process and that provides useful feedback to both the standards committees and browser developers.

Fair, JS is everywhere and serves many use cases. The implicit "we" in that statement is developers 2019 who are building client side applications that need to get a lot done, run in most installed browsers, and remain maintainable to a 5-8 year horizon. Not everyone for certain, but probably enough to generalize, at least on this forum.

Again, that really depends on what features you use and who your clients are. It's entirely possible that a team may not need IE11 support now or that they've moved in the direction of low-overhead for modern clients and a legacy mode (possibly transpiled) for the <1% of people who affected.

At some point this is a business decision like anything else and the security considerations in particular have helped get people onto evergreen browsers faster than used to seem possible.

You tell such users: "Your browser is too old, please update it" and direct them to the Chrome and Firefox websites.

With the exception of Safari, all major browsers support auto-updating, and anybody who intentionally uses an outdated version of Safari is a masochist with a deviant fetish for error messages.

And in the idealized fantasy world of Ayn Rand, any giant dinosaur enterprise corporation who insists on using antique outdated Jurrasic browsers deserves to be bitch-slapped by the invisible hand of the market into extinction for their outrageously dangerous security and privacy policies.

To bad the real world doesn't work the same as it does in self-indulgent libertarian porn...

ha!

The real world works exactly like that. It's called System Requirements. If you want to use a piece of software, you look at the requirements and if you don't meet the requirements then you can't install it.

All websites have system requirements, no matter how non-libertarian they seek to be, for example most websites will not work on IE6.

It is not a fantasy to inform users that they don't meet the requirements, it is actually the courteous thing to do. If more websites were bold enough to inform users of their outdatedness then we would not be having this conversation.

I mean the real world is not like Atlas Shrugged, which is archetypical self-indulgent libertarian fantasy porn. The invisible hand isn't God setting things right and making life fair, it's rich assholes (who worship Ayn Rand and think they're God) rigging the system to cheat for themselves.

NSFW link:

https://www.cbsnews.com/news/ayn-rand-vs-the-invisible-hand-...

This is especially true for businesses. I've had a few cases where clients balked at browser support policies but when presented them with the cost multiplier it'd add, not to mention the cost of features / security, that clicked it into a calculation and suddenly it turned out that the “hard requirement” was actually one VP who refused to upgrade from IE5 Mac and they decided not to pay more for that.

Feature phones, smart-tv/watches etc. do not auto update. Old versions of android, iOS, Windows. Non-mainstream OS's running non-mainstream browsers. 1% of the market is still a lot of users.

Or y'know, someone who doesn't see a reason to purchase a new Apple device every N years of forced obsolescence.

> Is the evolution of JS not directed in practice by the authors of Babel and Typescript?

In practice? I suppose in practice, JavaScript is driven by everyone in aggregate and what people consider to be "JavaScript" rather than "something that can be made to run in traditional JavaScript environments like browsers." I'm not sure if you mean that, or simply who directs actual changes to the traditional JavaScript environments (like browsers) themselves.

But yeah, if transpilation tools are reliable and continue to be well-maintained, you can say "why bother updated the 'official' language and implementation in browsers?" But I don't understand how this is a bad thing. You're getting the best of both worlds: browsers will implement new JavaScript features and optimizations, and some dev teams can also use build tools to use those new features, and other potential new features, and still make their work available to older browsers.

It doesn't seem like a problem to me, unless you're thinking about all the language development effort in the JavaScript community as a fixed pie such that "non-official" language development like Babel and TypeScript take away effort that otherwise would be allocated to official language development. And I certainly don't think that is the case.

We're in the age of "evergreen" browsers, where almost everyone is on a browser that auto updates. New features can be useable in maybe 2 years now, depending on your audience.

[laughs in enterprise web app]

Those people should just stick to IE5 anyway.

How about simply compiling IE5 into WebAssembly, wouldn't that solve the problem? ;)

Equally honest counter-question: all modern browsers essentially support ES2019 already, so why would anyone still need babel outside of turning JSx into JS because React is still a hot tech, or in order to turn normal modern code into the kind of legacy code that >99% of your visitors won't need?

I'm sure there are plenty of build systems out there that still indiscriminately turn things into ES5, because "that's how we wrote it years ago and it still works", but anyone who actually cares about performance will think twice before using babel today to turn nice, clean, concise modern code into incredibly verbose and shimmed legacy code, and will certainly think twice before serving ES5 code to users on a modern browser.

There's a handful of unsupported features I play with... the null operators and pipelines in particular. But I do set my presets for pretty modern support as a baseline. I still use webpack as well.

Webpack is just a bundler, it doesn't turn modern code into overly verbose legacy code on its own. Babel's the real troublemaker because by default it's still acting like it's the original 6to5 package. Using it to turn draft features into working ES2018 is sensible, using it to convert all the way down to ES5 for anything that isn't IE11 (which is basically the only legacy browser left at this point), not so much.

Agreed. That's why my baseline is at least async support. Every modern browser has supported it for about 2 years now, and regenerator+asynch was the single biggest part of legacy transforms. I did have a second config for legacy, but at my current job was able to drop support, and just show unsupported browsers a message page now.

You only need to target old es if you're deploying a website for a big company. Most people don't need IE6 compat. For example, people writing node apps can choose which version of node they deploy.

Maybe I'm missing something, but they said es5, not es4?

I assume GP meant es5; es4 was an attempt to add static typing to JS and was never shipped. ActionScript 3 was the only implementation AFAIK.

Not true at all; With Node.js I don't have to wait for a browser to update, and V8 is often up-to-date with the latest stuff. And as a full-time JS dev, I have not gotten the feeling that the transpiler authors get to determine what's in the language. Honestly if they add anything that isn't destined to be part of the spec, I wouldn't use it because then you're tied into that transpiler for good.

A few off the top of my head:

1. Node.js greatly benefits from these features. Transpiling is not as prevalent there

2. Some people do exclusively target "evergreen" browsers and don't care about IE support

3. Those that do differential bundling (different bundles per browsers) can see quite a performance boost by not transpiling on newer browsers

Ad 2) It isn't just about IE anymore as more and more older machines become outphased for current OSes. E.g., for a 10 years old Mac Pro, which is still a viable machine, Firefox is currently the only evergreen option which is still receiving updates. (Safari is largely OS-dependent, as is WebKit, and Chrome/Chromium cancels support as soon as the OS is phased out.)

> If we still need to target es5 4 years later

This is only true if you're writing JavaScript for the client and you have to support IE11. For many companies, the usage for IE11 is so low now that it can be safely dropped, for instance my SaaS products all just target evergreen browsers.

It's still a moving target though. Either you transpile, and your target is just a config option, or you are in the business of being super selective about which "official" language features are ok to use for your user base. I can't imagine the business case for anything but write-anything, transpileto whatever the lowest common denominator of the day may be. Outside of one-off scripts, I don't imagine many browsers actually will be running any these new ES features until they become a compile target themselves in 8 years.

One place this works, when your clients are able and willing to use the latest browsers to use your software.

The primary benefit is that I don't have to rely on hacks.

This is how I build the backend to my CMS and my clients are happy to keep their browsers updated. (nearly trivial to do these days).

This also means that as soon as I see a new JS/CSS feature that will eventually become mainstream, I can use it in my admin as soon as both major browsers (Firefox/Chrome) support it. And even sooner if it's not a critical feature. (eg, I can skip adding a feature like "lazy loading" because browsers will have it built in eventually, etc...)

On the public facing front end, that is a different story though. It's motivation to keep things simple.

If you target modern browsers only, and if you're building non-web facing apps, you should be able to... you can absolutely use this stuff today.

Right now, for example, the apps I'm working on require at least async/await support as a minimum test.

I hear you. I look forward to seeing the (support) death of IE11 in 2025 (!!!), which is likely all too close to my own retirement.

Also about the “subset” thing: the last 10 years or so I have been moving away from OOP, and more towards FP, so stuff like class support or Typescript have been a big yawn, anyway.

We had “C with classes” (I.e. C++ as it was known at the time) shoved down our throats in Uni back in the 80s, since garbage collection was impractical. That “wisdom” turned out to be short lived, and thus my migration towards FP (beyond the Lisp I had in an AI class back in the 80s)

Having these features in the standard gives browsers and transpilers a common, well-specified target to work towards.

If you only need to support a subset of browsers you can turn off compilation/polyfills for specific features, which sometimes leads to better performance and smaller bundles.

I think of it like TypeScript and Babel running ahead experimenting with new ideas, ES following along turning the good ideas into a spec, and browsers taking up the rear implementing the spec. It’s a pretty decent system.

There are certain sectors in which backwards compatibility is important, but most people developing can confidently use ES2015+ features directly in the client without polyfill.

JS doesn't compile so all the runtime engines (mainly browsers) need to adopt the new features as well. This takes time. These new features are part of the official ES2019 standard, and Babel makes it possible to use these new language features and transpile it to a language that all the browsers can use. What's not to love? This is actually a great (if not amazing) thing.

In my experience, you don't really have to target es5 anymore. Most browsers support new features all the way through es2018. My Babel / Webpack config is pretty minimal these days.

Because, everything has been moving to evergreen browsers for desktop. If only the mobile devices would do the same, you could have a future where you would not have to.

I like TypeScript's (stage-3) approach to feature adoption.

Gating on stage-3 really helps. (I have done the same on projects I work on and it helps) There are times when you need to consider the complexity of the specification and the amount of contention around it (decorators / SIMD for example).

IMO, anything below that is effectively a custom macro anyway (for which you may want to consider sweet.js or babel.macro to make it clear that this may change and help you find places you use the feature). Real-world feedback may change anything from syntax to behavior (`flatMap -> flat`, `Object.observe -> Proxy`, `EventEmitter -> Observable -> Emitter?`, and the it-feels-like-dozens-of-options pipeline syntax)

It wasn't TS's idea, stage 3 exists purely for getting feedback from implementations about implementing and using the feature.

It was TS's 2.0+ idea to stick to Stage 3 like glue. Especially prior to 1.0, but even during 1.x, TS implemented proposals in stages earlier to 3 (or even not yet staged). One of the regrets you sometimes hear from TS devs is that they added decorators way too early (it's still not Stage 3 and increasingly likely if it ever hits Stage 3 it will look very different, and it may never hit Stage 3 because there is a bunch of opposition), even though that is behind an "experimental" flag, there's a huge amount of "Production" code written with decorators in Typescript. (Largely thanks to the Angular ecosystem that became hugely dependent on decorators.)

You don't necessarily need to target ES5.

What percentage of your users is on IE11? Are you making money from them? Can you serve only them a compiled bundle?

Almost all new features can be implemented is ES5 so instead of transpiling you can patch old engines. Eg. Array.prototype.flatmap

That's Array.prototype.flat

> If we still need to target es5 4 years later

You don't. Unless you care about IE11 (for most consumer products and mobile apps isn't necessary) you can use many of the features up through ES2016 or later without transpilation. My business uses JS classes, arrow and async functions, and new prototype methods without issue.

Are you proposing that we just never improve the language?

Reply on news.ycombinator.com