Ilya Sterin is a software engineer with Nextrials, a clinical trials data management software company and also consults for a variety of startups, specifically dealing with scalable and distributed system architectures. Ilya’s also a book and blog author and avid user and contributor to open source software. When not hacking on yet another software project, Ilya enjoys spending his time coaching his 10 year-old son’s ever growing amount of sports teams. Ilya is a DZone MVB and is not an employee of DZone and has posted 5 posts at DZone. View Full User Profile

Choosing a Web Development Framework/Toolkit

08.13.2009
| 7686 views |
  • submit to reddit

I'm sure I'm not the only lunatic that spends many hours well into the night thinking about web frameworks, but then again, maybe I am. This is all exacerbated by the fact that I work for startups, so requirements are much different that say someone working for an established corporation that has various standards and practices in place. I left the corporate world 4 years ago and haven't looked back. I love the dynamics of the startup environments and my personality fits very well with its culture and pace.

So some of the questions I battle with are, which framework should I use for this new project, or am I using the right framework for my current project? Is the framework and language it's written in supports writing applications in a powerful, flexible, fast, scalable way? A lot of the criteria I just listed are not as much framework as design and architecture of your applications and infrastructure, but frameworks can make it easier or harder to achieve such a desirable architecture.

The issue is not as pronounced for other non-web applications, mostly due to the fact that most Turing-complete languages are capable of performing the same job as any other, the only question is the programmers preference, proficiency, and the availability of some framework/abstraction to make your life a bit easier. In some languages, writing these abstractions is a breeze or in some instances they are not explicitly available because some or lost of boilerplate is reduced through various language idioms.

But web development is so complex these days, that simple abstractions are not enough. Anyone that thinks either hasn't created a serious web application or posses some information that I'd be willing to pay to have:-) Sure, with the knowledge of HTTP and some gateway protocol, whether its CGI, Java Servlets, WSGI, etc..., one can do almost anything that's possible on the web, but that's a pretty bad criteria to have in the age of ever so complex applications/features. One doesn't want to rewrite something from scratch. Authentications/Authorization for example, although many applications have a pretty custom authn/authz scheme, 80%+ of what's needed is boilerplate that I nor any experienced application developer cares to reinvent. I'd rather be doing more challenging things, not sure about you.

So many frameworks conceal some amount of boilerplate from the developer through abstractions. Right now, there seems to be two kinds of web framework camp schools of thought:

  1. I've done this many times before, trust me, you don't need anything else. I've extracted this, not made this up. The 20 applications that I've developed with this framework and extracted all of its generic concepts is all you'll ever need. Here is my convention down your throat. You think you need XYZ? No dumb ass, you just have no clue and your brain has all the baggage of a previous framework. Come on, open your mind, do you really need XYZ? You do? Well #$%@ you, go use someone else's framework.

  2. We don't know what the developer wants, he might want bar or foo or barfoo or foobar or foobarbarfoobarbar, or what ever they wake up and desire that day. We'll come up with abstractions that can be extended by other abstractions. But wait, what if the developer wants to extend those other abstractions, oh, well we must allow them to do so, so here are some more abstractions. Before you get started, here are 50 different things you must do, with xml or code bootstrapping.

The second camps sound nicer, more sane in some instances, and you're overwhelmed with the flexibility that makes you believe that nothing is impossible. But that's further from the truth.

I've mostly used the #2 frameworks, as with many years of development, I've developed quite a convention of my own. No, it's not that I'm not open minded old timer that is scared of change, actually I love change so much that I find spending many unproductive nights hacking something in a completely different language/frameworks, exploring the ever so unpopular technologies, etc... But my conventions have grown empirically, though I'm not easily swayed to go back 10 years ago when I had no experience and relearn from the same mistakes I've already made to just come to most likely the same conclusions. People do this all the time, in every field and I don't have grant money nor a big corporation blindly investing in my useless use of time.

I'm pretty big on DDD and OO and all the abstractions that come with it and I need a framework that allows me to do so, without forcing me to mix relational and OO concepts by forcing me to use a weak ORM, or no ORM, or an ORM that they choose for me. I also am more than capable of deciding whether I need a Repository data layer and not just a plain simple DAO layer. I know what I'm talking about, at least I think I do, so I don't need any 20 year old telling me that using recordsets that masquerade as domain objects is just fine. Maybe for you, but I have a different opinion. It's possible that your todo list will do just fine, but not my software that might start off with 10 domain objects concepts and grow larger as functionality is added. Ok, enough with my discontent with the 20 year old programmers, there are many of them that are brilliant, they'll just have to learn (or not) as the time goes on.

