
Ask HN: Why learn non-JS languages/framework? - ziikutv
Hello HN,<p>At the risk of sounding completely stupid, why would I want to learn things like Rails, MVC5, Django over something in Javascript&#x2F;Node?<p>It seems there are significant advancements being made in the JS world compared to others.<p>I am a die hard Python lover, but I do not know what do to at this situation.
======
Kronopath
This feels like what happens when a web developer fails to realize that the
web is not the be-all-and-end-all of software development.

Do you want to create fantastic 3D graphics and visual effects? Best learn C++
and OpenGL.

Do you want to develop a highly resilient parallel system that can be patched
without downtime? Learn Erlang.

Do you want to program an embedded system, or anything where you need to be
close to the hardware? Learn C.

Do you want to program mobile apps? Java, Objective-C or Swift.

Do you want to "program" hardware on an FPGA? Verilog.

Do you want to quickly make 3D games or other interactive experiences? Try C#
and Unity.

Do you want to advance your own knowledge of programming and computation, even
if you don't have a particular platform restriction? Learn any language in a
different language family than you're used to, something like Clojure or
Haskell or Prolog.

And as you get familiar with other languages, you'll find it's easier each
time to pick up the next one.

Your question might better be phrased as, "As a web developer, what are the
advantages to learning non-JavaScript-based web frameworks and languages?"

With my limited experience in the web world, the only good, practical answer
to this modified question that I can come up with is "diversification". If all
your eggs are in one basket when it comes to programming skill, you're very
vulnerable to a language or toolset falling out of vogue. I know some Flash
developers, for example, who have been absolutely devastated by the happenings
of the past several years, because their toolset was far too rooted in Flash.
JavaScript is pretty ubiquitous these days, so I doubt something quite that
dramatic would happen to it, but it's possible that it could—for example, I
can imagine best practices shifting over the next ten or twenty years so that
nobody writes Javascript directly anymore, but only languages that compile to
it. I'm not saying that _will_ happen, but it's an example of something that
_could_.

~~~
msutherl
It's pretty clear from the post that he's talking about web development.

And I don't think your 'all eggs in one basket' argument makes much sense.
JavaScript will always be the (or, a) scripting language for the browser, and
if something new emerges, we will all have plenty of time to prepare.

As for backend trends, they evolve slowly. One needn't worry about being
caught unprepared for some sudden change.

~~~
lostmsu
> JavaScript will always be the (or, a) scripting language for the browser,
> and if something new emerges, we will all have plenty of time to prepare.

Thing is - what if it already emerged, but you missed that?

------
mrcwinn
You don't sound even minimally stupid. :)

I wouldn't necessarily advocate any of those specific frameworks, but I do
think there is life outside of JavaScript. I actually don't think JavaScript
(particularly on the server) is a very good language at all. Blasphemy, I
know.

As someone who has spent time with JS frameworks like Ember, Meteor, and the
rest, as well as libraries and component systems like Rendr, React, and
Backbone, it's certainly not the case that JavaScript is free of frustration.
In fact, I've found the opposite to be true: despite the enthusiasm, some of
these solved a bunch of problems only to create others.

The truth is, if you focus on being a great _engineer_ then picking up another
language and framework isn't very difficult. It will make you a better
programmer to see how other systems solve problems.

Not to speak out of both sides of my mouth, but I do advocate being a master
at one or two languages and learning how to write idiomatic code. I just think
there's room for more than literally one.

If someone tells you that Node is here to save us all from certain disaster
and JavaScript is the One True Answer, I would simply nod your head, smile,
say thank you, and then run as fast as you can.

~~~
yen223
> "I actually don't think JavaScript (particularly on the server) is a very
> good language at all. Blasphemy, I know."

That's a relatively common sentiment here, and I agree that JavaScript isn't
that great a language. In fact I would argue that it has so many warts, so
many problems that if it weren't for its first-mover advantage in the browser
space, JavaScript would be dead by now.

~~~
ziikutv
even #javascript agrees to this. To be honest, picking up anything JS related
was easy for me. I love npm, I love grunt (actually gulp now) compared to what
ruby brings to the table ...

------
dreamweapon
Basically JS represents a very narrow slice of what the world of programming
is really about. It's just a weird and artificial environment in many ways.
Also, despite its current success, it's bound to go away, eventually.

