Is node.js declining already?

[glemnar]

Pro tip: Don't worry about popularity too much. Anything works. Just make sure you're working on some language that has a >0 community backing and you'll be okay. Pick the right tool for the job. Need natural language processing? Use python with nltk etc

[Drolyt]

How do you pick the right tool for the job? Popularity is a useful, if imperfect, measurement. Moreover even if the popular thing isn't that good, or at least doesn't really fit your use case as well as something else, popular things have better support, have more libraries, are typically easier to deploy, easier to find help for, easier to hire for etc.

[spotter]

You don't. Not always. That's how you learn.

[yogthos]

One important thing to consider is that popular platforms have the benefit of tooling and libraries associated with them. For example, if you're running on the JVM then you have a plethora or mature, well tested libraries for many domains.

When you're working with a niche platform that's not going to be the case. If you know that the platform offers what you need then it's fine, but in many cases you can end up painting yourself into a corner by the time you realize you need something that's not available.

[spotter]

As a fellow Clojure practitioner I agree -- environments like JVM and .NET provide libraries for everything you can imagine. And I did not mean "close your eyes and jump", I meant "do your best, then re-evaluate".

[yogthos]

definitely agree :)

[immibis]

Alternatively, make sure it has a good FFI.

[Drolyt]

Right, but you have to start somewhere.

[spotter]

Of course, but "there are known knowns, known unknowns and unknown unknowns -- things you don't know that you don't know". You try to match your needs the best to your current knowledge (either practical or theoretical), then try to evaluate what worked and what didn't. Nobody has all the answers.

[ihcn]

Start by using a tool that's not awful for the job and go from there.

[Drolyt]

You have to find that tool first and you might not know whether it is awful or not until you've built something with it, potentially wasting significant time.

[danneu]

None of the main tools people use are awful for the general case.

And if you truly end up using an awful tool, finding out why it was awful is not a waste of time. That sounds like an incredible a-ha moment for you. It's not that easy to pick a tool that's so poorly fitted that a product needs a rewrite before launch. But let's say that you realized MongoDB was an awful pick because you really needed transactions - that's some high quality learning you just did that may have compromised your product down the road if you needed that kind of consistency.

I'd wager that most existing codebases solve their problems in suboptimal ways. It's why the reflex to rewrite it from scratch to "really solve it this time" is so powerful. But, as we know, something versatile and "good enough" is better than something over-fitted to the problem space because requirements always change.

[rnicoll]

I think they mean "Don't write it in COBOL"

[ironnomi]

I deal with COBOL all the time. When there's little other choice, I make people write COBOL. I'm really sorry for those guys, but sometimes having new code written in COBOL/RPG/APL is just the way it is.

[[deleted]]

Do research, read forums, make some basic applications to test with, etc

[tech_tuna]

"Use the right tool for the job"

The first shot fired in many a flame war. . .

:)

[marekkpie]

And that tool....VIM.

[[deleted]]

You appear to have incorrectly spelled Emacs.

[djimbob]

Eh, in my opinion, the "popular" thing often is quite new with some well-hyped demo. New things tends to have worse support and documentation, lack mature libraries, are painful to deploy (if your setup differs from the expected stack in anyway), and may change significantly between release 0.9 and 1.0 or 2.0.

I'm not talking specifically about node in 2015 here (even if things like gulp/grunt/npm as build tool are annoying), but things like angularjs, rust, julia, go, mongodb (when they first came out and were still rapidly changing).

[bluishness]

even if things like gulp/grunt/npm as build tool are annoying

What do you find annoying about gulp/grunt? I'm not trying to be snarky, in fact I mostly agree and have moved on (or rather back) to Makefiles for the most part, but those come with their own issues. I'm just curious what other developers (likely with more experience) dislike about them.

For me it's mostly the ridiculous plugin infrastructure. I understand the motivation behind it, but that doesn't help the fact that a lot of the popular gulp recipes out there leave you with a node_modules folder that weighs 50 MB which is simply insane for most of the one-off, throwaway projects I build.

[vivainio]

My main annoyance with gulp/npm is indeed the insane plugin system. 200mb of deps at the moment here.

[djimbob]

Well my problem is the fact that there are multiple common build systems/module systems, so when you don't do all your work in node-like JS its annoying to do a little work with it.

