To be fair ,aside from a Servlet container and JDBC none of these things are required for Java web development. Java language doesn't help though and could use more features from C# for instance.
Well I think the point is that it's a cultural thing. I really like Java, but it takes unconventional approaches to avoid bloat when working with Java tools because the "standard" way of doing things produces 200+ line stack traces.
You're going to be using a framework when you work for a company. Whether its a custom in-house framework (pray to the holy death it isn't) or something third-party (cry me a fucking river, you have to learn something new).
Just make sure you don't forget how to not use frameworks.
Yeah to clarify: you or your team members MIGHT build something awesome because you and they are awesome, but the chances are the custom framework was built by your boss 10 years ago and the server has already been hacked.
Yeah that stuck out like a sore thumb for me as well. Pretty tacky example. I'm sure it was just meant to convey a tongue-in-cheek sarcastic tone, but it's in pretty poor taste.
EDIT: I knew that would get a laugh. It was a good joke. I chortled. I don't get offended by every off-hand phrase in life when no one's hurt in the process. If you're offended by the joke then you are the one with issues, not the joke.
I thinks its up to every persons responsibility to learn to deal with rough language. The world isn't easy, and we need to learn to deal with it contents.
I don't think "picking on the language of others" is a good start. What about the people starving right now in less developed countries? And the homelessness problem? Companies doing serious damage to the environment? And we both are just sitting here discussing language on the Internet. I think you are not in the Position to talk about a better world as excuse for political over-correctness.
what about them really? I don't think these topics would make a great joke either :-/
"picking on the language of others" could so easily be transformed to "picking on the behaviour of others". there are so many things to do with a hammer, and i think we should pick more on the people who use it to kill women, or suggest it as a joke.
Language is a different shoe from what we actually do. HN is not a good place for this, drop me a mail on [redacted] if you are further interested in discussion.
Update: Removed the unnecessary and (as noted below) false remark about Joel not understanding Dependency Injection.
The main (but not only) reason we have object factories is to be able to extract code suitable to be unit-tested from the whole application. And unit testing is like testing the tire of a car in a laboratory instead of testing the whole car on a race track. Not that we don't test cars on race tracks - but it is a lot cheaper to test the tires in labs first.
It is not that we sell Object Factories so that people can produce their objects - we use Object Factories in our code - so that the objects are better encapsulated. Once you understand that - the whole satire with hammer factories collapses. But OK frameworks are still yet another subject and I kind of agree that libraries are often better (http://perlalchemy.blogspot.com/2010/02/frameworks-are-frami...).
1. This was not written by Joel himself. This was written by a guy named Benji Smith on JoS forum.
2. I understand dependency injection completely but question if it's really required to write quality software OR is it a technique you use because programming languages are lacking.
Let me give you an example. In .NET world, there is a product called, Isolator by a company called TypeMock. It can let you mock any type/method by exploiting CLR.
In .NET, there is a type called System.DateTime with a static property DateTime.Now. I have seen code where people try to write interfaces to inject DateTime.Now. And I think it's an overkill. When I saw their example of how they can mock DateTime.Now without doing DI, I am personally convinced that DI is about addressing limitations of your statically typed language and is not an absolute must.
Mocking is global - when you need two objects that need to have two different DateTime.Now - then you are out of lack if you mock it. DI is just a bit more universal than mocking. On they other hand mocking is simpler - agreed.
Thanks for correcting me about who was the author.
Here's the current status of .NET software development.
I think there is a broad agreement that unit testing is a very useful tool in developing quality software. Because of the inherent limitation of C#, you can't unit test easily if you don't use DI. This often leads to a situation where you have tons of interfaces + each interface is implemented exactly by one class. This is because product like Isolator is not free. Hyptothetically, if Isolator was provided by Microsoft for free, I am sure that we will see reduced usage of DI.
Don't get me wrong, I think there are other scenarios where DI is a great technique in designing components which are flexible. However, those scenarios are not that many. Using DI to make your software unit testable is an overkill IMHO.
But still I haven't done with frameworks, mostly because when I build a house and I have nothing to start with, I could very well use a factory factory factory, which could provide me with factories, than to run to a shop every time I need something.
Say for example, what I need is a url routing system, I could very well use a routing framework than to write one myself. A user authentication system is such a common task that I'd rather generate one with a factory than to run myself to a shop to buy one.
Frameworks have their place in my toolkit. Using them only at the right time with the right purpose is what will make the difference.
Agreed, frameworks are tools to be used or abused. The main problem with Joel's analogy is really that factories did not replace hammers. Hammers and factories and everything in between are always available to us.
If you're a home builder, I would expect you to already have what you need to build one, and not running elsewhere to buy parts that everyone uses on their houses, too. Unless you're just a tract house builder cranking 'em out without a care for what they look like.
Frameworks seem to be most useful for churning out a lot of mediocre websites quickly. If you're doing something really original, a framework is less useful.
Another downside of frameworks is maintenance. A company hires an outsourcing company to make a website. They use a framework, and might not even use it correctly. The incentive is for the outsourcing company to use a framework, because that lets them ship a website that sort of mostly works quickly, so they can get paid.
The contract is over and now some other programmer (such as me) is now supporting it. Now, making changes is several of order of magnitudes harder, because you're fighting the framework in addition to the code that was already written (especially when they didn't use the framework correctly).
For example, I was working on a website that used Zend forms. Now I needed to modify the form so that it was pre-populated with the data (an edit page instead of a submit page). I spent a couple days looking at the code and the zend documentation, and I just couldn't figure it out. The form had some javascript on it also, so I couldn't just use value="" to pre-populate the data.
It it was plain HTML/PHP, I could have just used value="" to pre-populate the data and be done in 5 minutes. The framework make a 5 minute task almost impossible.
> If you're doing something really original, a framework is less useful.
Waaaait a minute - what kind of frameworks are we talking about here? You can build loads of things with Django. I can build VERY unique sites with backbone... i don't understand the opening comment. Hell, even bootstrap can be tweaked beyond recognition without terrible code.
Edit:
> They use a framework, and might not even use it correctly.
That's a shitty company or developer, not a symptom of the framework.
Surely you would rather work on an established documented framework than a custom undocumented mess from the same shit company?
My experience with frameworks has been that, once you go outside the stuff that comes with the framework, they start to hold you back more than they help you.
It's also a nightmare to go into someone else's poorly written framework code and try to maintain it, especially because frameworks have "magic" where functions are not explicitly invoked, so it's almost impossible to trace the control flow.
Every time I've been maintaining someone else's framework code, the project was a mess. I don't see how frameworks are so awesome if so many people use them incorrectly.
For example, at my last job, they were using angular.js. Every 30-60 minutes the website just randomly crashed. There were all sorts of weird "$digest in progress" errors and bizarre errors. I know they weren't using angular correctly, but if a group of average developers are using angular incorrectly, do you blame them or blame angular?
> My experience with frameworks has been that, once you go outside the stuff that comes with the framework, they start to hold you back more than they help you.
That's why I prefer to use microframeworks over full blown frameworks. I can make it get out of the way if I want to by swapping out parts I dont like.
Well first, angular is not so great, but that's only one framework.
> once you go outside the stuff that comes with the framework, they start to hold you back more than they help you
If you're talking something like angular, you are correct. If you're talking about something such as Django, not so much.
> nightmare to go into someone else's poorly written framework code and try to maintain it
Try doing it with undocumented custom code.
> especially because frameworks have "magic" where functions are not explicitly invoked
It is your duty to read the source code when all else fails. If you start doing this you will also most likely start seeing a distinct difference between the acceleration of your career vs. your coworkers.
> Every time I've been maintaining someone else's framework code, the project was a mess
you have been working with or following behind poor developers. their custom code would most likely have been equally terrible and rife with bugs.
> I don't see how frameworks are so awesome if so many people use them incorrectly.
So are guns, drugs, genitalia and cars but people use that stuff wrong all the time.
Frameworks are nice for these reasons:
1. they can help you learn how to build your own frameworks
2. they are typically documented (hopefully well-so)
3. the fact that you can identify which mistakes your coworkers made quickly ("oh, they should have used this class, function or file structure because it says so in the docs", vs trying to track down the original dev or read through mountains of source code to figure out what some undocumented thing does).
Edit: i wish i would get told why i'm getting down voted on this rather than just down voted for an unknown reason. Is it the snarky remark that contains the word "genitalia"?
>It is your duty to read the source code when all else fails.
Wait? I have to read the source to use a framework? Which is it? Frameworks are awesome because they are well-documented? Frameworks are awesome because you can read the source when you're fighting some obscure bug?
The problem with reading the framework source is that, the bits of the framework being used are usually only 1%-5%, so now I'm digging through some mountain to find the tiny bit I'm looking for.
If I have a problem with GCC or PHP, I don't (normally) have to read the GCC source or PHP source. Why should I have to read the framework source in order to find out how it works?
> Wait? I have to read the source to use a framework? Which is it? Frameworks are awesome because they are well-documented? Frameworks are awesome because you can read the source when you're fighting some obscure bug?
Well, I said "when all else fails". If for some reason you are unable to find the answer to the issue you face within the documentation, then as a developer you have to dive into the source code.
> now I'm digging through some mountain to find the tiny bit I'm looking for
What is the reverse case? Why is custom code different?
> If I have a problem with GCC or PHP, I don't (normally) have to read the GCC source or PHP source. Why should I have to read the framework source in order to find out how it works?
Correct, but if you have a problem with a PHP website, you typically do open up the website's PHP source code and read it. I don't understand how custom code solves the problem of needing to read source code.
With custom code, there usually is just enough code to solve the specific problem. With a framework, there's also the code that comes with the framework that this project doesn't use. The framework is a super-generalized solution, and it comes with a lot of code my use case doesn't need, which makes it a lot harder if I need to trace through the framework to find the problem.
My boss wants the bug fixed in a couple hours. I can't spend a couple weeks reading the framework source so I can fix the bug. (For the zend form example, I wound up writing my own form instead of reusing what was already there.)
If I have a problem with a website written in PHP, I read the PHP source and can fix the problem. If I have a problem with a website written in PHP plus a framework, now I'm expected to read the PHP code PLUS the code for the framework? That's several orders of magnitude more work.
> My boss wants the bug fixed in a couple hours. I can't spend a couple weeks reading the framework source so I can fix the bug.
Perhaps you feel I am saying that you must exhaustively read the framework's source code to understand it. I am not. You should have the ability to quickly open up your framework of choice's source code, navigate to the portion that contains the relevant bit of info you need and go from there.
"going from there" sometimes entails referencing a few base classes or figuring out what the result of some custom methods or functions do. It shouldn't require understanding every line of code of the framework.
> now I'm expected to read the PHP code PLUS the code for the framework?
Only if the framework's documentation or the internet fail to answer your question faster, yes.
The contract is over and now some other programmer (such as me) is now supporting it. Now, making changes is several of order of magnitudes harder, because you're fighting the framework
That's barely ever the case though. A framework guarantees consistency. You can complain about the Zend framework, but it has documentation you can look up. If an outsourcing company wrote it from scratch you'd have no-one to ask and no further information to pick the code apart.
You're complaining about a framework that doesn't have the feature you wanted, but that doesn't invalidate the concept of frameworks.
I looked at the zend documentation, and it was basically an auto-generated list of function names. I looked through the specific Form class they were using, and it was useless, just a list of function names with no description of what the parameters meant.
The documentation for other frameworks I read was similar.
Actually, they have another project written in a custom framework, which is also a nightmare, but it's less bloated and I was able to figure out how it works by reading the source.
So frameworks are bad because one framework you used was more bloated than the other? It's not just documentation - Googling "zend form prepopulate data" returns a ton of Stack Overflow answers.
I'm not saying every framework is amazing, I'm saying that using public, known frameworks means there is a lot more support available for you out there. Not least because these frameworks have had many eyes review them - the custom framework you used was less bloated this time, but there's literally zero guarantee of quality there.
Yeah, I was googling carefully. It wasn't just a zend form, they had derived from the zend Form class and added their own custom logic. After a couple days, I couldn't figure it out, either by looking at their code or the zend documentation.
To me it sounds like the issue you faced was one of maintaining someone else's nightmarish code, not necessarily one caused by a framework. I still don't see how the absence of a framework would have made it any easier to deal with this contractor's work. In my (very) limited experience I would wager that if they'd been left to implement all functionality themselves they would have left you much worse off.
I've seen frameworks degenerate into a mess both for outsourcing firm projects, and projects developed internally.
You might say "They were using the framework incorrectly!", but if it's too easy to use a framework incorrectly, then I don't see the value it provides.
Without a framework, it's much easier to trace the control flow. If the code is in 2-5 files that are explicitly included, that's a lot easier to understand than when files get magically included from all over the place.
I haven't seen a single MVC-style framework that I liked. I don't understand how such an awful idea can be so popular. It sucks to be in an industry that chases fads over substance.
MVC frameworks I have tried at work:
Java/Spring/jsp/beans
Ruby on Rails
angular.js
zend
All were awful.
I do like libraries, things you can plug and play and use where you want (like jQuery). A framework demands that your whole application be written in its style.
For example, the Ruby on Rails project used a legacy database, which was not written in primary key autoincrement integer Rails style. That project was a disaster and that startup failed. With financial data, demanding the primary key to be autoincrement integer forces a lot of unnecessary joins, when you already have natural keys like Ticker or CUSIP.
I love lightweight frameworks that exist mainly to reduce boilerplate code and, for web development, mitigate cross-browser compatibility issues. ExpressJS and jQuery are good JavaScript examples.
I tend to avoid frameworks that attempt to push developers into coding "the framework's way" (cough cough AngularJS). Such frameworks are often great in the beginning, but once you pass the basic application stage, a deep understanding of the framework itself will become necessary and it will stop saving you time. Sometimes you have to adapt special ways of writing tests, debug nonsensical stack trace dumps, etc. Not to mention it increases the overhead of bringing new developers on the project.
tl;dr Don't use heavyweight frameworks unless you have a good reason.
> a deep understanding of the framework itself will become necessary and it will stop saving you time
This is true for any 3rd party code you're going to use.If you don't know the difference between jQuery the DOM and how to go from one to the other within jQuery you're going to do a lot of mistakes as DOM apis evolve fast while jQuery features don't.
> I tend to avoid frameworks that attempt to push developers into coding "the framework's way"
What makes you think your way is better? and when you end up working with several devs , are going to meet every morning to talk about what's the good way to do things for every aspect of the project ? using a third party frameworks helps , people only have to agree on what 3rd party code they are going to use.
And libraries are not black boxes. Reading 10 000 lines of code shouldn't considered a burden or one should reconsider career choices.
jquery is a library not a framework but yeah i agree
edit: sheesh why did i get downvoted for this? it is absolutely a library which is completely different from a framework. even jquery's website says it is a library.
While there are a couple of guys still shaving that yak, today it's more or less Jetty micro services all the way. Still Java but a huge step forward from the J2EE abstraction astronaut crap you had to put up with for a while. Configuring factory factories suck on a whole different level from ordinary coding.
Wasn't really trying to sell anything and I can't see the connection between micro services and factory factories, except that they were both once the next big thing. I'm just saying at least it's getting better for the Java folks.
I disagree with the message here - unless you have exceptional requirements, frameworks can be extremely useful. To give an example of their utility, I am currently building a site for an online community I run - on top of my regular job, exercise, and contract work, free time is hard to come by. I went with Sails.js and Fluxible on top of React to assist me with putting together a good frame since when I start letting the three other developers in the community develop features for the site, they will have an easier time searching for solutions due to existing documentation and Stack Overflow.
The core logic is decoupled from any particular franework though, and only makes use of each framework for their strengths. The important thing is to be judicious in your use of a framework.
