Ask HN: Why learn non-JS languages/framework?
54 comments
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.
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.
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.
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.
> 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?
Thing is - what if it already emerged, but you missed that?
Actually some people are using javascript + node for embedded systems. But I only am interested in opinions related to web/phone development :)
I was only talking about in web development context but yes I know/use some languages you have listed. I do embedded system programming, also design hardware and do FPGA related stuff. :)
Good to know, I guess that makes my answer quite a bit less relevant. I just tend to get frustrated when I see people who've only done web stuff treat "programming" and "web programming" as synonymous.
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.
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.
> "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.
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.
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 ...
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.
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.
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.
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
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.
> 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.
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.
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.
No, there isn't, nor should there be.
Rails and Django are both heavyweight, all-in-one frameworks, full of canned magic and optimized for easy OOB experience at the cost of inflicting undue difficulty when it comes to complex tasks, i.e., useful ones.
If there's anything like that in the Javascript world, it hasn't achieved prominence, nor will it; modern Javascript development is much more concerned with, and much better suited to, lightweight microservices tied together by smart client code. Working effectively with such architectures requires a greater initial investment than does becoming au courant with Rails or like ilk, but the return in scalability and maintainability is very much worthwhile.
Rails and Django are both heavyweight, all-in-one frameworks, full of canned magic and optimized for easy OOB experience at the cost of inflicting undue difficulty when it comes to complex tasks, i.e., useful ones.
If there's anything like that in the Javascript world, it hasn't achieved prominence, nor will it; modern Javascript development is much more concerned with, and much better suited to, lightweight microservices tied together by smart client code. Working effectively with such architectures requires a greater initial investment than does becoming au courant with Rails or like ilk, but the return in scalability and maintainability is very much worthwhile.
Meteor is about to hit 1.0. The current go to tutorial for Meteor is 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/.
I still owe you an email.
I still owe you an email.
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.
To me "Meteor" looked more like a direct competitor to Sinatra than Rails.
Anyhow "Meteor" seems pretty impressive.
I already know of Meteor. its great. I like it more than Rails, or any other framework in the market. The question, though worded inappropriately, was that I notice everything related to JS.. what the fudge cookies is happening in the other languages?
Here's a good list of the big ones http://www.quora.com/What-is-the-best-full-stack-web-framewo...
None as mature as Rails though.
None as mature as Rails though.
You should really check out http://emberjs.com
It applies the Rails way of thinking to JavaScript and is maturing fast. As a Rails developer I love working with Ember!
[deleted]
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.
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 …).
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 …).
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/) and Om (https://github.com/swannodette/om).
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/) and Om (https://github.com/swannodette/om).
> 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.
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.
Paul Graham has an essay discussing what he calls the "Blub paradox." 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.
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.
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:
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 ;)
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
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 ;)
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
"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
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.
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.
Why highly suspect ? We know and use cooperative concurrency since decades.
Agreed on the "not suitable for all" but no one said that.
Agreed on the "not suitable for all" but no one said that.
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?
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?
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?
Thanks.
Erlang seems interesting, would you mind expanding on Erlang or GO?
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.
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.
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.
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.
One good reason is the market. The wider your skillset, the greater your opportunities.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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?)
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.
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.
> That said, Ruby is trending down, Python is trending up
http://trends.builtwith.com/framework/Ruby-on-Rails vs http://trends.builtwith.com/framework/Python
Or am I interpreting this wrongly?
shrug
http://trends.builtwith.com/framework/Ruby-on-Rails vs http://trends.builtwith.com/framework/Python
Or am I interpreting this wrongly?
shrug
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....
Interesting, that site is showing a "network error" in the console on Firefox in Windows for me. Have to see if it displays in Firefox/Linux.
There is a graph of the amount of JS repos on Github, its exponentially increasing (granted its not all web related)
you should learn perl and catalyst, because they're awesome :)
catalyst over mojolicious? Looking into both, and mojolicious seems to be winning at this point.
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.
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.
At the risk of sounding completely stupid, why would I want to learn things like Rails, MVC5, Django over something in Javascript/Node?
It seems there are significant advancements being made in the JS world compared to others.
I am a die hard Python lover, but I do not know what do to at this situation.