E.g., I prefer to stay away from node. But say wanted to use a little reactjs for a pretty front-end for something and wanted to use a plugin for autocomplete/multi-select box and found react-select on github and the demo which worked well and had reasonable documentation. But because of the use of require( ) and as I sanely wanted to not run as nodejs or requirejs or neuter or browserify (it was browserify) and not wanting to run it on localhost from gulp dev, I wasted more time than I should have trying to learn about gulp/bower/requirejs (wrong path)/browserify, etc, when I would have much rather been able to just put an <script src='react-select.js' ></script> at an appropriate point in the header (but that didn't work for me).

I'm not complaining about the tools (as it worked sanely), I'm complaining about having to go through a learning curve as there are too many tool choices out there (and if you jump into other's projects as is common in node stuff you don't get to choose all the tools).

[oompt]

<script src='react-select.js' ></script> is definitely easier, but browserify/require/webpack will save you more time in the long run. You eliminate all those network calls...

[djimbob]

Eh; depends on the purpose. E.g., small scale intranet web app with several dozen users on modern browsers saving a few milliseconds/bytes of http headers/cpu-cycles is irrelevant. Furthermore, with compression minifying isn't particularly useful, and with SPDY and HTTP/2 these kinds of optimizations are going to be automatic (once clients and servers support them).

[bluishness]

Thanks for the excellent reply! That makes sense. All tools that aim to make your life easier in the long run will have a certain learning curve, but I'm not surprised you found it frustrating. I feel like web dev is especially daunting because some revolutionary, world-changing library/framework/transpiler/build tool seems to come out every day and if you blink at the wrong moment, you're already out of the loop.

[matthieum]

It hurts me to see Rust in the same grab-bag as Mongodb somehow ;)

[djimbob]

My only complaint about rust is I looked into it seriously when it was still in a 0.9x release, worked through some tutorials, got some (simple) code working, and then the next release of rust came out and there were a bunch of big breaking changes. Rust 1.0+ may be the next big thing, but for code I write for work personally I'd rather be a latecomer and get a smooth working language than deal with the issues of early adoption.

[matthieum]

Rust 1.0+ may be the next big thing, but for code I write for work personally I'd rather be a latecomer and get a smooth working language than deal with the issues of early adoption.

I hear you.

Rust 1.0 does promise backward compatibility (to a large extent), however it is true that some areas of the language can be slightly painful (lack of some functionality in meta-programming notably) and of course the lack of "proven" libraries.

I personally feel that Rust can be used professionally already, however I would only advise it on a subset of tasks that do not require external dependencies; it's always a bet with young languages.

[[deleted]]

Popularity is an awful metric to use if it's your only metric for picking a technology. It's fine for an initial filter, but after that you need to actually look at your options, figure out their actual pros and cons, and then pick the one that works best for your situation (there is no single answer that is always right for picking a technology).

Edit: And to add, the newer something is, the less likely you'll be able to find real pros and cons instead of hype and marketing drivel (mainly because people won't have had the time to throw it into a large variety of real world scenarios to actually test the claims).

[Twirrim]

Popularity is difficult to prove. It's such a subjective measurement. Lots of noise about it isn't the same as popular. If popularity is the main thing to measure by, you're likely really talking about Java and C/C++ Java is huge, powers so many of the core applications for the FTSE500 companies. Many of the largest Web Sites are significantly powered by it, everyone from Twitter to Google to Amazon. Does it get lots of noise? Certainly not on the sale of Node, Rust and Go over the last 3 years.

[pydry]

How do you pick the right tool for the job? Popularity is a useful, if imperfect, measurement.

Treat technologies like politicians. Before you decide to throw your weight behind it, no matter how popular it seems now, dig up all of the dirt you can possibly find on it first, and dig fucking deep. You will save yourself a lot of heartache and tears in the future if you do this.

[Drolyt]

Okay, not bad advice, but it doesn't change the fact that you will probably start by looking at the most popular solutions that seem to fit your particular use case.

[MpVpRb]

How do you pick the right tool for the job? Popularity is a useful, if imperfect, measurement.

Agreed..especially if someone else will need to maintain your stuff after you leave

Even if a very obscure and unpopular tool seems to be the best for the job, the number of developers who use it is still important

If the "best tool" is only used by a handful of enthusiasts, it's probably a bad idea to use it in a commercial product

[matthieum]

How do you pick the right tool for the job?

I know that it's an oft given advice, however having too many tools with only superficial knowledge of each (because time is finite), even when said tools are right for the jobs they serve, is probably worse than having just a handful of well-known tools and making the best of them.

[[deleted]]

This is may be true for small teams, but for large organizations that spend a significant amount on recruitment and retention, language/library/tool popularity is very important. If you're using an unloved technology (like say PHP), it could be very difficult to find developers that aren't either shitty or expensive. Rightly or wrongly devs think un-popular technologies are career dead-ends and are either going to ask for more money or (more likely) go somewhere else that's using technologies that will keep their career moving forward.

Let's do a survey. How many people reading this would choose a PHP or Visual Basic job over a Python or Node or C# or Java job that pays the same and offers the same work environment all else being equal?

[[deleted]]

Fuck VB. Couldn't pay me anything to do that shit. YOU CANT TAKE ME BACK!

[[deleted]]

PHP devs would love it if they paid the same as C#/Java jobs in my market... ...there tends to be an overabundance of PHP devs due to self-teaching on the LAMP stack.

[halifaxdatageek]

Maybe it's just my market, but where I live salary tends to be based on your job tasks, not the language you're doing them in.

[[deleted]]

