Ask HN: in 2013, is it still worth learning RoR/Django? | Hacker News Reader

Ask HN: in 2013, is it still worth learning RoR/Django?

34 pointsurlwolf31 comments

Can one skip a generation and say learn backbone instead of jquery, or meteor instead of django? I wonder if knowing the older technology is still needed to appreciate the new one; The elders of 'server side rendering' frameworks are saying in talks that what they do is virtually obsolete, as more and more gets rendered on the client. But of course there's a large chunck of applications that still are better implemented with RoR/Django. Since we all have a limited time to learn... in 2013, is it still worth learning RoR/Django?

View on HN

Instead of using RoR or Django (or something really "opinionated"), try looking into Sinatra or Flask (or other small "micro-frameworks" and libraries) where you can mix-and-match your own libraries from different places. This will get you in the habit of weighing the pros and cons of using different packages and tools for different tasks, and it will also force you to learn how to chose the best tool for the job yourself.

I think Rails and Django are great, but they offload a lot of design decisions to the community -- this is great when you want to write maintainable code with a diverse team, but not necessarily the optimal setup for gaining the most useful skills for the future. If you want to be ahead of the curve, try using smaller and more focused tools. Even though an individual piece of the puzzle may occasionally need to be replaced, you will at least know that you hand selected the best tool for your use case, and won't have to shoe-horn another approach on top of it.

Also note that recently web development is moving away from including front-end logic and templating in the server side code. Nowadays developers are focused on building front-end apps (with backbone/ember/etc) that interact with back-end APIs. If you want to move in this direction, Flask and Sinatra can provide all the functionality of Django/RoR without the overhead of all the templating junk you won't use. If you like the ORM of Django, try SqlAlchemy + Flask.

Backbone yes, Ember, likely not. Ember is so new and the core changes so often that it's unlikely that a large number of developers are using it.

Jeff Atwood's new product Discourse is heavily based on Ember, so that's at least one major user.

And it's also using rails for the sever side component

some well known companies are using it http://emberjs.com/ember-users/

and all of those companies are using a server side framework as well - lot's of rails at the other end of that emberjs code

