Hacker News Reader

Comment by coldtea | Hacker News Reader

No, variety also means:

1) scattering of effort (each framework gets less total attention by fewer people),

2) duplication of effort (besides what is unique in each, tons of effort is spend in implementing mostly the same things),

3) Many half-finished frameworks

4) Worse documentation and less books/manuals/video tutorials (see 1, 2)

5) Less chances of getting an answer to a framework problem in forums/irc/SO (again: scattering of resources).

6) Less vibrant ecosystems around the framework (if each of 10 frameworks has 10% of the market, it's not as good a business to invest in making plugins as something that has 30-40%). Same for hosting offerings, support, etc.

So you want variety but not too much. 2-3 big players would be mighty fine. 10 players of equal size, not so much.

View on HN

Agree. The current war of numerous Javascript MVC frameworks reminds me of the situation of Python Web Framework a few years ago, the community was confused by so many choices to select from. In the end, nobody wins, even the ultimate winner Django lost the opportunity to become mainstream. In that sense, the merging of Rails and Merb seemed to be a wise and successful strategic move in hindsight.

Django is pretty mainstream. Its not as popular as Rails but its hardly a maverick.

I think the reason why Python never went all in on a single web framework is just because the Python community itself is much larger and more diverse than the Ruby community. Consequently there were alot more opinions and alot more people willing to develop those opinions into separate projects.

Maybe you're right that there are advantages to converging on a single framework, but I'm not so sure. Rails is omakase, so if there's some part of it you don't like its not really easy or a good idea to change it, and you don't have any other options in Ruby. Django is also omakase but if there's some part of Django that you really disagree with you can just move to web.py or flask or pyramid. these are all built on the common core of Python's wsgi module so these are just different opinions on how to accomplish the same task.

With Django in specific you can swap out a component. For example, if (like many people) you don't like the HTML template syntax, just swap it out for Jinja2 or Mako. In Django it is also usually easy to customize something minor by use of overrides (OOP).

This is also true of Rails. That's what the Gemfile is--a list of optional packages that you can swap out. (Almost) all of your configuration happens in that one file where you tell Rails what packages (gems) you want to use with your application.

this is very true for some of django's components. the template engine is probably the most opinionated part of django and is also one of the easiest parts to swap out. other parts of django are not so easily disposed of. for example, the ORM is very tightly integrated. its possible to swap it out for SQLAlchemy or something but this is really a huge headache and not worth doing.

Reply on news.ycombinator.com