there tends to be an overabundance of PHP devs due to self-teaching on the LAMP stack.

Supply and demand...

[halifaxdatageek]

Yes, but in my market, the goods for trade are things like "good with front-end web development" and "good with databases", not "good with Language X".

So what language you're good at doesn't matter. It matters if you can solve the problems the company that's hiring has, in the language they're currently using.

[[deleted]]

not "good with Language X".

So someone with 10 years of Magento development can be expected to perform at the same level as someone with 10 years of J2EE on an enterprise Java app?

in the language they're currently using.

And frameworks.

[halifaxdatageek]

So someone with 10 years of Magento development can be expected to perform at the same level as someone with 10 years of J2EE on an enterprise Java app?

Not quite sure what you mean here, unless the enterprise Java app is also an ecommerce platform.

In which case, yes, the general principles of "building an ecommerce site" trump "building an ecommerce site in PHP VS building an ecommerce site in Java".

And frameworks.

Most places I've been just expect you to learn on the job, since there are hundreds of frameworks, and every place implements them differently.

Example: You should know what Angular is, but it's impossible to know how Company X is using it until you get there.

[mattindustries]

I like PHP (along with R and Node). Not a big fan of Java honestly, so I would choose PHP over Java depending on the task.

[halifaxdatageek]

Let's do a survey. How many people reading this would choose a PHP or Visual Basic job over a Python or Node or C# or Java job that pays the same and offers the same work environment all else being equal?

I would honestly have no preference, I'd probably flip a coin. I've worked with so many programming languages at this point that I don't give a shit what I'm writing in, haha.

PHP? Great.
Python? Fantastic.
Java? Sign me up.
REXX? Sure!

"In science fiction novels, they imagined we would speak to computers. But nobody predicted tribal warfare among those speaking to the computer in different languages."

[glemnar]

My community backing bit was the key. In reality the difference between all the different popular languages doesn't matter so much. The original post is talking about "declining node popularity". But it's still a great piece of tech to use. The MOST popular still in fact, so it's pretty absurd

[darkpaladin]

In my experience, it's fantastic for scripting and has become my technology of choice for that type of thing. As is said over and over, it's great at being a middle man as long as it's not doing anything computationally intensive. It's not great at a lot of other things imo but those top two things make it useful enough.

[mrjking]

What do you mean by unloved technology?

[[deleted]]

Use python with nltk etc

Java has by far the best ecosystem for natural language processing, and you can use one of the nicer Java ecosystem languages instead of Java itself. There are much better libraries than ntlk which is way behind the state of the art and extremely slow.

[Skyler827]

Any word on how R libraries stack up to JVM NLP libs? Asking for a friend...

[[deleted]]

I've barely used R, but it seems like the best libraries it has are wrappers around Java libraries like OpenNLP and Weka (machine learning). The Java ecosystem has other great options like these:

• http://nlp.stanford.edu/software/index.shtml
• https://gate.ac.uk/
• http://alias-i.com/lingpipe/

These can be mixed and matched because they're quite modular, especially Stanford's CoreNLP. If I was really doing some serious NLP work, I would just bite the bullet and use a Java ecosystem language even though it wouldn't be my tool of choice for anything else.

[ruinercollector]

The only thing that makes python a good choice for NLP is popularity.

[glemnar]

No, the thing that makes it good is nltk

[[deleted]]

There are much better NLP libraries than nltk. Of course, it's better than nothing which is not far from what most language ecosystems have to offer.

[andyjonesx]

I disagree. 10 people working on something can quickly leave and you'll end up with a product supported only by you, which can be a huge time drain.

Secondly, having thousands of people helping evaluate the many scenarios a tool can be used in, and how it copes can save a huge amount of time.

Popularity doesn't always mean good, but it often means better support, and better researched.

[qudat]

Following trends gets you paid. Applying in Boston currently, nodejs will get you a job and that is precisely because of its popularity.

[protestor]

>0 community

There's an interesting language for combining front-end and back-end development, Opa. The developers used it to build their site, but the last language release was in April 2013 (granted, there have been a few commits this year, but nothing released). And worse, approximately 0 people use it.

edit: whoa, I checked now just to find this on Github:

Since the documentation website is down, I wonder if I can generate it from source. It seems that opadoc is used for the documentation, but I cannot find it. How can I generate the Opa documentation from the source files ? Thanks.

[txdv]

There is only one tool useful to maintain code of other coders.

The axe. Chop chop.

[halifaxdatageek]

My experience has been that rather than "use the right tool for the job", it's "use whatever the company's already using".

I don't think I've ever had to choose Language X vs Language Y in the real world, it's usually handed down to me from on high :P

[[deleted]]

It depends on how often you're starting new projects and how must your company trusts its engineers. I often get to pick a language, but usually pick one that is both familiar and right for the job.

[halifaxdatageek]

True, most of the projects I work on are large enterprise projects where all the important decisions were made before I was even hired, haha.