Why the fuck do startups only want Node.js developers?

File: gopher2.png (111KB, 1634x2224px) Image search: [Google]

111KB, 1634x2224px

Because they don't know about Go.

I heard it's easy to make those fancy electron apps and run them almost everywhere.

File: Cs0WzecUEAAzuZg.jpg-large.jpg (12KB, 626x104px) Image search: [Google]

12KB, 626x104px

>>59588698
Yeah, as long as you don't mind shipping 100MB binaries as a baseline.

>>59588741
When you could just do 10MB using Qt and C++, but no, C++ is not hip, JavaScript is.

We switched from .NET to Node.js at my large Enterprise work not too long ago. We have a lot less maintenance now and much faster time to market. That's not to say it's the best possible technology out there of course. It's just pretty good.

>>59588741
I'm not a big fan of it but for example right Spotify just werks and looks the same on Windows, GNU/Linux and macOS so if electron mean more support for GNU/Linux then I'm ok with high memory usage. VS Code a good example of a decent electron app except 13% cpu idle meme.

>>59588805
And no wonder why it doesn't work on FreeBSD and Wine.

>>59588827
this is irrelevant, nobody gives a flying fuck whether or not people using FreeBSD as their desktop OS can run a product via Wine. Nobody should ever give a fuck about this.

>>59588805
spotify just uses chromium embedded, from what I understand- the platform itself isn't the problem, it's the specifics of electron

>>59588773
You could do even less using C/C++ and no bullshit.

>>59588883
True.

>>59588674
They don't. Just the ones you're looking at.

It's not a language I'd ever choose, but .... you'll find you need to use the language of choice of the shop. Not your language of choice. Maybe the decision was made for non technical reasons, but it's work, so you suck it up and do it.

You want to work at one of those startups? Learn yourself some node. It won't be the last time you learn a new language or technology just to get a job.

>>59588674
Because a decent sized server application written with node.js is generally more performant than one written in C++, let alone Java, and takes 1/20th the time to make.
And don't bother arguing with me on this based on purely nothing but your preconceived notions when you haven't written an application for an every day web-app task in JS that's at least a few thousand lines, and also written something that does the same exact thing in C++, and benchmarked them on a large scale.

While the same performance improvements that are automatically done by the VM in JS can also be hand written in C/C++, considering that, no shit, V8 is written in C/C++, they take an inordinate amount of time and expertise which is the entire appeal of a self-optimizing VM which is what V8 has become.

It is also understood that it can easily be maintained indefinitely, which is less the case with Go (as much as Google dumps money into it), avoiding the Pascal/COBOL problem.

>>59588741
I tried it out and it was like 44mb.

I think there are slimmed down versions of Cordova that are in the 15-25mb range.

Sure, I've seen Electron apps like Duelyst using 800mb+ that should be using <200mb. That's a fault of shitty programming, which happens in every language, and not a fault of the minimum footprint of the binaries.

>>59589224
what frameworks do you use for your backend when developing websites/apps?

i've been meaning to learn ruby on rails so i can use it in API-only mode with react/redux for the front-end, but my ...mastery... of javascript makes me want to just use one of those js backends.

express? koa? feathers?

i was interested in feathers until i read that koa is a smaller, more robust version of express, made possible through the new generator functions

>>59588674
so they don't have to hire different people to do the front-end

>>59589280
I would go for Elixir, it's pretty amazing in production.

>>59589280
I use Golang as backend, and angular2 as a frontend. It's a pretty good mix. The guy that said elixr is also right, but it's hard to get a handle on it if you're not already familiar with it.

>>59588674
>>>59588674
>Because a decent sized server application written with node.js is generally more performant than one written in C++, let alone Java, and takes 1/20th the time to make.
>And don't bother arguing with me on this based on purely nothing but your preconceived notions

Fine. Link to some published benchmarks, that include the source code and document the server configurations used in testing. Then there will be no argument. Until then, this IS based on your preconceived notions, and vague memory of some benchmarks and blog posts.

Compared to compiled languages:
Faster development
No compiling wait time
Vast existing library that's as easy to set up as running one command, highly documented
No seg faults
No memory leaks
Easy debugging
Higher flexibility of integrating new features into existing code.

I work for Microsoft Office and we are slowly bleeding to death. 10,000+ engineers work on Office. A build takes 48 hours to complete, we have teams and entire websites to manage builds. We have teams to support those teams and websites to manage the build websites. Getting something simple like a custom dialog box to appear takes one to six weeks. Our standard procedure is if something is wrong, crash the app on purpose so that we can get a memory dump sent back to us. Everything is built in house and we have no documentation for any of it (aside from notes people just make for themselves). Having a team of 20 work just as fast as a team of 10,000 is a pretty good deal

>>59589665
I haven't checked on angular2 and I'm a bit behind on those front ends, but angular and all the others were much too slow.

I want to assume angular2 is as well, but I could simply be behind on them. I used to just write my own event-driven content updates.

>>59590811
-Compile time is pretty much nothing on a typical server application. And there are JIT tools to speed up development. But for millions of lines applications, yeah, for sure.
-"No seg faults" also isn't really true. node.js gets halt errors, even though you can suppress them I guess.
-Something similar to memory leaks also can happen in JS if you program shittier. Obviously far easier to avoid and way less consequential when they DO happen.

The rest are true, though. Especially the existing libraries (more open source JS than like all other languages combined, much of with are NPM modules), and easier debugging. Even though there are great debugging libraries for other languages to try to pretty much mimic JS ones, they still don't come close.

One of the biggest things you point out that's often overlooked is your last
>Higher flexibility of integrating new features into existing code.
C++ and Java became popular on this idea that classes would be able to be copied around from one application to the next. That turned out to be complete bullshit.
node.js and NPM was the first thing to really, truly, deliver on that promise from 20+ years ago.
You can drop any correctly made NPM module into any application you have and it just works, independent of everything else you're using.
Classes are usually shit and shouldn't be used more than 95% of the time someone /thinks/ they need a class. A non-conflicting library with a good API is tops.

>>59590811
That sounds like an issue with technical debt and corporate politics, not compiled code.

Millions of people work on Linux, 15mil+ lines of code, compiles under a day even if compiling everything, reasonably easy to make changes.

>>59592299
>Classes are usually shit
+9000

Classes suck ass. You're always better off using structs and functions until you're 100% sure in hindsight that a struct+functions should be a class.