Hacker News Reader

> This is my main problem with this line of thinking. Developers aren't actually developing anymore. They are mashing together frameworks.

Usually you have one framework and then you mash together a bunch of libraries. The framework exists as a way to abstract the most common functionality of your chosen platform. A good framework eliminates a lot of boilerplate without getting in your way when you need to go beyond the common functionality.

The ironic thing about your post is that PHP itself has a bit of a nascent framework quality to it. It was developed before web frameworks of course, at a time when everyone was writing Perl CGI scripts using a bunch of libraries. The revolutionary aspect of PHP and mod_php in particular, was that it had automatic hooks into all the common aspects of the HTTP cycle, including the page metaphor, which meant you could change a static page into a dynamic page with no effort. PHP was state of the art when websites were mostly still just pages. Serious programmers laughed of course, how could you build a serious application in this glorified templating language? So they continued to develop their "proper" frameworks like Struts, Zope and countless others rooted in the experience of GUI developers from ages past.

However as web development experience and understanding matured, there was a widening gap between PHP and the enterprise frameworks. And this gap is squarely where Rails was dropped in 2004. There are so many things that are common to all web applications that PHP doesn't handle. DHH's brilliance was not so much in the details of the original Rails code, but in picking and choosing best practices and unifying them in one package in a minimal way. I think this was instrumental in web framework developers from all languages re-evaluating what was really necessary and what cruft could be eliminated.

Nowadays Rails is pretty enterprisey in capability, but it still avoids most of the overhead present in enterprise frameworks of 10 years ago. The minimalist torch has been carried forward by upstarts such as Merb and now Sinatra.

The strength of these various frameworks is that they do things that tens of thousands of developers need to do every day in a standardized way that's had massive input and refinement over time. When you use these frameworks you can hire people and they hit the ground running. When you use your own personal library then every new developer has to get up to speed on your dime, and you foot the bill of maintenance yourself rather than gaining the advantage of a large open-source community.

You say you don't believe that mashing together frameworks is actual development, yet you recommend the jQuery framework for front-end coding. Do you draw a distinction between front-end and back-end - is front-end work not really development?

In my experience, the time it takes to become proficient with an existing framework is generally a lot shorter than writing a framework yourself. And, generally, the existing one will have been vetted by thousands of people before me.

jQuery is nice because you can jump back and forth between it and "regular" Javascript. Inside your $(id).click() function you can just as easily call document.getElementById. jQuery even provides you access to all of the DOM level objects in case you want to escape outside of it for a bit.

Most frameworks do not let you do this and you have to actually have to work at it/hack at it to use functionality that isn't provided by them.

Well, one major reason to use jQuery, besides all of the cool APIs, is that it encapsulates most of that messy browser specific stuff you have to account for which is not that analogous to what you have to do with most programming languages.

"You say you don't believe that mashing together frameworks is actual development, yet you recommend the jQuery framework for front-end coding. Do you draw a distinction between front-end and back-end - is front-end work not really development?"

I use it sparingly. Mostly because there are many quirks between the various browsers and jquery seems to have a pretty good handle on it. As an example: rather than using one of the many bloated pagination libraries I found based on Jquery, I rolled my own in less code. It ended up much smaller because I didn't have to incorporate everything in the existing libraries. Most frameworks throw in everything, because they have to account for all possibilities, rather than just the ones that you need. You end up with bloated code, unless you know how it works behind the scenes (and many times even if you do, you can't take out the parts that you don't need).

> I've looked into frameworks like Django. It's not good because it abstracts away the functionality of the database. It's nice that everything is an object, but if you want to do something more complex and go around the framework, things get messy and start to feel hackish.

I was thinking the same when I first worked with frameworks (Rails at first, Django now...). First there was the honeymoon phase, where it seems like the framework does everything you need... then you start to encounter the first problems (i.e. try to do something thats a bit more complex...), and you start thinking; Well, the framework does everything for you 90% of the time, but the 10% when it doesn't makes up for the time you saved...

But I found that after working with a framework for a while (almost 2 years with Django in my case) you get to know its strength and its weakness, and you get to do more complex stuff a lot more easily (for example, I often resort to raw SQL with Django, it's just a matter of doing Model.objects.raw() ). In the end, I think it's worth working with a framework because well, obviously it prevents you from having to re-write boring boilerplate/glue code, but it also (usually, or perhaps I should say, hopefully) means you are working with a well-tested codebase on which to build up on. In my case, I would say the time it took me to really learn how to work with Django was worth it today, if only for the time it makes me save now!...

  >> I generally don't use a PHP framework. I have my own set of classes that I wrote (and improve on).

In other words you have written your own framework that suits you well. I would guess the only thing that stops this from being a general purpose framework is documentation and marketing.

To be fair, a couple of classes domake necessarily make a framework: http://en.wikipedia.org/wiki/Hollywood_Principle

"In other words you have written your own framework that suits you well. I would guess the only thing that stops this from being a general purpose framework is documentation and marketing."

In a way, yes. It's a boiler plate of classes that I use for most projects (db, sessions, and some other helpful funcs that I built).

If I could take out all of the crap that I don't need that is usually in most frameworks, I might consider using one.

Take a look at Sinatra.

Or Flask if you want to use python.

Ah yes, the inevitable "I write my own framework" post. This completely overlooks the fact that with a well-known framework you have thousands of other developers available to help you if you should run into a problem. It also overlooks the value of not re-inventing the wheel.

> I've looked into frameworks like Django. It's not good because it abstracts away the functionality of the database.

The Django ORM is no more or less easy to do your own queries as CakePHP, Propel, Doctrine, Hibernate, or SQLAlchemy:

  blogs = Blog.objects.raw('SELECT * FROM myapp_blog')

"with a well-known framework you have thousands of other developers available to help you if you should run into a problem"

Not always true - I'd say often not true.

1. I have to learn where to get support from these thousands of other developers.

2. I have to read through dozens of posts from others asking the same questions I have, but often phrased inconsistently.

3. I have to figure out which answers are correct, and which are wrong, and which were correct 2 years ago, but aren't right currently because 2 libraries are now deprecated.

4. I have to learn enough about the framework to be able to formulate coherent questions using the proper terms and express my specific problem.

5. I have to deal with 0 people responding after 4 days of posting.

6. I have to deal with responses just being "me too".

7. I have to deal with responses being "RTFM" or "LMGTFY".

8. I have to deal with well-intentioned people who ask me for help replicating my setup in their environment so they can help me.

And there's likely more variations I could think of that make the magic "there's thousands of developers to help" argument null and void in many situations.

I think stackoverflow.com pretty much solves all of these problems for you.