3 ms·

I'm probably going to get downvoted for this, but whatever. This is a very easy decision. If you're an experienced Rails developer, use Rails. If you're an ex

I'm probably going to get downvoted for this, but whatever. This is a very easy decision. If you're an experienced Rails developer, use Rails. If you're an experienced Perl developer, use Perl. If you're an experienced PHP developer, use PHP. etc. The tools don't matter so much. Your experience level with them does. Don't use something you're unfamiliar with in production just for the sake of using the new hotness. That's dumb. That's not to say, of course, that you should never use anything new. Learn new things, and learn often. Play with new technologies and languages on your own time and get some proficiency with them before using them for a client in a production setting.

raquo 11y ago
Counterpoint: the stack you choose initially will often follow you for years because switching costs are rising with every line of code and every developer on the payroll. Personally I often go for a less familiar but more appropriate stack.
- hhandoko 11y ago
  I agree. I'd also like to add that as long as architectural best practices are followed, the switching costs and risk can be minimised.
- cweagans 11y ago
  You can write bad code with a good stack, and you can write good code with a bad stack. Put another way, a pro football player will be pretty good with whatever he uses, but even if I had the exact same gear, I'd never get picked for even a high school team. It's about the person, not the tools.
  - raquo 11y ago
    Absolutely, but for non-experimental stacks good practices are well understood and are easy to pick up, especially if you don't focus your career on the one true stack. For 99% of the projects you don't need to know any stack at level 80. You're much better off having a more diverse experience. Most skills beyond intermediate level – defensive coding, good architecture, managing complexity, etc. – translate very well to other stacks.
    - cweagans 11y ago
      That's a valid way to look at things, but I take a different approach. I try to avoid easy projects as much as I can with my preferred tech, because it forces me to grow as a developer. I have a relatively diverse skillset which I can grow outward or upward if I need to, but I also have deep knowledge of 2-3 technologies that really pay the bills.
rahimnathwani 11y ago
This is correct in general, but there is some detail missing. I wouldn't call myself an experienced Python developer, but it's my most comfortable language so I'll use that to illustrate. 1) I'm comfortable with Python, and have some understanding of web frameworks. Should I use Django or Flask or Pyramid? Which ones have a shallower on-ramp, or will help me make my project more modular? 2) It's 2015, should all web apps consist of a clean RESTful API, decoupled from the front-end? Or is it OK to have all server-rendered pages? 3) If I should separated as per point (2), then does that mean I should stick to a lighter web framework, instead of using Django+DRF to provide the API? How should I build the front-end? Backbone? React? 4) If I don't separate front and back-end, what do I do about the little things that need some Ajax magic? Just write some 'onlick=...' stuff in my templates? Or should I be keeping my JS modular and using gulp or something to collect stuff up? Even if the answers is 'just use Django' or 'just use Rails', there are lots of specific things to decide, and it's annoying to have to do so. If I were a Ruby expert starting a web app tomorrow, at a minimum I'd have to decide between Rails and Sinatra, and between rbenv and RVM...
- cweagans 11y ago
  At least you'd have the knowledge to make that decision intelligently and only have a few choices to make, rather than having the burden of learning an entirely new tech stack on the fly and likely make decisions that may not be the "right" way to do things with that stack.

raquo 11y ago

Counterpoint: the stack you choose initially will often follow you for years because switching costs are rising with every line of code and every developer on the payroll. Personally I often go for a less familiar but more appropriate stack.

hhandoko 11y ago
I agree. I'd also like to add that as long as architectural best practices are followed, the switching costs and risk can be minimised.
cweagans 11y ago
You can write bad code with a good stack, and you can write good code with a bad stack. Put another way, a pro football player will be pretty good with whatever he uses, but even if I had the exact same gear, I'd never get picked for even a high school team. It's about the person, not the tools.
- raquo 11y ago
  Absolutely, but for non-experimental stacks good practices are well understood and are easy to pick up, especially if you don't focus your career on the one true stack. For 99% of the projects you don't need to know any stack at level 80. You're much better off having a more diverse experience. Most skills beyond intermediate level – defensive coding, good architecture, managing complexity, etc. – translate very well to other stacks.
  - cweagans 11y ago
    That's a valid way to look at things, but I take a different approach. I try to avoid easy projects as much as I can with my preferred tech, because it forces me to grow as a developer. I have a relatively diverse skillset which I can grow outward or upward if I need to, but I also have deep knowledge of 2-3 technologies that really pay the bills.

rahimnathwani 11y ago

This is correct in general, but there is some detail missing. I wouldn't call myself an experienced Python developer, but it's my most comfortable language so I'll use that to illustrate. 1) I'm comfortable with Python, and have some understanding of web frameworks. Should I use Django or Flask or Pyramid? Which ones have a shallower on-ramp, or will help me make my project more modular? 2) It's 2015, should all web apps consist of a clean RESTful API, decoupled from the front-end? Or is it OK to have all server-rendered pages? 3) If I should separated as per point (2), then does that mean I should stick to a lighter web framework, instead of using Django+DRF to provide the API? How should I build the front-end? Backbone? React? 4) If I don't separate front and back-end, what do I do about the little things that need some Ajax magic? Just write some 'onlick=...' stuff in my templates? Or should I be keeping my JS modular and using gulp or something to collect stuff up? Even if the answers is 'just use Django' or 'just use Rails', there are lots of specific things to decide, and it's annoying to have to do so. If I were a Ruby expert starting a web app tomorrow, at a minimum I'd have to decide between Rails and Sinatra, and between rbenv and RVM...

cweagans 11y ago
At least you'd have the knowledge to make that decision intelligently and only have a few choices to make, rather than having the burden of learning an entirely new tech stack on the fly and likely make decisions that may not be the "right" way to do things with that stack.