7 ms·

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 framework

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.

wakaflaka 13y ago
Reinventing the wheel at every turn!
nathan_long 13y ago
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.
grammaton 13y ago
This is a known anti-pattern.
- astrodust 13y ago
  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.
  - banachtarski 13y ago
    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.
coldtea 13y ago
>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.
- nathan_long 13y ago
  > 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.
  - coldtea 13y ago
    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).
    - astrodust 13y ago
      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.
      - coldtea 13y ago
kayoone 13y ago
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 ;)
- 7mediaws 13y ago
  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.
  - astrodust 13y ago
    So you re-implement another framework? Brilliant.
  - kayoone 13y ago
    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.
mkilling 13y ago
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.
- VLM 13y ago
  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.
  - astrodust 13y ago
    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.
    - banachtarski 13y ago
      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.

wakaflaka 13y ago

Reinventing the wheel at every turn!

nathan_long 13y ago

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.

grammaton 13y ago

This is a known anti-pattern.

astrodust 13y ago
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.
- banachtarski 13y ago
  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.

coldtea 13y ago

>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.

nathan_long 13y ago
> 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.
- coldtea 13y ago
  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).
  - astrodust 13y ago
    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.
    - coldtea 13y ago

kayoone 13y ago

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 ;)

7mediaws 13y ago
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.
- astrodust 13y ago
  So you re-implement another framework? Brilliant.
- kayoone 13y ago
  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.

mkilling 13y ago

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.

VLM 13y ago
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.
- astrodust 13y ago
  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.
  - banachtarski 13y ago
    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.