~~~
leftnode
This is great advice. If you spend your time only reading about the latest
startups, you'll think everyone is using Javascript and Node for everything.

The _vast_ majority of software is not written in either of these two. And
it's not a knock on them, there just a tremendous amount of software out there
and most of it pre-dates the Javascript/Node environment.

~~~
rifung
I would think if you were only reading about the latest start ups, it would
sound like everyone were using Rails. At least that's been my experience

------
rmchugh
It really depends where you are in your career. If you are just starting out
and would like to work in general web development, committing yourself to JS
only would be stupid beyond belief. That would assume that JS based frameworks
are going to be ubiquitous in the near future. They definitely won't be and
there are many reasons to doubt that they will be ubiquitous in the long term
as well. The same can be said for any language or framework, language
convergence does not seem to be happening. More likely the landscape will
remain unstable in the medium to long term. Therefore, as a generalist web
developer you will be better served by polyglotism. Learn MVC and other
application design patterns. Learn server side programming and client side
programming. Learn SQL and others ways of interfacing with persistence layers.
In short, don't stop learning and don't assume that there is one holy grail or
one right way to do it. There are many jobs and many tools. Being a good
programmer is about finding a way to match the tools with the job.

~~~
timmm
> If you are just starting out and would like to work in general web
> development, committing yourself to JS only would be stupid beyond belief.

You're suggesting they focus on SQL instead? Ha.

In my opinion, java script is probably your safest bet if you want to focus on
one thing related to general web development that will remain valuable for a
long period of time. The trend I've seen with out clients (top 500 eccommerce
sites) is more and more use of javascript. I would say learn jQuery and
understand how Angular works.

------
mhartl
Is there any framework in the JavaScript world as mature as Rails or Django
(or with as many features)? This isn't a rhetorical question; as the author of
the _Ruby on Rails Tutorial_ , I'd like to know what (if anything) I should be
looking at next.

