6 ms·

> Maybe it's because I've never been a webdev but I just don't understand the fascination with JavaScript. 1) It's the only true "write once, run everywhere" l

> Maybe it's because I've never been a webdev but I just don't understand the fascination with JavaScript. 1) It's the only true "write once, run everywhere" language out there (along with languages that transpile to JS). 2) npm 3) Asynchronous I/O

dullgiulio 9y ago
Javascript "fame" came before npm/Node.js and before it had any idea async/await would ever be implemented. Simply put, Javascript is the only language in the browser.
- austincheney 9y ago
  Yes, but not much before. It took heavy evangelism and Google Chrome's JIT to make JavaScript popular about 10 years ago.
  - dullgiulio 9y ago
    Maybe you don't remember the early 2000s when people were adding flying butterflies around the cursor with Javascript? Recently there has been hype and explosion but web development (development on the browser, which means Javascript for lack of alternatives) had a long way coming.
- crandycodes 9y ago
  Asynchronous I/O refers to the fact that all I/O interactions default to being asynchronous in JS, not the fancy new `await` keyword, which is nice, but just sugar around Promises. The result of this default is that makes a best practice into a feature, not something I have to manage as a developer.
  - goatlover 9y ago
    Because of Node or the browser's event loop? It's not like JS was the first language to have a built-in event loop. Visual Basic did exist.
wruza 9y ago
The only true “write once run everywhere” is ANSI C, please don’t overestimate js in that regard. Unless you’re using polyfills and babels, it is feature-detection hell never ever imagined on desktop or embedded. Asynchronous, parallel or progressive io existed since forever, and barely is an exclusive property of js. Moreover, it is not required from application programmer, unless the platform is built in a way that it is impossible to avoid.
- com2kid 9y ago
  > The only true “write once run everywhere” is ANSI C, Sure, until your pointer size varies from platform, or LONG is 64bits on one platform and 32bits on another. Don't forget compiler support, which version of C are you using? Does the compiler support it everywhere? C runs everywhere with sufficient #IFDEFs.
  - wruza 9y ago
    If C code incorrectly depends on specific type sizes or is written for less portable standard than ANSI C or can be compiled with non-compliant compiler only, then it will be less or non-portable. You can argue that these restrictions allow less freedom of expression and more quirks in some cases, but the same applies to js without polyfills and babels, because these are effectively ifdefs and compilers. The one main difference is that correct C code actually can be deployed to a variety of platforms unavailable to javascript, which is runnable on just few selected powerful environments with heavy help of what is called compat-libs in non-web world. Moreover, with all these compat layers you cannot just take js code and use it in non-hosted environment; that’s why everything runs in embedded node/webkit. This is barely portable, and I think you’re confusing [seeming] ubiquity and with actual portability (like “everywhere”).
    - com2kid 9y ago
      > If C code incorrectly depends on specific type sizes Now days C includes wonderful things such as int64_t and int32_t. Before those existed, life was hard. Everyone had to implement their own type system abstraction layer on top of C, for good reasons. Making a structure that maps to a network data packet is irritating when the underlying types of the language vary in size from platform to platform. Thus the million different prefixed IFDEF'd type systems in headers. The size of an enum is up to the compiler. Some optimize so that enums with less than 256 elements will have 8bit values, other compiler's don't, always setting size as 32bit. Simple solution is to set a value at the end of the enum to 0xffffffffu, but I've had teams I've worked on shy away from using enums for data modeling specifically because of how the C spec defines them. #pragma pack not being part of the spec also causes headaches. I get why, some platforms don't support unaligned access (heck, ARM up until relatively recently). Most modern compilers implement it, and it'd be nice if the standard laid down a single, opt-in, syntax for compilers to use. Even with pack, #pragma push and pop are not implemented everywhere, so you there is still this mess of cross-plat code that is needed. (#pragma push and pop are seriously useful, also possible to get in a lot of trouble with them!) All this can be worked around, but it very much makes C not write once run everywhere. It is write once, adapt for a bunch of platform inconsistencies, run most places until it segfaults, fix the segfault, run again, hope it works until some new platform is brought up. I'm not saying JS runs everywhere, far from it. It is true that there is a C compiler for almost every platform, but for the deep embedded platforms, the C code is very much custom. Just a few years ago, a product I worked on had an 8bit micro on it with 256 byte memory pages. It was attached to a Cortex M4 with 256KB of SRAM. The Cortex M4 had more memory hanging off an external bus. A huge chunk of the code for all of this cross-compiled to run on Windows with lots of mocks for the hardware, including the entire Flash file system. Each of the embedded systems relied on compiler intrinsics, accessing magic memory addresses, and the rare drop to raw assembly. Getting the code cross platform was less IFDEF's than one would imagine, mostly because code was kept in separate _win32.c/_arm.c files, and each file started with a giant #IFDEF(__win32) or #IFDEF(__ARM) (best way to do this IMHO, throw *.c into the build system, let the preprocessor figure it out). C may be supported everywhere, but making the same C code run everywhere is a huge hassle. In comparison, cross-plat JS engines (e.g. Node) don't scale down nearly so much, but when they are brought to a platform, everything is going to be the same. The abstraction layer provided is a lot more robust, by design. Two very different goals. Lua and Forth programmers all think this is silly, since their languages really do run everywhere. :-D
