Maybe it's because I've never been a webdev but I just don't understand the fascination with JavaScript. Personally I hate JavaScript any time I have to code in it. Give me literally any other language.
iteration time is orders of magnitude faster than any C/C++ project I've ever worked on.
I hated JavaScript at first because I didn't understand it. It took about 2 year to stop trying to turn in back into C++. It didn't help that my first real intro was in an environment that used Google Closure and the closure compiler both of which were designed by Java programmers to try to treat JavaScript as Java and disallowed real JavaScript.
now I mostly loath going back to C++ and having to fight the dev tools on each platform which seem to change every 5 years such that all old samples fail.
is it JS perfect? no, i think I kind of miss static typing but not always. It's often a joy to just do it.
Instead you get to fight with often poorly-versioned bower/npm dependency hell, and gulp/grunt/webpack config errors with inscrutable messages.
> having to fight the dev tools on each platform which seem to change every 5 years such that all old samples fail.
Such stability! If anything in javascript still works five months later, I count my lucky stars.
https://yarnpkg.com/lang/en/docs/yarn-lock/
JS development without yarn is complete madness.
We have something like that,
node_modules for some project goes to a rpm called $project_name-devel
and the result goes to $project_name
Is not really that complicated and then we don't rely on anything outside of our control (e.g: github, npm)
We never had an issue with this workflow. Our dependencies (the devel package) changes maybe once every two months if so?
These downsides only appear when you’re working on project that did it wrong way. Thousand-line autogenerated makefiles, pkg-config-unaware craplibs with headers based on different basedirs (Qt, I’m looking at you), idiots who think that using cmake/qmake/etc will magically ensure buildability on different platforms and never ever test that it does build there.
In pure js you don’t have include/dependecy problem simply because there is no require/include option at all. Then you install node/npm with 100Mb of js backing it aaand it is yet another complex toolkit to learn forever. With no man pages and shady internet snippets. My hate of js comes from different direction though — I know it and it is ugly simpleton that dooms you to boilerplate, polyfill and spaghettize everything. Debuggers help until you get a “framework” that turns everything upside down and whirls.
I’m sharing your every 5 years annoyance though, even non-web does too much change for the sake of change. No good ui also, you’re right. This comment was meant to be a counter-argument, but it appears that both worlds are crap.
I get formatting, styles, animation, for free. I get cross platform graphics, video, and audio for free
That's like saying that chalk tastes so much better and is so much easier to digest than gravel. However, it's good to be happy with a language... so if it works for you, great!
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
Simply put, Javascript is the only language in the browser.
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.
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.
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.
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”).
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
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.
The Stockholm syndrome around using browser technology everywhere, just because you've been brutalized into learning its wrinkles to work on the web, is scary.
clone this repo, follow steps at bottom of readme, ship on 3 platforms
If all you need is an action button to trigger some underlying code, then those hello-world products are very simple.
Electron is NOT that easy to use of a platform. In fact, it's quite technical and requires a lot of knowledge about node and HTML/CSS. It requires that the developer understand you're running a node process that feeds its results to a browser that has a native chrome.
Visual Studio Code and Slack for example have native plugins that light-up the various platform's features. So you're never completely guarded from having to write native code. At the end of the day it's just another UI toolkit and language choice you can make when building out your software.
HTML/CSS are already something with massive widespread know-how and insane numbers of online resources. That's a huge deal. This takes every web developer and makes them a cross-platform desktop app developer with no additional learning.
A developer with the caliber required to solve those problems will be comfortable in any language they are asked to write in.
The point is that Electron is cross platform. Building three different native apps with completely different UI toolkits is a huge amount of work and depends on much less common skillsets.
And yet, this hypothetical person wants to write an Electron app to run on desktops?
I don't get this argument. If you are good enough to understand how to write and deploy an Electron app, you should certainly be able to understand Eclipse.
Note: I'm not advocating for Java here...
But Electron is a there for a different reason. I can convert my SPA to a working desktop app with minimal coding (same Css/js front end/ja backend, if you use nodeJs). And even it works for all major platforms. So I literally have one codebase for web and all three desktop platforms.. beat that!
I know it's not optimal to have everyone open a chromium instance under the hood but how bad is it from JVM?
And with Java, I have the option to have an actual binary, 100% native code, if I feel inclined to do so.
Something that many Java haters keep being unaware of.
I'm torn between JS and PHP for the language I have the least fun programming in.
Native lexical scope. Do more with less and write/test it in a fraction of the time. Seriously, a couple of rockstar JavaScript devs could easily replace a large department of equally skilled Java developers.