~~~
vqc
Meteor is about to hit 1.0. The current go to tutorial for Meteor is
[https://www.discovermeteor.com/](https://www.discovermeteor.com/). And a good
snapshot of the current learning resources can be found at
[https://www.yauh.de/best-learning-resources-for-
meteorjs/](https://www.yauh.de/best-learning-resources-for-meteorjs/).

I still owe you an email.

~~~
atmosx
I saw "Meteor" presentation on their website yesterday. The 'real-time'
client-server approach is impressive. I was impressed. Their straight-forward
non-MVC approach might be handy for small projects.

To me "Meteor" looked more like a _direct competitor_ to Sinatra than Rails.

Anyhow "Meteor" seems pretty impressive.

------
ams6110
Ten years ago (or less) if you had proposed building ANYTHING beyond basic
form field validatation logic in JavaScript you would have been laughed out of
the room. JS/Node is popular now but it's a fad. Things that seem exciting are
really just reinvented wheels when you look closely. That said it's not a bad
idea to learn it. Just don't think it will be something you're using heavily
in 5-10 years. Same is true of any other language in the space though.

------
j13z
I'm surprised no one mentioned single page web applications -- that's where I
see JavaScript's strength at the moment, compared to the other server-side
frameworks you named.

JavaScript: While Node.js is awesome, it is definitely not the best choice for
everything -- not everyone needs its features (despite the hype). But if you
want to build web apps on the client side, you have to either use JavaScript,
or compile to JavaScript.

A client side web app however still needs a back end API. The good thing is,
if your front end runs (mostly) on the client side, you can pick almost any
language / framework for the back end you want (e.g. Python).

> I am a die hard Python lover, but I do not know what do to at this
> situation.

Now if you don't know Django yet, my suggestion would be to learn both Django
(given your Pyhton background) and one of the client side JavaScript
frameworks, e.g. Ember.js, Angular.js, React.js or maybe Meteor (depending on
your use case). (And if you learned both Ember.js and Django, you probably get
an idea of what Ruby on Rails is like …).

------
yogthos
I'm actually not aware of any advancements being made in JS that haven't
already been made on other platforms. For example, the JVM is much more
performant than Node, has more libraries, better build tools, better
development environments and so on.

I also think that other languages are more flexible and productive. JavaScript
is a very crufty language with a lot of gotchas and odd behaviors. Dealing
with these wastes developer time and makes large projects harder to maintain.

I'd much rather work with a language like ClojureScript and have the benefit
of using the same language on the client and the server, while using a well
thought out language.

Writing apps in ClojureScript is far more pleasant than with JavaScript. There
are also fantastic libraries available such as Reagent
([http://holmsand.github.io/reagent/](http://holmsand.github.io/reagent/)) and
Om ([https://github.com/swannodette/om](https://github.com/swannodette/om)).

------
temuze
> Why would I want to learn

First off, because learning is good for you! Even if you dislike a language,
there's probably something to learn from it if it's widely used.

There's a lot of great developments in the JS world and Node has really pushed
the envelope in terms of asynchronous IO and making it easy to use web sockets
and such. That said - most apps you'll make don't need some of the more unique
features of Node and personally, I find it's easier to make web apps in high
level languages like Python.

That said, it comes down to personal preference. It's the ol' optimization vs.
discovery problem - you can't figure out what the best tool is for you without
exploring new things.

I wouldn't worry about JS/Node replacing server side code, to be honest.
Python and other languages are slowly going in the same direction (see Python
3's asyncio module). Learning a new framework or language is never a waste of
time.

------
vqc
Paul Graham has an essay discussing what he calls the "Blub paradox."
[http://www.paulgraham.com/avg.html](http://www.paulgraham.com/avg.html).
Perhaps the discussion there isn't immediately applicable to your question,
but I think some aspects of PG's discussion are abstractable and applicable.

Ultimately, if you don't know what the other options are and their strengths
and weaknesses, you will only ever have a hammer. And you won't even know that
your only tool is a hammer. And you'll be trying to eat with it and sew with
it, thinking that it's your only option.

If your life depends on manipulating bits. You should learn all the ways to
manipulating bits. Because you will then know the best way to manipulate a bit
in any given situation. Maybe you should be focused more on one than the
others, but that doesn't mean you should ignore everything else.

------
pointe
Right tool for the job. If you think JS solves everything I would propose you
take a few introductory CS courses ;)

~~~
jordsmi
But all the hip startups are using JS, it must be the best

------
chriswarbo
Why learn anything other than x86 machine code? ;)

Seriously, from a software engineering perspective, the past decade has been a
peculiar time: JS used to seem like a joke to many, but it's got past that and
is now a serious contender as a platform compared to established ecosystems.
However, we're also starting to see other languages include JS as a target
platform; once _that_ matures, those other ecosystems can piggyback on JS's
features, and it loses much of its appeal.

From a computer science/hobby programming perspective, JS is a 'Jack of all
trades, master of none'. If you only know JS, you might get _really good_ at
churning out code, debugging language-specific nuances, sculpting libraries to
your whim, etc. but I would argue that you _won 't_ be really good at the big-
picture stuff.

Without the perspective of multiple paradigms, you might not see the wood for
the trees. Your _thinking_ will be a fuzzy mixture of important ideas lost in
a sea of JS implementation details; you won't have the clarity that comes from
thinking about a problem from multiple perspectives.

It can be difficult to learn a different technology; especially if it's not by
your own choice. The key is that, once you've got past the initial "It can't
even do X, Y and Z!" stage, you'll realise that:

    
    
      - It *can* do X, just in a way you didn't recognise because you didn't fully understand X
      - It can do A, B and C that you never even knew existed
      - Y is actually an anti-feature, which you didn't realise the problems of before
    

With all that said, if you're trying to learn new things, there's not much
'bang for your buck' going from JS/Node to Python/Django, Ruby/Rails,
PHP/Symfony, or even whatever Perl's up to these days, since those languages
are all very similar; of course you'll find a few nifty frameworks/approaches
which are popular in each, but if you look around on GitHub you'll usually
find slightly-crappier reimplementations in most of those other languages.

If you want to get some real "Aha!" moments, try something out of your comfort
zone like Erlang, Haskell, C, FORTH, Prolog, Maude, Scheme, etc. (admitedly JS
is like a cheap knock-off of Scheme, but those missing pieces like call-cc,
tail-recursion and macros can drastically change the mindset of its users).

If you want to get stuff done, stick to what you know ;)

~~~
xerophyte12932
I dont see why people downvoted you. You had the best all-round advice.
especially this part:

"It can't even do X, Y and Z!" stage, you'll realise that:

\- It _can_ do X, just in a way you didn't recognise because you didn't fully
understand X

\- It can do A, B and C that you never even knew existed

\- Y is actually an anti-feature, which you didn't realise the problems of
before

------
rubiquity
1) Learning different programming languages is one really good way to grow as
a programmer.

2) The web is just one of several mediums for delivering content these days.

3) Node.js has a highly suspect concurrency model that might not be suitable
for all the various types of programs you could be building.

~~~
mackwic
Why highly suspect ? We know and use cooperative concurrency since decades.

Agreed on the "not suitable for all" but no one said that.

~~~
rubiquity
Cooperative concurrency is fine and a lot of languages use cooperative
concurrency just fine. The issue with Node is that it completely ignored the
multicore reality that we live in. Everyone argues that multithreading is so
complex, and it is unless you have the right abstractions. But what is
guaranteed to always be complex is single-threading with process forking. As
soon as you want to communicate between processes, and you will want to
communicate between processes, you now have to implement IPC. In come the
message queues... that is once you pick which message queue to use.

We've also been using event-driven IO for decades and Node is the only modern
run-time to ignore the obvious perils of evented IO. Instead of doing what
languages like Go and Erlang did, which is have event loops in the run-time
that are completely transparent to the developer, Node pushes the evented IO
right into the application developer's face. Are there remedies for writing
good evented code? Absolutely. But why should application developers need to
be schedulers in the year 2014?

~~~
ziikutv
The stuff you were saying about forking, IPC... it made me giggle because I
just wrote a midterm on these concepts last night :)

Thanks.

Erlang seems interesting, would you mind expanding on Erlang or GO?

~~~
rubiquity
Everything in Erlang is asynchronous and non-blocking but this is almost
completely transparent to the programmer. When you start an instance of the
Erlang VM it spawns as many threads as you have CPUs and a thread for an event
loop. Each thread can have thousands of Erlang processes (Erlang's unit of
concurrency is called a process) executing. Inside of the thread is an Erlang
scheduler that allocates execution time to each Erlang process using a
technique known as reduction counting.

Erlang also has great features for distribution. Communicating with processes
that live in another Erlang VM node is also transparent. It's debated whether
this is a good thing or not because some people think communicating over the
network shouldn't be transparent due to partitioning, but in a lot of Erlang
programer's experiences this is a wonderful feature.

The result of all of this is that the Erlang code you write looks synchronous
but is executing concurrently. You have both CPU concurrency and IO
concurrency. The Erlang VM takes care of most of the nasty bits of
asynchronous code, which is what a good language run time does for you.

~~~
ziikutv
Thanks,

Where is Erlang used predominately? Is it a "good" solution for web
development (if that's even possible)?

~~~
fenollp
Jose Valim, a RoR developer, created a language (Elixir) just for your use
case. Go have a look!

------
ep103
Because the only way to learn the answer to that question, is to learn why
people are using the other languages, which in turn, likely means researching
them and learning them for yourself.

To answer your question more on point, the first thing you'll find is other
languages add much, much more safety into their language than js-node can.
Indeed, that's what makes js-node as much fun as it is. But if you're a new
business owner, and you have to choose between building your server backend on
java/c#/etc technology, which can be rigorously checked for stability, and js,
chances are high you're going to go with the languages that have such
automatic checking features.

------
grimtrigger
One good reason is the market. The wider your skillset, the greater your
opportunities.

------
yogsototh
Each framework, programming language can learn you something new. Many
framework/languages feel very similar.

If you really want your mind to learn something you can get back to your JS
code, you should try to use a functional language:

\- Clojure (I recommand compojure-api for the server and reagent in clojure
script for the frontend)

If you really want to blow your mind:

\- Haskell (scotty if you want to start small, Yesod if you want all batteries
included) for the back and Elm (for the frontend)

It will make your code cleaner in the end, and you'll start to focus on the
important stuff instead of just the syntax.

------
MalcolmDiggs
I work 100% in javascript at the moment, but it's only because I happen to
like it and find it interesting _right now_. Not because of any inherent
advantage to the frameworks/runtimes.

Do what you enjoy. That will change over time, and so should your tool-chest.
As long as you keep learning and stay true to yourself, you'll progress
naturally through different languages, frameworks, etc. Try not to box
yourself in, there's really no advantage to limiting yourself.

------
lhnz
I think JavaScript's here to stay, which is why I've specialised a little in
it recently. However, I also think that there are lots of programming concepts
that are moving from other languages towards it.

It's worth exploring a few other languages to just get a greater feel of the
future, and to also protect against the chance that JavaScript loses its
ground.

------
mackwic
It's like learning a new programming language: the more you know how to
speak/code/design, the more you can express and understand others.

You should have a look to rails, it's still the state of the art in term of
framework design. The java/scala Play framework is also worth trying.

------
farresito
To be honest, I would personally choose python over node any day when
developing web applications. Before Go appeared into the scene, I would have
told you to go with node for concurrent server stuff. There are plenty of
libraries written for node, though.

------
ziikutv
I cannot edit the main thread but, thanks for all the answers.. Some of the
interesting messages mentioned, Go, Erlang, and JVM (I know that JVM is faster
than Node, but how do i go about using JVM backend with say XYZ frontend. And
what should XYZ be?)

------
msutherl
None of the existing answers seem particularly convincing to me. Here's how I
have chosen: pick the framework that is most popular with the people you want
to work with, projects you want to work on, or companies you want to work at.

If you're building simple websites for clients (publishers, small business
owners, etc.), PHP is probably still the best choice, and usually Wordpress.
It runs with no config on standard web hosting platforms and you mustn't
underestimate the power of the Wordpress plugin ecosystem + the fact that most
people are comfortable with Wordpress.

If you're building more advanced websites (not web-apps) for clients, Django
is a great choice, in large part because it has an excellent drop-in admin
panel, but also there's a ton of third party apps available.

Ruby is also a good choice for this, having an even more solid ecosystem.

That said, Ruby is trending down, Python is trending up. Also, hipsters are
now learning node.js and nearly everyone who went to engineering school knows
Python. Hipster savants are learning Go, Clojure, Haskell, and Scala (in
order). Who do you want to work with?

node was built with event-driven apps in mind. In other words, it's for web
apps. It would be unwise to build a traditional website with node unless you
have a particular reason to.

Same with Go, Clojure, Haskell, and Scala.

If you want to work at a cool startup, you won't do yourself a disservice
learning node. If you want to work at a cool startup doing more hardcore stuff
(think Firebase or Cloudfront), you wouldn't do yourself a disservice learning
Go or Clojure.

If you want an all-around framework and to broaden your skills, go with Ruby
or Python. If you're more of a hipster (aesthetics, web-only) then choose
Ruby. If you're more of an engineer (academic, data science), choose Python.

Another perspective on Ruby: Rails skills will be in demand for maintaining
old code-bases for awhile into the future, even if it's declining in relative
popularity.

~~~
acmecorps
> That said, Ruby is trending down, Python is trending up

[http://trends.builtwith.com/framework/Ruby-on-
Rails](http://trends.builtwith.com/framework/Ruby-on-Rails) vs
[http://trends.builtwith.com/framework/Python](http://trends.builtwith.com/framework/Python)

Or am I interpreting this wrongly?

 _shrug_

~~~
msutherl
My claim was anecdotal. For some data, TIOBE tells a different story than what
your source claims:
[http://www.tiobe.com/index.php/content/paperinfo/tpci/index....](http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html)

------
n0body
you should learn perl and catalyst, because they're awesome :)

~~~
senorsmile
catalyst over mojolicious? Looking into both, and mojolicious seems to be
winning at this point.

~~~
n0body
depends on what you want to do. catalyst has a proven history of big teams
working on big projects and not getting in each others way. as well as one man
teams working on small projects.

it's mature, well supported and powerful. there's a bit of a learning curve
when you first start, but that's the way with everything. although it might be
made worse by it's opinionated approach to the way you have to lay your
project out, but not long into it you'll be thankful for that, as it helps
keep everything clean and clear

mojo is more flexible about how the project is layed out, has async and
websockets and stuff, but i've not used it, so i don't know the ins and outs
so i can't comment

that said, you should try them both, see which one suites your needs best.