blunte 9y ago
I'm confused. Are you naming npm as a plus? 5,000 individual downloads/dependencies to use a library that you could hand write in a couple of hours... not to mention embarrassing events like left-pad...
- olalonde 9y ago
  > 5,000 individual downloads/dependencies to use a library that you could hand write in a couple of hours... Yes, that's a trade I'm always willing to do. I'd rather use those couple of hours to write something new or spend some time with the family. "left-pad" was a minor annoyance that was quickly resolved.
- Can_Not 9y ago
  Leftpad, a one time event that was fixed very quickly with a solid permanent solution? Being able to use libraries that 5,000+ other people have already vetted for quality for you so you don't have to waste a couple of hours hand writing them? That's 2 pluses right there.

dullgiulio 9y ago

Javascript "fame" came before npm/Node.js and before it had any idea async/await would ever be implemented. Simply put, Javascript is the only language in the browser.

austincheney 9y ago
Yes, but not much before. It took heavy evangelism and Google Chrome's JIT to make JavaScript popular about 10 years ago.
- dullgiulio 9y ago
  Maybe you don't remember the early 2000s when people were adding flying butterflies around the cursor with Javascript? Recently there has been hype and explosion but web development (development on the browser, which means Javascript for lack of alternatives) had a long way coming.
crandycodes 9y ago
Asynchronous I/O refers to the fact that all I/O interactions default to being asynchronous in JS, not the fancy new `await` keyword, which is nice, but just sugar around Promises. The result of this default is that makes a best practice into a feature, not something I have to manage as a developer.
- goatlover 9y ago
  Because of Node or the browser's event loop? It's not like JS was the first language to have a built-in event loop. Visual Basic did exist.

wruza 9y ago

The only true “write once run everywhere” is ANSI C, please don’t overestimate js in that regard. Unless you’re using polyfills and babels, it is feature-detection hell never ever imagined on desktop or embedded. Asynchronous, parallel or progressive io existed since forever, and barely is an exclusive property of js. Moreover, it is not required from application programmer, unless the platform is built in a way that it is impossible to avoid.

