Hacker News Reader

Comment by banachtarski | Hacker News Reader

This sums up more or less why I ditched Rails altogether.

Funny enough, one commenter on this article advocated Rails:

"I don't want to start yet another religious war, but for a nice respite from the complexities of J2EE frameworks, check out Ruby on Rails. I'm playing with it now and it is a pleasure to work with."

I was actually surprised to see this is from 2005 too...

It was frameworks like the ones Joel was railing against that inspired Rails.

A framework should help you do your job, not get in the way.

(post was by BenjiSmith, just on Joel's site)

Ah, good point.

Really? IMO, there are many reasons why you would want to ditch Rails, but factories of factories is not one of them.

It's not just the factories of factories thing. It's actually the amount of cruft that I don't think is really necessary. I find that the pattern for programming with Rails is to find a gem that more or less does what you want and drop it in, at least, on most developer teams I've seen use Rails. What ends up happening is the creation of this bloated monstrosity that performs like crap for a number of unknown reasons.

Ditched...for what?

Writing my own! You'd be surprised at how lean the code is if you only write what you need. For others, I'd recommend trying one of the lighter weight frameworks (like Sinatra or something if you're into Ruby). Cowboy is good if you're into Erlang.

*edit: Perhaps "writing my own" was not the best usage of words. There is a way to provide server services without writing everything from scratch. I use a number of open source libraries but I refuse to fall into the usage of factory factory factory blueprints that bundle tons of features I don't need.

Reinventing the wheel at every turn!

Writing your own framework may be the best decision for your project. However, it's almost guaranteed that the next developer on your project would find a known framework with known conventions to be easier to understand.

I'm not saying your tradeoff is wrong, just that there is one.

This is a known anti-pattern.

The real anti-pattern is "My application is simple, so I don't need a framework". Simple applications are ideal for frameworks. It's the crazy hard stuff where frameworks break down.

I completely agree here. I think frameworks excel at making easy-to-medium tasks nearly trivial. It's the space beyond the medium-hard task that frameworks have trouble with.

>Reinventing the wheel at every turn!

Perhaps you never heard of this thing called libraries...

It's not "reinventing the wheel", it's designing and building the kind of house you want (with tons of tools at your disposal), instead of living in some customized trailer construction.

Not to mention that "reinventing the wheel" is very useful in itself. I wouldn't want to use the wooden wheels of 1800 horse carriages in my car.

> it's designing and building the kind of house you want

Yes, and that may be a fine decision. If it's your house, and you want ringing the doorbell to play a symphony, and you want to store your cereal in the closet, that's fine. Whatever make s you happy.

The issue is when you ask other people to live in the house with you. How hard will it be for them? Is the cost worth it?

Maybe yes, maybe no.

That's a false dichotomy.

A framework DOES include stuff that you're not gonna need, and also makes several architectural decisions for you. That's a given.

A custom build (with libraries) site does not imply it will be done in some bizzaro way ("cereal in the closet", etc). That's NOT a given.

So that particular accusation against frameworks is definitive, whereas what your particular accusation against projects not using frameworks is a maybe.

(Not to mention that some frameworks, e.g a lot of Java ones, do enforce themselves a "cereal in the closet" --or AbstractFactorySingletonFactoryProxy -- mentality).

If it's customary to store the cereal in the closet in a framework, then people will know where to look for cereal.

On the other hand, if you store your cereal under a squeaky board in the kitchen, that's not helping anyone.

Or, you know, you can build your own house AND keep the cereal in a normal place.

My analogy was terrible. I admit it. But in actual practice, software varies more than houses do.

You could easily walk into my house and find the kitchen. The stove and sink are both there as expected. But despite how carefully I thought it through and built it, and despite the fact that it made perfect sense to me, I doubt you'd find my custom-built intranet app easy to navigate.

On the other hand, my last Rails app has a structure familiar to any Rails developer. The actual business logic is unique, but that's the part that has to be unique. "How do we update the database schema?" is a given.

And if it's unfamiliar, there's plenty of documentation and blog posts to help you. With custom-built code, there's no help on the web.

To go down the car analogy rabbit hole, this is not like using obsolete technology (wagon wheels) but instead having a car that uses a completely non-standard size of tires and a bolt pattern that no other manufacturer uses so you need to get your rims custom made.

You see this sort of engineering all the time. Why does that device you just got use a non-standard power plug? What is it doing that's so special that any of the half-dozen standard types wouldn't work?

When you go and custom make something, you better have a good reason for it.

You do that until you need more flexibility or a broader scope and realize it would have been wiser to start with a sophisticated framework from the get-go. Trust me, been there more than once ;)

Or you could build your own framework that meets a specific standard that allows an instant drop of other libraries to extend your custom framework.

So you re-implement another framework? Brilliant.

The problem is that you will probably never get to the point of the vision you had initally. Be it because of time (deadlines), changing requirements, teams changing etc. The effort to roll your own is hardly ever worth it.

The more code you roll yourself the higher the likelihood that you will have to fix critical bugs on a Saturday night at 1am. It will happen.

And if you rely on someone elses code which you don't understand, you won't even be able to fix the critical bug. At least you stand a chance with your own code.

Experience a couple "framework emergencies" then you'll hate them too. And I thought they were supposed to make things faster and easier, not the reverse.

Nope.

Your homebrew framework is going to have to go through all the same growing pains as any other, but you won't have anyone to lean on when the going gets tough.

If it's an open-source framework you're using, you can always fork and fix or monkeypatch if you've got problems. Most of the time your issue will be patched already in a pull-request, it's just a case of applying it. Rarely do you have a situation so unique that nobody else has experienced it.

Except, of course, when you're using your own framework.

I've seen so many projects flame out in a spectacular way when developers get it in their head that they can write their own framework, or that they don't need a framework at all. That's the first step towards unmitigated disaster. The next step is to fall into a hole that you can't get out of without a whole lot of work, and have to solve a problem that those frameworks you should've used in the first place have already addressed.

Don't forget that code you understand today quickly turns into code you don't understand in the future. Don't think just because you wrote it you're automatically golden when it comes to making fixes.

It's a fine line and slippery slope to be sure. I think that after programming for many years though, a seasoned developer should have honed instincts as to what is probably an established pattern and what isn't. For me, the decision was made when I found I was wasting more time wrestling with the framework rather than just using it.

What framework were you having such a hard time with? Most you need to do it "their way" or you'll be going against the grain all the time.

I've spent a long time in Rails and it solves most Web + CRUD problems well enough. When it doesn't you have options.

Recently I've been doing more NodeJS stuff which requires a completely different mind-set. If you try and do Rails in NodeJS you will fail, and vice-versa. Same goes for something like Django.

This is why picking a framework that approximates your requirements and matches with your philosophy as closely as possible is essential.

Going without a framework is almost always a disaster. At the very least pick one that's thin enough it doesn't get in the way.

Yea that's just the thing. I don't build web apps. I was a backend developer and there are lot of things that have to happen on the backend that doesn't fit in the standard CRUD or MVC pattern.

I think you're overgeneralizing on the last point. I've shipped things without a framework that have been some of the most stable pieces of software I've written.

"or that they don't need a framework at all."

And that is the fundamental mistargeting of most framework marketing. The ideal short demo or short tutorial for a framework is probably a noob-friendly simple "CRUD plus a little bit". On the other hand that is a horrible actual application for a framework, all that complexity for little reward. And its such a noob magnet. Never programmed in ruby before? No problemo, "rails new crud-demo" and good luck.

I'll agree you need a framework to do something complicated. Not everything is complicated, or grows to become complicated.

This may be the hidden meaning of the original article from 2005. Superficially the joke is frameworks are hyper abstracted into factories for factories for factories (well maybe yes, maybe no). But the more fundamental interpretation of the story is I don't want to enter mass production, I want a fast simple reliable one-off. It will never be the next twitter and it will never be used by more than 1000 people. And sometimes, that's OK.

Not necessarily. I think I've fixed my lion's share of other people's code that I have embedded in my own systems. In fact, I've never been up on a Saturday night due to my own bugs. In the afternoon when I'm trying to fix my unit tests sure, but not Saturday at 1am.

In an isolated system, sure. Or extremely well defined fully enforced demarcation points in a large system, sure. However as part of a large business system, that can be completely out of your control.

Especially if there is a demarcation point or highly detailed definition, but multiple incompatible interpretations simultaneously exist.

If the concept of the failure mode doesn't even exist when the unit test is being written, or is in direct opposition to the stated business plan at that time so "it can't happen" then unit tests can't help.

Even worse is political issues. Yeah sure I promised in writing our demarc point is I'd send you an ASCII file but it changed at midnight to UTF-16 strings inside an XML file and you're either going to like it or work elsewhere and I can make this stick. Oh, well, when you put it that way, then I guess that's why I'm working at 1 AM. A contrived example for short simplicity, the real world is much longer and more complicated.

Reply on news.ycombinator.com