I agree with this - learning Sinatra is a bit closer to the metal (and I'm sure Flask is similar).

Really, the choice of the tool comes down to a lot more than just "what's best today". But some common criteria are:

Language - are you comfortable with the language used in the tool? Conventions - are you comfortable with the conventions used in the tool? Community - what kind of community is around the tool? Is it supported sufficiently by helpful peers? Fit for consumption - does the tool really do the job well? In other words, are you using a tool with the wrong kinds of strengths? (Programs written in C are fast, but writing raw C doesn't make sense for most web apps) Team - Does your team use a particular tool? Are you collaborating with people, and if so, do they have an opinion about the language and conventions used?

Beyond this, it really has to do with aesthetics. Most any tool out there will "do the job", and with reasonable performance. Of course there are plenty that have significant gaps (compare a Wordpress load overhead to static files served by Jekyll, and you'll see an example of this), but at the end of the day, people utilize and patch and hack and ... get the job done.

What looks exciting to you? What are you going to put your heart and soul into learning? What is enjoyable? What works? Choose that.

This conversation seems to come up often. Server side templating is still really important and isn't going away too soon.

There's still so many problems to solve before server side templating can seriously be considered obsolete.

1. Search engines still can't scrape javascript created content. Hacks like #! don't count.

2. Grade A browsers still don't properly support pushState() and if they are supported in some cases it's a buggy experience.

3. There's still a decent amount of people with JS turned off.

4. Having the client do the heavy lifting of your web site is a bad idea because the experience cannot be controlled. Anyone without a decent computer is going to get a sluggish experience and mobile performance is still very questionable.

#3 is probably the least important thing but it will also depend on what your site is doing. If I'm selling a product that with global reach and I ignore #3 then I'm throwing away money basically because India and China are massive and they have pretty high %s of people without JS or very old browsers.

Regarding point #1:

Yes it can be done, but it slow down the process a lot.

Can you go into more details?

Making your web server respond back with server rendered templates if it detects a bot user-agent instead of serving back json normally isn't really what I would consider a solution.

It's a solution in the sense that you can satisfy both search engines and users but it requires the developer to code basically 1.5 web sites instead of 1 (it's not really double the work but it's certainly more work than just wiring up some routes that spit back json).

I cannot go into technical details because that is a solution I worked out for Nuuton. Though it is possible by using a helper bot. The crawler does not do the job itself, but gets the data passed to it by another bot.

I don't want to sound dickish, but I can't really give you much technical details. Sorry.

Sounds like it's not solved. Don't you think Google would be happily crawling javascript sites without the developer having to do anything special?

I don't know what Nuuton is but from the looks of the home page it seems to be some random no name search engine that isn't even released.

I wouldn't really call that solved, considering most end users are using Google, Bing or Yahoo.

What "Grade A browsers" don't support pushState()?

My definition of grade A might be different than yours.

Grade A to me is a browser that is part of the "used just about everywhere" group.

Windows 7 ships with IE 8, so I consider IE 8 a grade A browser. Using tools like history.js to offer buggy fall backs isn't acceptable behavior IMO.

Ah, yes, it is just a question of definitions. I took it to mean something like "has generally good support for standards," in which case no version of IE besides maybe 10 would make the grade.

Backbone and jQuery do different jobs, they complement each other quite well.

For the next year you'd have a much better chance of getting a Django or RoR job than a Meteor job. Meteors still the new kid on the block so it's still in a process of picking up traction. Beyond the next year, who knows...anything could happen. As long as you understand the underlying principles of web development, picking up new technology should be trivial.

I don't care so much about the job market, but I want to know what would give me a wider range of apps I can put together quickly, given I invest X hrs to learn the technology.

The idea of skipping Rails and learning Backbone instead makes no sense unless you just wanted to be a front-end guy all along. You still need a backend. Whether you like Rails' style of backend or prefer something like Sinatra is up to you, but you need something on the backend, and Rails is still a very strong contender.

If you are doing a heavy front end, you should avoid something heavy on the backend like Rails. It will only get in the way. Something like Flask, Rack, Grape or Restify is a better option for the server-side component.

It's not a zero sum game.

Also, there's a lot of hype about JS frameworks and client side rendering, but you still need an API and server side rendering (Twitter just figured this out after going back and forth). Both RoR/Django are good tools for writing REST APIs on, and for learning about web development in general.

Both Rails and Django will be here for a long time, regardless of what the current fad of the day is.

IMO this is the composition vs inheritence debate.

In the Python world, WSGI was really a break-through idea (a decade ago!) - parse the request up front and pass the text down a chain of functions each of which can modify the request / response.

That way the chain you build is the chain used.

Every python web server uses it behind the scenes, and then tries to make bits of it "easier" for you by hiding the underlying goodness.

Its usually a good trade off, but it kind of takes away the point.

So, I would say, (python) learn how to deploy your own WSGI app on gunicorn behind Nginx. And put security in using repoze.who.

Then you can choose to replace your app with Flask. Or django. Or ...

build up from the ground

  > learn backbone instead of jquery

Backbone relies on some sort of DOM library like jQuery to function. Regardless, for any library, it's important to learn the fundamentals before using them, such as DOM basics in JavaScript before even using jQuery.

To answer the original question, yes, it's important to learn server-side frameworks since there's still many things about them that client-side rendering can't do (better search engine optimization, progressive enhancement, accessibility).

If you want to remain an applications developer, then yes ROR/Djano is worth learning.

If you want to learn to build critical system components in the back-end, you can skip RoR or Backbone, and learn stuff like machine learning, NLP, or building distributed systems.

Can anyone enummerate the apps that are 'as of today' better suited to RoR/Django?

The funny thing is that the django tutorial uses a poll app. This is an app that is ten million times easier to do, and more effective, in say meteor. But I'm sure other apps are not.

It's still worth learning COBOL, so I'm going to have to say yes.

Don't compare backbone and jQuery. That's like saying "I want to build a bike, do I need a frame or a wheel?" Learn both. They work together.

I'd go straight to javascript for webapps, but Ruby is my favorite way to write map-reduce jobs. It's really well suited for big data work.

I'd skip RoR/Django at this point.

I'd say if you want to be a front-end only dev you can skip it - you need to know some server side framework if you're going to be doing anything else

Reply on news.ycombinator.com