com2kid 9y ago
> The only true “write once run everywhere” is ANSI C, Sure, until your pointer size varies from platform, or LONG is 64bits on one platform and 32bits on another. Don't forget compiler support, which version of C are you using? Does the compiler support it everywhere? C runs everywhere with sufficient #IFDEFs.
- wruza 9y ago
  If C code incorrectly depends on specific type sizes or is written for less portable standard than ANSI C or can be compiled with non-compliant compiler only, then it will be less or non-portable. You can argue that these restrictions allow less freedom of expression and more quirks in some cases, but the same applies to js without polyfills and babels, because these are effectively ifdefs and compilers. The one main difference is that correct C code actually can be deployed to a variety of platforms unavailable to javascript, which is runnable on just few selected powerful environments with heavy help of what is called compat-libs in non-web world. Moreover, with all these compat layers you cannot just take js code and use it in non-hosted environment; that’s why everything runs in embedded node/webkit. This is barely portable, and I think you’re confusing [seeming] ubiquity and with actual portability (like “everywhere”).
  - com2kid 9y ago
    > If C code incorrectly depends on specific type sizes Now days C includes wonderful things such as int64_t and int32_t. Before those existed, life was hard. Everyone had to implement their own type system abstraction layer on top of C, for good reasons. Making a structure that maps to a network data packet is irritating when the underlying types of the language vary in size from platform to platform. Thus the million different prefixed IFDEF'd type systems in headers. The size of an enum is up to the compiler. Some optimize so that enums with less than 256 elements will have 8bit values, other compiler's don't, always setting size as 32bit. Simple solution is to set a value at the end of the enum to 0xffffffffu, but I've had teams I've worked on shy away from using enums for data modeling specifically because of how the C spec defines them. #pragma pack not being part of the spec also causes headaches. I get why, some platforms don't support unaligned access (heck, ARM up until relatively recently). Most modern compilers implement it, and it'd be nice if the standard laid down a single, opt-in, syntax for compilers to use. Even with pack, #pragma push and pop are not implemented everywhere, so you there is still this mess of cross-plat code that is needed. (#pragma push and pop are seriously useful, also possible to get in a lot of trouble with them!) All this can be worked around, but it very much makes C not write once run everywhere. It is write once, adapt for a bunch of platform inconsistencies, run most places until it segfaults, fix the segfault, run again, hope it works until some new platform is brought up. I'm not saying JS runs everywhere, far from it. It is true that there is a C compiler for almost every platform, but for the deep embedded platforms, the C code is very much custom. Just a few years ago, a product I worked on had an 8bit micro on it with 256 byte memory pages. It was attached to a Cortex M4 with 256KB of SRAM. The Cortex M4 had more memory hanging off an external bus. A huge chunk of the code for all of this cross-compiled to run on Windows with lots of mocks for the hardware, including the entire Flash file system. Each of the embedded systems relied on compiler intrinsics, accessing magic memory addresses, and the rare drop to raw assembly. Getting the code cross platform was less IFDEF's than one would imagine, mostly because code was kept in separate _win32.c/_arm.c files, and each file started with a giant #IFDEF(__win32) or #IFDEF(__ARM) (best way to do this IMHO, throw *.c into the build system, let the preprocessor figure it out). C may be supported everywhere, but making the same C code run everywhere is a huge hassle. In comparison, cross-plat JS engines (e.g. Node) don't scale down nearly so much, but when they are brought to a platform, everything is going to be the same. The abstraction layer provided is a lot more robust, by design. Two very different goals. Lua and Forth programmers all think this is silly, since their languages really do run everywhere. :-D

blunte 9y ago

I'm confused. Are you naming npm as a plus? 5,000 individual downloads/dependencies to use a library that you could hand write in a couple of hours... not to mention embarrassing events like left-pad...

olalonde 9y ago
> 5,000 individual downloads/dependencies to use a library that you could hand write in a couple of hours... Yes, that's a trade I'm always willing to do. I'd rather use those couple of hours to write something new or spend some time with the family. "left-pad" was a minor annoyance that was quickly resolved.
Can_Not 9y ago
Leftpad, a one time event that was fixed very quickly with a solid permanent solution? Being able to use libraries that 5,000+ other people have already vetted for quality for you so you don't have to waste a couple of hours hand writing them? That's 2 pluses right there.