> @Alex Objelean & Igor Vanyberg-2 > Yea, my bad on just posting something up here without looking at any > previous posts. Look, it was my rant and how I felt about things at the > time. Nothing personal. This was actually the clean version for public > consumption. It was probably still too rude though. Sorry about that. I > suppose it would be lame to spend a lot of time on a framework and then have > some kid post up a “Wicket Sucks” post.
If you want to blow off steam and tell people you think X sucks, that's fine, but do it on a blog or something. It's just bad style to do this on a list that is meant to help out with X. If at all, the developer list would be better, but even then, you may want to consider having a chat with some of the developers first to see what their reasons for some of the things you dislike may be. Anyway, constructive criticism is good on a list like that, but I didn't get much of the constructiveness... > @Jonathan Locke > I agree that Java is fast. I don't worry about scaling and performance > because of that. To the people worrying about memory, I don't think that is > a big deal. Sure any framework is going to waste more memory than bare > bones JSP/Servlets, but memory is cheap. Eclipse is like the biggest hog > ever and look at how successful it is. > > Also, I am sticking with Java. I have a really good job and such. The only > reason I would ever move is if I could land a leet job in the Valley doing > Python at some sweet start-up. Not likely though. Do you live in the Bay Area? Seems to me there's plenty of work for folks wanting to do coding in other languages than Java, particularly for startups. > Java is better than some > of the alternatives out there: > http://harmful.cat-v.org/software/ruby/rails/is-a-ghetto. Scala is still > too unstable. The other Java web-frameworks are all flawed too. I don't > hate my job either. Any choice will have it's own disadvantages. Also depends on what you use a language for. I'm not sold on Scala, but I wouldn't think it's not stable enough for production. May have to be careful doing upgrades maybe. > @sthomps > LOL! You know Eleco Hilenius wrote the “Wicket in Action” book? For some > reason I can't stop laughing. Now everyone is going to think you are a > badass at work. The book is decent, but it would be nice if the next > edition would have a chapter at the end that rewrites the “Cheese Store” > into “Cheese Store 2.0,” using all the advanced stuff that was explained in > the latter chapters. It would help Wicket newcomers like me. It would also > show how to do a real app with best-practices. Well, I can tell you that I hated every minute of writing it :-) One of these things one can do to 'just have done once in a life' and I'm happy to hear from people that were helped by it, and hope it helped the framework reach a certain stage of 'maturity', but never again will I write tech book in my life. Anyway, I always thought and still think that a good set of examples and test cases are often more valuable to a project. Imho the first chapter of Wicket In Action is the most important one, as it goes into the why and rough outline of how. After that, I think you should hit the examples and dig through the code. That at least works best for me... then again, I'm very much an autodidact kind of guy and respect that this is not the best way for everyone. Now, since I'm typing anyway, here are my 2c on your points: * "Violates Dry" -> It does a bit, but I believe for a reasonable purpose. We've explored several alternatives at some point, but felt this was the least of evils * "Not previewable" -> Hah, this one is funny... point by point; - "First, we don't have seperate designers at my company" -> so... who's fault is that? - "Second, it is better if the samer person" -> ah, so you think that 1 is a good idea. Well, I - as I'm sure most people who've worked on projects with some scale will agree with - disagree with you on that. Unless you are a fantastic UX persons. But most likely (just statistics, sorry) as you're posting to a programming list, you're not does development and design. - "Third, if you use extends your page will not be priviewable..." -> Yep. So if you use it, you lose that benefit. You could not use it, or just suck it up and still be happy with the other benefits that a good separation of concerns give you. * "Violates MVC" -> Who cares about MVC purity. It hasn't been 'pure' since the original article. Funny you mention Spring MVC, as I think that having special constructs for 'flow' is just very silly unless maybe you are writing a business process engine. * "Excessively verbose and complicated" -> Verbosity is often there to make it easier to understand what something is/ might do. I'm sure we don't always succeed in that. Complicated is something that Wicket is also. We've been trying to find the right balance between that and power. Some things worked out better than others. * "Breaks POJOS" -> every frameworks comes with it's own rules that are typically limiting in one way or the other. Wicket is a stateful framework by design, your most important state is component/ model state, and that needs to be persisted somehow. You can write your own serialization code technically, but concretely, this is indeed a Wicket limitation. Is it really a bit deal? Not in my opinion. * "Terrible AJAX" -> I would go further than that and argue that most Ajax support in Java frameworks is retarded. We made a best effort, and imho you need to understand it in the context of that Ajax just started to get all that press when we were in the early stages of developing Wicket. Nowadays, I would argue that you shouldn't abstract something like jQuery at all. I'm nowadays using Wicket for basic page set up and things like navigation and authorization, and do most of the interaction on pages through JavaScript calling HTTP services (which we implement using Jersey/ JaxRS). That doesn't make Wicket a failed framework for me; I'm just using a relatively small portion of it. * "Bad Defaults" -> Yep. Though understand that Wicket is a stateful framework by default, with statelessness as an added feature afterwards (I know this, because I argued for it and implemented a good share of it). If *I* would write a Wicket follow up today (don't worry, I won't), I would probably make it stateless. But it would be much more limited and not as quick to develop with and not as statically typed. So many of my colleagues here wouldn't like it, and they'd have good reasons for that as well. In the end everything is about tradeoffs, and clearly, you didn't agree with many of Wicket's. Ok, I'm going to skip over a whole bunch of stuff. I'm basically agreeing with about half of what you say, but disagree with your choice of forum etc. This though: "What was wrong with JSPs/Servlets"... You have got to be joking. I actually started out with that way back when. Led a team of 5 coders writing JSP/ Servlets full time. It was awful. Horrible. Still wake up screaming at night some times. Then Struts came along. Which looked roughly like the framework that I developed in-house with my tiny little coding experience I had back then. Got a lot of press so I thought it must be good. It wasn't of course, as nowadays anyone with half a brain will tell you. I've made some effort trying to describe these problems in the first chapter of Wicket In Action, and probably about a million discussions on the interwebs. Here's a rant on my own long deceased blog: http://tinyurl.com/7z8zqa9 Eelco --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