Now with all that's mentioned above, I also am very aware of over-engineering and aren't we all so good at it. So, when I'm not in the mood to over-engineer something, I'd like a simple way of accomplishing a task. Without all the enterprise application pattern abstractions, etc... Sometimes I just want to create a quick prototype, start off simple, then grow it if needed into a production ready piece of software. Eventually through constant refactoring, I'll add the necessary patterns/abstractions as my requirements grow or change.

With all the above rant, I'm yet to find a framework that can do this. Rails maybe comes close, only one problem. ActiveRecord is very limited and sucks. Besides the mapping limitations, you also bind your domain objects to the relational model and are constrained into modeling your domain in a unnatural way. This might be fine if you're building a small app in its isolation, but it's a huge technical debt if you're building a service model on top of a persistence model that might be used/reused by other domains or services, etc... I want to have a consistent, coherent domain which is available as a service to other services, like webapps, background processes, etc... Good luck doing this with Rails. It is true that when I'm first starting my app this might not be a requirement, but like any other startup company, we have a vision and if that vision is realized, we'd rather not have that much technical debt to pay before we can move forward.

So after all the rant above, what is it that I want? Here is a list. It's not comprehensive, just things I can think of at this time. I'll update it as I think of anything else.

  1. Support for MVC (most frameworks have pretty decent support for that now)
  2. Extensible MVC (need to be able to extend the way controllers and views operate. Some frameworks do it by convention and limit you to a set of popular conventions.)
  3. Allows you to build your domain in isolation. (I want my domain model to be completely decoupled from any web technologies, persistence, etc... Just a plain OO domain model)
  4. Gives you very flexible persistence options. (I might decide to use a fully featured ORM (ActiveRecord is not fully featured), or I might want to use SQL, or heck, I might want to do both for efficiency or to scratch a morning itch, who cares about the reason, please let me choose. Oh, and one more thing, what if I don't want to use a SQL database at all? I want to use a native XML store or better yet a key/value store. Even if it's just to piss someone off, I want to do this and one should be able to accomplish that pretty easily. I'm not asking for a mapper for these stores, simply just don't make your framework bound to some relational store though making the work of turning this dependency off a 5 hour chore.)
  5. Supports AJAX (I should be able to easily render JSON or XML views, without much plumbing or lots of mappings and annotations. The authentications and forms support should also expose some form of ajax compliant interfaces, so that forms and authentication can be done using ajax if I choose so. Be able to easily parse submitted data into some data structure and validate/synchronize it with the domain model.)
  6. Bindings (All frameworks have some sort of bindings. Some of them are limiting. I don't want to create command objects to just simply bind the data and than synch with my domain model. If I have domain object graph(s), I should be able to bind it in the view layer. Bindings should be customizable. In Spring MVC for example, you can only bind one input control to a field or set of fields in the command object, but what if I want to bind 3 input fields that collectively represent one field in the domain object, I'm out of luck, unless I use javascript to first serialize those input fields into one field. That really sucks.)
  7. Support RESTful, stateless, and other web concepts in a straightforward way. (I want to be able to configure every part of HTTP and the web and make the application work, look, interact in my way that's compatible with the web, not your way. Some component based frameworks make that harder that it should be, like the fact that they are inherently stateful by default. Some make it hard to support RESTful or custom URI schemes, because they transfer state through URL rewriting. All of these problems don't exist in some frameworks, like Rails, Spring MVC, Grails, etc..., so I know it's possible.)
  8. Validations (Most have fully fledged validation support, but I can't say that it can't be made a bit easier. I do like Spring's flexible validation support.)
  9. Forms (This is a big one. Can you provide a flexible way of creating forms and layouts. I mean seriously, we're developing forms today the same way we've developed forms 15 years ago. Every other aspect of development has moved on, but we're still doing bullshit html form controls. XForms is a way out, but no browser support and pretty hard to integrate support from vendors like Orbeon and Chiba makes the standard useless. Can we either embrace it or come up with something else. Am I the only one that gets an anxiety attack every time I think about creating yet another interactive form that doesn't do anything much differently than the form I created 4 months ago for a different project, though I either have to copy and paste all the cruft or start from the absolute scratch. Wow, that's sad IMO.)
  10. Scalability. I know this one again is not up to the framework, but as I mentioned before, the framework can make it easier or harder to achieve. For example, inherently stateful frameworks that require either session affinity or replication of session state, make it very hard to horizontally scale. Yes, I know you can scale with replications tools available out there, but any synchronous replications is not linearly scalable. So any such frameworks makes it harder. There are many other criteria that can make a framework more scalable than others, but in general, statelessness, stability, and speed makes it viable for faster scalability tunes.)

Ok, that's it for now, I need to vent before my brain allows me to think of other things I've encountered of my never ending framework journey. I'd really love for someone to just say, hey you're wrong, there is such a tool(s), here it is. I'd be eternally grateful. Many will say that it's useless to complain, if I see a need, help create the framework or functionality that you think is needed. I wish I had more time, until then, I'll continue to grunt and develop my own inner frameworks to make things easier. One day, if I have time, maybe I'll devote some time into making some existing open source framework better. I've had more time years ago and contributed to quite a few open source projects that I'm truly starting to miss it now. I still occasionally submit a patch or two to a framework I'm working on after fixing an issue or adding some feature, but at times I'm in such a hurry to move on to the next task, I don't have the time to package or generalize it enough to make it useful for everyone else.

Right now, I'm working with Grails after starting a project in Spring MVC and not being able to deliver functionality as quickly as I wanted. I'll have to live with some issues I found with Grails when I was using it about 4 months ago, like the fact that you must use hibernate or gorm, crappy groovy stack traces, etc... Hey, there is always something one might not like, but I really like Grails and am hoping that now that it's in the hands of SpringSource, they'll spruce up the documentation to be more like Spring's awesome documentation and clean it up a bit.

Update: I wanted to reiterate a bit on the Grails in regards to isolated domain model. Grails does allow you to create and isolate your domain model and its persistence, unfortunately you have to twist it's arm if it's anything outside of GORM. You don't have to add classes to domain directory, but wtf is it there for? Also, it would be nice if the grails team provided a way to specify which classes in the domain directory are persistent or not. I mean, a domain model != persistent entities. So transient classes and other domain artifacts should also be grouped together. Putting them into src/groovy sucks personally, because I have to navigate two directories now to look at what's supposed to be a coherent domain model.

From http://www.ilyasterin.com/blog/

Published at DZone with permission of Ilya Sterin, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Marc Stock replied on Thu, 2009/08/13 - 2:32pm

There is no one-size-fits-all framework and expecting there to be one is unrealistic. However, I would agree that most web frameworks suck. But in the end, you will always have some trade-offs to make. Personally, my fave right now is Wicket. It's the only framework that supports true re-use, it has an actual non-invasive answer for state management, and it's the only framework that I know of that actually provides true separation of concerns between the view and business logic. In Wicket, your HTML pages are actually just HTML pages and they stay that way so that if you have an HTML guy designing your site, he can continue designing and changing pages even after you put code behind it. Wicket is also designed entirely around the notion of convention over configuration. Unfortunately, it's just not as popular as it deserves to be.

People are still coding Struts 1 like there's no tomorrow and I wouldn't be surprised if it's the same story 5 years from now.

Jose Maria Arranz replied on Thu, 2009/08/13 - 3:28pm

@Marc: true separation of concerns between the view and business logic. In Wicket, your HTML pages are actually just HTML pages and they stay that way so that if you have an HTML guy designing your site, he can continue designing and changing pages even after you put code behind it.

Wicket is not the only player using this approach, see ItsNat (in fact I must recognize Wicket, to some extend, was a source of inspiration, anyway the result is very different).

 

Ilya Sterin replied on Thu, 2009/08/13 - 5:47pm in response to: Marc Stock

@Marc, true, I'm not necessarily looking for perfection. I'm just really confused about why the authors of the rapid frameworks think that it's **necessary** to lock someone into a convention they see good. Why not abstract away and bind everything through adapters, though allowing for any strategy to be interchangeable for any layer. To be honest, grails, rails, django, etc... pretty much cover a good 90% of what's needed on the MVC front and handle it pretty well, but why such a tight integration with the model. Model is usually a part of the domain of the application and that layer should be independent of any view/persistence technology. Take a look at GORM for instance, what happened to persistence abstraction. If the framework embraces an OO style of programming, why not allow the domain to be true OO and let the developer decide whether through configuration or explicitly through code how to persist this data. Provide just helpers. Now, many frameworks do this, but when you do, it gets pretty dirty. In grails for example when you want to mix GORM and regular objects, you have to do this in two different directories. WTF? Why not just use an annotation or some other way to denote a class as persistent or transient. What about if I want to persist 80% of my domain using GORM and the other domain entities using raw SQL through some DAO or Repository abstraction. I have to place files all over the place and I also loose some of the benefits that are not really persistence related, like validation, etc... Yes, there are in my opinion hacky ways of injecting that functionality, but it should be a no brainer, instead there are long discussions about how to do this and how to bypass a bunch of other issues it might cause. As far as Wicket, agree. I think Wicket is great, at least from the few hours i looked at it. I did much more with GWT and really like the component based development model. My biggest gripe with the component frameworks is their utter reliance on statefulness through sessions. That's a big scalability issue and I wouldn't want to tie myself into such a model. I looked around and found ways of making wicket more RESTful (stateless), but it's not really backed into it's model if I remember correctly. Please correct me if I'm wrong, I'd love to give it another try.

Walter Bogaardt replied on Thu, 2009/08/13 - 6:08pm

Silver bullet, or hammer is the best tool to fix all problems? This is why we have different layers with in enterprise applications. Your point about Rails being good. Is an example that works for smaller web applications, once the application starts to grow it becomes too big for one framework. Also remember, that persistnence layers and service layers have nothing to do with web applications. They are services to it, but you can plop on a GUI app or web service on those. This is one reason we have different frameworks in different areas of the application.

kelly jason replied on Thu, 2009/08/13 - 9:35pm

Fashion handbags LUXURY Handbags all are here!! Louis Vuitton or lv replica handbags ,wallets,purses & more! more information will make your startling!in b2ubags.com under affordable price with high quality

Ilya Sterin replied on Thu, 2009/08/13 - 10:44pm in response to: Walter Bogaardt

@Walter true, that's what I was actually saying. It is completely separate and though is a part of good design, but here is the problem. Frameworks that allow you to completely decouple these concerns mostly don't provide rapid app development like Rails, Grails, etc.... There is a lot of plumbing, but besides the plumbing, there is to high of a noise to signal ratio. That's bad IMO, at least for startups that have to produce rapid results with minimal people. Now, the rapid web frameworks are great as long as you use it within their constraints and utilize their conventions. Once you start deviating, it either becomes hard, you loose the whole benefit of even using that framework, or it just becomes an ugly mess. So far, I've been OK with conventions in most places, but what bothers me is the domain model conventions. The heart of your software, domain model, which should be completely decoupled from anything else and you should be able to bolt on a GUI, or integrate it with any other service, etc..., becomes too couples with the web framework and it's conventions. My point of the post is why? Does it really have to be that way? Why can't we have decoupled, flexible components and still get the benefit of rapid app development like Rails? There is no reason for it. Like Grails convention of persisting everything in the domain directory and with JPA or GORM at that. WTF? Who said I have to persist my domain classes and if I do, who said I have to utilize a relational backend? What if I want my persistence service to be a separate jar? What if I want to place my domain classes, which (I hope grails authors know this) are not comprised of only persistent entities, that's actually a small piece of the domain puzzle. There are value objects, transient objects, repository layers/factories, services, and other artifacts. It's fine to utilize the convention, but please allow us to override it easily. I don't want to put some classes in src/groovy, some in src/java, others in domain, others in services. WTF? I think there are better ways of accomplishing convention and I should be able to turn on/off each piece granularly. Bean validation shouldn't be tied to GORM injection. Rails suffers from same issues. I was looking around on how to utilize grails with data mapper or through explicit home grown persistence. Wow, the consensus is don't try it unless you want to get really really dirty. I think one framework that's somewhat appealing and that has the whole loosly coupled thing right is Pylons. I was actually going to utilize it on one of my projects, but pylons future is in question. The source is updated once every two weeks. The developers sometimes disappear for months stating work related issues. They haven't updated the roadmap in quite a while. So I'm a bit worried. Yes, I know it's open source and I love dabbling in source, contributing patches, functionality, etc..., but when I have a limited amount of time to build something, the last thing I want to do is spend a week fixing stuff that's not application related.

Marc Stock replied on Thu, 2009/08/13 - 11:19pm in response to: Ilya Sterin

@Ilya Wicket supports detachable models so you can minimize how much is stored in the session. In this scenario, you can keep the state wherever you want (like the database) and keep it cached for quick reference.

Bruno Vernay replied on Fri, 2009/08/14 - 3:28am

I have been following the "Web Framework" thing for quite some time now and it is just too broad to mean anything. You look at it from the point of view of decoupling your domain model from the framework, but other will be interested in AJAX or scalability. And as usual everyone will come with its own recommendations, even if I see less and less passion in the "Web Framework". So my only point would be: choose a more specific title and head line if you want to gather some attention !

Shaw Gar replied on Fri, 2009/08/14 - 3:45am

Hi There, Your article is too verbose. Consider making it more concise or if you have a lot of things to say, split them into multiple articles. I hope the feedback is taken in good sense.

When I switched to Java, one of the things I had the most trouble with was web layer. I'm not sure if I'm alone, but one of the hardest part I had with Spring was it's web tier - Spring MVC.

The fact that we have too many web frameworks (and I'm not complaining), probably makes us keep trying alternatives or marry one with the other, to get a solution. If we had only one or two web frameworks we would have probably got adjusted, found some ugly hacks and lived with it. A lot of platforms do that today. In Java people generally try to find elegant solutions, and that probably results in a lot of web frameworks. That or the technology doesn't lend itself too well for the web layer. The biggest peeve I have with Java is the web tier. To me every other problem in Java seems to have been solved in a very elegant manner, except for web.

It is fair to say that web layer is also too complicated, and highly competitive. It's not easy for Java to catch up with the rest of the industry.

Casper Bang replied on Fri, 2009/08/14 - 1:17pm

You are not the first to ask these questions. There are too many choices in Java, but many incl. me now consider Wicket to be the best of breed framework if you like OO and are ok with state on the server. Sometimes less is more, Wicket seems to make the right compromizes especially when compared to something as ivery towery as JSF. Of course, these opinions vary tremendously for the same reason some people prefer a Viper over a Ferrari.

Ilya Sterin replied on Sat, 2009/08/15 - 12:37am in response to: Casper Bang

I'm really not familiar with wicket outside of looking at it about 2 years ago and really enjoying it. It fits certain applications, specifically the ones that don't need much scaling out of the box. The reason I say this (please correct me if I'm wrong), is that everything in wicket seems stateful (due to callbacks). I believe there are stateless pages now, but sessions are still created and seems like interaction in these pages happen through some weird URL rewriting? Maybe it's just the few examples i looked at, but sessions are a huge scalability block. Outside of conversation flow, they are generally not needed and overused and in most action based frameworks they are not used unless explicitly required. Wicket seems to rely much on sessions for interaction. Yes, I know you can store session state in the db, but I think minimizing the session or any info that needs to be replicated between cluster nodes is the key to scaling horizontally. Session replication and/or session affinity are not scalable. Can you provide more insight into Wicket and stateless/RESTful applications? Ilya

Gary Purnomosidi replied on Sat, 2009/08/15 - 9:50am

There are 2 web frameworks i would recommend: Stripes & ZK. Both are easy to learn and support ajax.

Stripes is action framework like struts but far better, while ZK is component based framework like wicket. For Stripes you still need to combine wih javascript library like Jquery or mono. Not to mention you also need to learn css, html, and jsp/freemarker .

On the contrary, you don't actually need to learn html, jsp/freemarker, javascript dom and css stuffs with ZK (you only need to learn java). Furthermore, there is ZK developer studio eclipse plugin for designing ZK GUI. 

 

Stripes framework website - www.stripesframework.org

ZK framewework website - www.zkoss.org

 

 

 

 

Jose Maria Arranz replied on Sat, 2009/08/15 - 6:02am in response to: Ilya Sterin

@Ilya Stering: Session affinity is not scalable

Really?

I can understand your statement about session replication but I don't buy your argument about session affinity, memory is really cheap and if you can sacrifice fail over (in 99% of cases, db transaction integrity is enough) I don't see why is not horizontally scalable.

 

Ilya Sterin replied on Sat, 2009/08/15 - 8:55pm in response to: Jose Maria Arranz

You're right, it depends on your load patterns, etc... I probably shouldn't of generalized it this way. Round robing session affinity is not scalable. With a complex load balancing scheme and session affinity you can most likely scale. It's not about memory, it's just because round robin or other naive load balancing with session affinity, just like with poor hashing algorithms, uneven distribution can cause issues. So I take my argument about general session affinity back, rather I mean that poor distribution of session affinity doesn't scale. With that I must also say that it's pretty hard to design good load balancer. In a lot of cases the algorithm has to take into consideration application level and session level usage and semantics. This is also true for hash based partitioning. There is not a one size fits all algorithm. Now, with that said, it's much easier to scale stateless architectures, though why they have been some hyped (and for the right reasons). With stateless architectures, you have less to worry about, and less complex more generic load balancing schemes can be used.

Bozhidar Bozhanov replied on Sun, 2009/08/16 - 1:27am

Actually, JSF is not that much 'ivory towery'. I'm using JSF 1.2 now + RichFaces, and I must say, this is pretty much sufficient. It offers almost all the abstractions that can possibly be needed (and even such that would not be needed). Yes, it has drawbacks, which are being addressed in JSF 2.0.

Jose Maria Arranz replied on Sun, 2009/08/16 - 6:45am in response to: Ilya Sterin

I can't say very much about load balancing scalability.

I want to correct one previous statement of me about "sacrifice fail over" if you use session affinity. This is not fully true, session data can be persisted too in session affinity and another node can load the persisted session when the previous "proprietary" node crashes. This kind of fail over is obviously not so "hot" and quick as with session replication (the data is already in memory).

@Ilya Stering: With stateless architectures, you have less to worry about, and less complex more generic load balancing schemes can be use.

In a happy and idyllic world of honest end users, where the technology installed is highly controlled, powerful browsers executing more powerful and speeder languages than JavaScript (for instance Java), enormous disk capacity (and right to use), and enormous bandwith to load instantaneously the new application version... we could send SQL statements from the browser :)

In a real world, fully stateless (pursuing an anemic server) is a myth:

* The critical part of the application must be in the server, is not only security, is corporative privacy important too.

* Validations must be performed on the server too. Yes, end users can be bad guys.

* We cannot send very complex applications to the client, too much code to send and JavaScript is slow and definitively not the best language to manage much and complex code.

* In a fully stateless application user data must be sent again and again to the server. How much data can we send to the server whether the typical DSL connection usually has an anemic bandwith for uploading? For instance, the download bandwith is 20x greater than upload in my fiber cable connection at home. 

* JavaScript is anemic compared with Java, .Net etc, in client we lost amazing tools like ORMs, and in server to build again and again the same objects using an ORM may be not a good idea (because we cannot save objects in memory).

* Business data may be complex, this data model must be constructed in client in JavaScript and reconstructed in server again and again as Java objects (for instance to be used with ORMs).

* Sometimes some decisions about what the client must see (again corporative privacy), must be executed in server... then some visual state must be saved in server this implies view rendering should be done in server.

In summary, fully stateless may be a good objective but it can be a hard fight, what in client? what in server? is just the server like a C function?  

In my opinion, life in server is by far easier, all is near, all is Java, all is cached if needed, no custom bridges, no client-server repetition, no work to be in sync...

 

Walter Bogaardt replied on Mon, 2009/08/17 - 7:37pm in response to: Ilya Sterin

Sounds like a simple enhancement to the Domain model ala annotations of say JPA that notates that the Entity domain is none persistable or transient and another annotation that says persist ala this method, jar file, text file.

Annotations simply is meta information that framework authors can use to make their frameworks a bit more flexible. 

I've done work on a Crank project that is scoped to allow just crud operations on tables in a database. Going beyond that and just like Rails and anything else you start to see problems because of the underlying complexity. There is one side of trying to be as abstract enough to handle most use cases, but when you start to make the framework more specific to handle some domain model space, which can have a large number of use cases that becomes very difficult across the multitude of industries. 

 

Kelly Stevens replied on Sun, 2009/12/13 - 11:14pm

One of my biggest pet peeves about programming in java is that there are so many different frameworks to choose from. I spent a few years as a Java developer and as far as programming with the language, I am fine, but if you asked me to sit down and create a site from scratch I wouldn't know where to start. I enjoyed reading your post and at least got a little insite of how a Java developer approaches how to pick the framework to use. I have been a .Net developer for the last 4 years and I personally like that the .Net framework contains everything you need and you don't have to learn a whole bunch of different ones.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.