7 ms·

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

by simias 7y ago

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?

speeder 7y ago
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.
- kbp 7y ago
  Threads are C11, not C99.
qudat 7y ago
> 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.
- untog 7y ago
  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.
  - pault 7y ago
    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.
  - sdegutis 7y ago
    Versioning files is still a need too.
- fimdomeio 7y ago
  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.
pault 7y ago
> 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).
- WA9ACE 7y ago
  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 https://gitlab.com/WA9ACE/frontend-starter
  - alex_duf 7y ago
    That's an interesting project template. Manually managing dependencies and using backbone sounds quite fun!
- anthonybullard 7y ago
  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.
- LukeBMM 7y ago
  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. }
ken 7y ago
> 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.
- bfdm 7y ago
  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.
- jolmg 7y ago
  > 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.
  - dingo_bat 7y ago
    Maybe C++ programmers care about standards compliance. C programmers care about what gcc does.
- simias 7y ago
  >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 https://en.wikipedia.org/wiki/C99
saghm 7y ago
> 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?
- rictic 7y ago
  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.
syntheticcdo 7y ago
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.
- root_axis 7y ago
  Huh? The compiled JS will continue to work just fine for the end-user. Not sure what you're getting at.
  - semigroupoid 7y ago
    Sure, but JavaScript isn't compiled but typically interpreted (or JITed).
    - root_axis 7y ago
      Sure, but this is a distinction without a difference from the perspective of the end-user.
  - syntheticcdo 7y ago
    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.
    - root_axis 7y ago
deergomoo 7y ago
> 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.
rikroots 7y ago
> 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.
- mundo 7y ago
  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.
- JMTQp8lwXL 7y ago
  > 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.
pier25 7y ago
> 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.
tlarkworthy 7y ago
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.
masklinn 7y ago
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 https://gcc.gnu.org/c99status.html, it's unclear how up-to-date it is, and if GCC is still missing any required feature.

by simias 7y ago

speeder 7y ago

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.

kbp 7y ago
Threads are C11, not C99.

qudat 7y ago

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

untog 7y ago
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.
- pault 7y ago
  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.
- sdegutis 7y ago
  Versioning files is still a need too.
fimdomeio 7y ago
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.

pault 7y ago

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

WA9ACE 7y ago
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 https://gitlab.com/WA9ACE/frontend-starter
- alex_duf 7y ago
  That's an interesting project template. Manually managing dependencies and using backbone sounds quite fun!
anthonybullard 7y ago
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.
LukeBMM 7y ago
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. }

ken 7y ago

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

bfdm 7y ago
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.
jolmg 7y ago
> 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.
- dingo_bat 7y ago
  Maybe C++ programmers care about standards compliance. C programmers care about what gcc does.
simias 7y ago
>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 https://en.wikipedia.org/wiki/C99

saghm 7y ago

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

rictic 7y ago
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.

syntheticcdo 7y ago

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.

root_axis 7y ago
Huh? The compiled JS will continue to work just fine for the end-user. Not sure what you're getting at.
- semigroupoid 7y ago
  Sure, but JavaScript isn't compiled but typically interpreted (or JITed).
  - root_axis 7y ago
    Sure, but this is a distinction without a difference from the perspective of the end-user.
- syntheticcdo 7y ago
  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.
  - root_axis 7y ago

deergomoo 7y ago

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

rikroots 7y ago

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

mundo 7y ago
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.
JMTQp8lwXL 7y ago
> 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.

pier25 7y ago

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

tlarkworthy 7y ago

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.

masklinn 7y ago

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 https://gcc.gnu.org/c99status.html, it's unclear how up-to-date it is, and if GCC is still missing any required feature.