Comment by snorkel | Hacker News Reader

Comment by snorkel | Hacker News Reader

Parent Full thread

I agree completely. Web frameworks add a layer of code bureaucracy that really doesn't need to be there in most cases. Reading and setting browser cookies is not that hard. Creating and reading web forms and validating inputs is not hard. Creating a relational database schema and objects that store themselves in that schema is not hard. You can do all of this directly in mod_python, essentialy by buildng your own framework, so you really don't need Django (I'm know, I'm a heretic for saying so) But doing all of these things directly mod_python takes time to learn how to do it reliably and efficiently. So I understand Django's appeal to people who picked up a Python book and asked "How do I create an event calendar web site in five mouse clicks?" and didn't see a direct answer to that question so they went with a framework. Personally I'd rather not toil under the tyranny of someone else's framework, especially when they suggest you need to create Factory for a Consumer then connect it to an Active Bridge connector... no thanks, I'll just use "mod_python import Cookie" instead.

"essentially by building your own framework"

Why build your own framework when there's one already there? Already well-used, well-tested, well-extended?

Sure it may be easy enough to do, but is it really worth it?

I, for one, would much prefer to be spending my coding time writing application logic than Yet Another Validation Library.

There is a trade-off to using a Framework. For me, it depends on the complexity of the problem, and the difficulty of learning the framework.

Suppose someone is familiar with Java Servlets and JSP, basic JDBC and SQL, and the tomcat container (with connection pooling). If I have a simple database driven application, I can choose to hand code some of my application logic, or use a framework.

So I'm choosing between, say:

No framework: container managed security, hand coding my ORM layer, writing my own server side form validation, writing my own MVC (or just not bothering, if it is just a few pages).

Framework: Spring Security, Struts for form building and validation, Spring for the MVC tier, JPA and Hibernate for ORM.

These are slightly extreme - you don't have to use all those tools, of course.

But let's say we do get something out of the framework. The code really is easier to maintain and understand, provided someone has read a 300 page book on spring, another 300 page book on hibernate, and a 150 subsection of a book on Struts, along with doing all the exercises.

Even if the framework based code is better, that's not enough to justify the complexity. I need to justify taking an application out of the realm of someone who understands the basic servlet spec and putting it into the realm of only those who have read and digested an additional 600+ pages of Framework complexity.

Thing is, I like frameworks. You can read and digest 100 pages about Rails and really get going. So the bar for justifying the "added complexity" of a framework in the Ruby world is much lower than it is in the Java world. I don't use Python, but I'd imagine it's a similar situation - it's much easier to justify Django than the Java framework stack.

Because frameworks aren't optimized to your use case.

Hell, programming languages (typically) aren't optimized to your use case. You modify them to make them so.

Good frameworks are the same way. I've already extended the hell out of Kohana to make it more useful to me. This is work I would have had to have done if I weren't using it, sure, but all the basic stuff is there all the same.

Sure, it just depends. Quite often, I've found that modifying someone elses code takes orders of magnitude longer, than just writing it yourself.

the difficulty of modifying somebody else's code is proportional to your own programming skill.

Yeah I'm not sure that's actually true :)

Would you rather build a porche, or try to convert a clapped out old volvo into a porche?

Tidying up rubbish, bad architecture choices, stupid coupling etc isn't fun. It's twice the work - fixing all the stuff they did stupidly, and then implementing it how it should be done.

"Why build your own framework when there's one already there?"

Why learn woodworking when you can buy furniture at Walmart? Some people like craftsmanship and others like frozen dinners.

So, the popular theorem is that programmers who have been working for any amount of time already have the makings of their own frameworks. They've already written code to connect to or abstract a database. They've already written their authentication pieces. They've already written (or are using) something like Smarty for 'views' or display data.

For many developers who toil in the same language all the time, or who have spent many hours in whatever language they're currently in, that's the case.

For me, I avoid Rails because it makes me feel like a failure. ActiveRecord, for one reason or another, hates me. I like Rails, and I like the Framework concept (however limiting it might be) -- because I feel that it gets you started more quickly. At the end of any significant project, I feel like you will have likely massaged enough elements of the framework to make it work for you that it's hardly recognizable, but it still got you something to show people that much faster.

That said, ActiveRecord is the showstopper for me in Rails. It seems like I've either never properly wrapped my head around it, or there are fairly low limits to what you can do, or I'm doing everything wrong. What that's always meant for me is that instead of using ActiveRecord to its fullest, I'm building SQL queries manually. And if I'm deviating from the framework's toolset, why am I using this framework in the first place.

This is NOT a knock on Rails, I'm probably just doing it wrong. Rails and I can still be friends... just not in that way.

I've always liked the 'middle ground' that Zend offers, in that it abstracts away the connection and handle, and gives me a convenient place to start building the model code. It's not 100%, but it doesn't make me feel guilty in the morning either.

I use Kohana myself, for exactly the reason that you mention you like Zend - it's a good starting point. And if I need to extend Kohana's model or rewrite it from the ground up, this is totally accepted and even encouraged by the framework.

I find it's just way, way easier to get up to speed with a framework as a base, and if your framework is any good, then it should be easy to shove aside later when you need to special-case things for performance or whatever.

My biggest problem with frameworks is that, although they save you a lot of time upfront, you need to spend a lot of energy learning concepts that may not be necessary for your application. So, the time you save coding is partly spent in learning things you may or may not need. If you do everything by yourself initially, at least you will know when it makes sense to use the framework. This is my approach with web development: Try to do whatever I need without the help of a framework. Then, I will know where a framework can help or not, and use it the next time I need a specific functionality.

Code bureaucracy? A friend of mine managed an Extreme Programming project for the Department of Defense. When he first started out, the paper bureaucracy required to create a new class amounted to two full business days! He got that whittled down to two hours.

this is no doubt tangential to your original point, but you should stay away from mod_python. You're walking into a version coordination nightmare (apache+DB+python). Debugging is a pain and your apache processes now load a python interpreter (each!). I suggest you take a look at wsgi.

Reply on news.ycombinator.com