5 ms·

I programmed assembly then C then C++ through the the 80s, 90s and 2000s. I love JavsScript. It just so damn easy. No fighting with headers, include paths, link

I programmed assembly then C then C++ through the the 80s, 90s and 2000s. I love JavsScript. It just so damn easy. No fighting with headers, include paths, linker options, make files , cmake files, scons files, etc. No cross platform bs. When I want to share I just send a link. Electron does have a few platform issues to build the app but they're most solved for me. I get formatting, styles, animation, for free. I get cross platform graphics, video, and audio for free, networking is trivial. I also get pretty amazing debugging tools. 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.

megaman22 9y ago
> No fighting with headers, include paths, linker options, make files , cmake files, scons files, etc 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.
- jeeberz 9y ago
  I hear you but since I've been using yarn to lock all package versions I haven't had any issues. https://yarnpkg.com/lang/en/docs/yarn-lock/ https://yarnpkg.com/lang/en/docs/yarn-lock/ JS development without yarn is complete madness.
  - merb 9y ago
    which means that you do not use a npm proxy.
- aprdm 9y ago
  You can just build a RPM package with your dependencies and another with the dist result. 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?
wruza 9y ago
>No fighting with headers, include paths, linker options, make files , cmake files, scons files, etc 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.
Yetanfou 9y ago
I get formatting, styles, animation, for free. I get cross platform graphics, video, and audio for free That is only true if by "for free" you mean you (or your users) get to exchange an oversized portion of their free memory and CPU cycles for those things. Better hope those users have at least as powerful a system as you do or they'll be looking elsewhere for their text editor, cooperative workbench or IDE.
blunte 9y ago
If you went from asm/c/c++ to js, and you didn't use a half dozen other languages including Python, Ruby, and even Java back in the day, then it's no wonder you're happy with JavaScript. 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!

megaman22 9y ago

> No fighting with headers, include paths, linker options, make files , cmake files, scons files, etc 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.

jeeberz 9y ago
I hear you but since I've been using yarn to lock all package versions I haven't had any issues. https://yarnpkg.com/lang/en/docs/yarn-lock/ https://yarnpkg.com/lang/en/docs/yarn-lock/ JS development without yarn is complete madness.
- merb 9y ago
  which means that you do not use a npm proxy.
aprdm 9y ago
You can just build a RPM package with your dependencies and another with the dist result. 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?

wruza 9y ago

>No fighting with headers, include paths, linker options, make files , cmake files, scons files, etc 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.

Yetanfou 9y ago

I get formatting, styles, animation, for free. I get cross platform graphics, video, and audio for free That is only true if by "for free" you mean you (or your users) get to exchange an oversized portion of their free memory and CPU cycles for those things. Better hope those users have at least as powerful a system as you do or they'll be looking elsewhere for their text editor, cooperative workbench or IDE.

blunte 9y ago

If you went from asm/c/c++ to js, and you didn't use a half dozen other languages including Python, Ruby, and even Java back in the day, then it's no wonder you're happy with JavaScript. 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!