Wicket isn’t suited for Websites

In this article I describe why Wicket framework isn’t suited for websites. But I first start defining the difference between Websites and Webapps.

Websites vs Webapps:

A webapp behaves like a desktop client-server application, but it’s accessible via an URL in a webbrowser instead of as an executable on an OS. Webapps can be rendered in HTML, but also in Flash, Silverlight, Applets etc. Webapps usually don’t have content that should be indexed by search engines, so Search Engine Optimalization (SEO) plays no role in webapps.

A Website on the other hand, is less focussed on the application, but more on serving its content to users, usually rendered in HTML instead of Flash etc. SEO is usually very important.

There are far more website than webapps on the Internet, although a clear distinction between a webapp and a website can sometimes be a bit difficult. Some websites contain parts that can be seen as a webapp. The focus of it determines whether it should be called a webapp or a website. If it’s the primary goal is serving content to users, than it’s a website. If it’s primary goal is allowing users to add/control content where serving content plays a lesser role, than it’s a webapp.

Website owners often try to get as many visitors as possible, this includes search engines. Webapps on the other hand, are often internal for a company, and only want a small number of people to be able to control and view it’s content.

In this article, I’ll describe why Wicket isn’t suited for websites, and that Wicket is targeting Webapps instead.

Sessions:

When developing websites that primarily serve content, the unnecessary usage of sessions should be avoided when the memory costs of sessions are relatively high. However sessions are often needed to preserve state among webpages, especially when users have the ability to login at a website. So in the ideal case, when a guest visits a page, then no sessions are used, but when the guests logs in, than that same page can use sessions. With effort, to some extent, it is possible to achieve this in Wicket, but it’s difficult because Wicket is a framework that heavily depends on session state, and the session size is relatively high. Wicket does have some stateless components that can be used, but only a few exist and they are not matured. To be sessionless, all resources (pages) that are requested by the user within 30 minutes (default) should be completely stateless. If only one Wicket component is stateful, then sessions will be created automatically.

Session memory problems can easily occur when a cookie disabled client (webbrowser or bot) visits a Wicket website. These client will cause new sessions to be created at every page load/refresh. When a single page contains multiple session-state components that are requested under a separate http request as result of a single page request, then the number of sessions can explode. Especially when a bot visits the website. (But you don’t want to block bots, because if you have a website, Search Engine bots are very welcome. This is different when you have a webapp instead of a website.)

So developing (sessionless) websites using Wicket is difficult. There are only a small amount of stateless components, and they aren’t matured.

Ajax:

Basically every web application/website can rendered using just simple HTML, when looking at it in from functional system perspective. However, if you want to take more out of the system, it can be improved  using Javascript/Ajax. Ajax improves user interaction by greatly reducing response times of sending information to the users. So in the end, every matured website should use Ajax. But as told before, there are only a few stateless components in Wicket, and stateless Ajax components don’t exist.

If it was possible in Wicket, then a problem that arises is how to deal with Ajax requests. You don’t want a full Wicket page to be constructed on every Ajax request.

Ending:

Even though Wicket advertises itself with “just HTML”, which makes the suggestion that it is suitable for websites, it is only targeting Webapps. But in contrast to websites, you don’t need “just HTML” for webapps. Webapps can also be build using only Javascript/Ajax solutions because they don’t have SEO requirements.

I like Wickets, there aren’t much similar frameworks that have the same programming model. I hope the Wicket team realises that sessionless/stateless components are very important when it comes to website development in contrast to webapp development.


Updated/added at 27 January 2011:

To come back at my comment of maybe being to harsh at session usage for public facing websites, I don’t think session usage would be a big problem if the session size was small. But the session usage in Wicket is large.
(Size can be checked using RequestCycle.get().getSession().getSizeInBytes() , which has to be called after the page is fully loaded and stored in the session.)

Wicket stores almost everything in sessions for a page is stateful, even when using models. For example, when you want to render a list of String that is retrieved from the database, and render it on a stateful page, then you can use a loadableDetachableModel to retrieve the data without storing/serializing all the strings in the that model. But when you render the strings using a listview, you have to add labels to the listview’s items in the populateItem method (at least if you want to do it the Wicket way). But the labels itself will contain a model that stores the String anyway. Or you can use a compoundpropertymodel using item.setModel(new CompoundPropertyModel(item.getModel())), but that also adds extra objects to the session.

Example, if you have a list of 2253 strings, which in total is 17.5kbyte (7.96kbyte/string on average), that you want to be rendered on a stateful page, then it will cost you about 198kbyte in session usage when using the nested CompoundPropertyModel approach. It will even be larger when using a default label model. 198kbyte imo is way too much, that part of the page should be 0 kbyte.

If you have an internal webapp than you can calculate the maximum memory usage based on a fixed number of internal concurrent users. But if you have a public facing website, than calculating the maximum memory usage is hard. Public facing websites want to attract as many visitors as possible. The number of concurrent users can vary daily. It’s possible that due to linking of external websites, a website get an order of magnitude higher number of visitors the next day. Which can easily cause big problems on website that use large sessions sizes.

29 thoughts on “Wicket isn’t suited for Websites”

  1. > stateless Ajax components don’t exist

    Not true, that is, they can be created. At tipspot.com we display information in a lightbox that is retrieved from stateless Wicket pages.

    We also found a filter that prevents the creation of a session from cookie-less visitors.

    Although I technically agree with a lot of things here, I am not sure the distinction between webapps and websites can be made at all. Anyways, putting it out there like this keeps people sharp…

  2. There are certainly a number of problems where Wicket wouldn’t be the best tool for the job, and public facing (anonymous access) web sites are such jobs.

    But now, look at the alternatives… what are good frameworks for such sites? Surely not the model 2 frameworks, as any complexity at all often forces developers into relying on session state or things get very messy. Just use Ajax you say? Yes, but then you might as well use e.g. Wicket to bootstrap pages and do the rest with say jQuery and Jersey (I’ve done that this year, and that works well). Or use GWT maybe? Nah, forget about SEO and back button support. JSF? Has the same potential state problems Wicket has. Wicket is very explicit about relying on session state, where several other frameworks just don’t tell you about it.

    Anyway, if I were to redesign Wicket, definitively one of the first things I would try to take on would be the stateless mode, and implement it such that it would be easier to stick in stateless mode (e.g. by letting Wicket throw errors/ warnings when breaking out of it when you configure that, and also turning off the ability to do component replacements when in stateless mode, so that it is easier to check for statelessness.

  3. “Or use GWT maybe? Nah, forget about SEO and back button support.”

    GWT offer support for both. The problem in fact doesn’t change for a site using javascript or a site that perform any action (Back forward should not give an error or bill your credit card 2 time).

    For CEO, what ever the technology, you must ensure to provide a simple HTML version of all pages you want to be indexed. And theses pages must not depend on javascript, flash, silverlight, session, cookie or anything to render properly the public content.

    That’s it you should have a persistant URL for all public resources you want to share on the web(like sold items in Amazon website). It is better if theses URL never change so they can be bookmarked.

    You can then provide features (like buying items) using any technology you want. For exemple, amazon allows users to listen to music before buying it using flash.

    Despite that, javascript technologies (including GWT) tend to be better for public site because it is easier to enhance the CEO content with it.

    The more problematic part maybe is to deal with history inside a webpage. You can just avoid it : RIA content in the page is just small enhancements and has no history support. Let say you can add an item to cart without leaving the actual page, and using the back button will not remove the item for the cart. But go to the previous page.

    That a perfectly acceptable behaviour (And not so much websites/apps really undo your actions when you go to the previous page).

    If you want to provide “back” and bookmark support into the same HTML page, it is a litle more difficult :
    – Each state inside the page shall have a distinct URL (using #)
    – your javascript code shall listen for history event and update the page content accordingly
    – you should indicate an equivalent URL without the # so search engine can reach it.

  4. Wicket is a statefull web framework, but can also be configured to work in stateless mode. Having said that for stateless website, the best approach is REST with JavaScript. Although I admit wicket has quite a learning curve, the kind of problem it solves are quite complex, but i hope wicket introduces first class stateless support.

  5. In my employer-sponsored class on web security, it says that all state which must be protected should reside on the server. State sent back and forth to the browser, and protections that exist only on the browser are too easily hacked.

    This suggests a natural boundary. Wicket should be used for web features that require security, whereas some other website mechanism may be more appropriate for dealing solely with public domain information. Use whatever web technology seems appropriate for manipulating customers’ shopping carts, but as soon as they’ve decided to purchase it’s time to shift into Wicket or some other state-oriented technology.

    Shifting back and forth, between Wicket and whatever, e.g. when a customer starts to enter personal information and then decides to do a bit more shopping before completing the transaction, is the challenging part. Trying to do everything within one framework may result in a memory hog if you choose Wicket or an insecure and unmaintainable ball of mud with most (though not all) other web frameworks.

  6. Although I was skeptical at first, I think this article makes a good point. Wicket wants to maintain session state throughout the web site’s interaction with each user. The Wicket team has said that they strive to keep the session resource requirements to a minimum, which would help with the server load and responsiveness. But the need to maintain a session seems like a lot of overhead if a visitor is simply (say) reading old articles, browsing a catalog, or using the site “search” capability – these are mainly “output” tasks that should not rely on a personalized session.

    Providing a user-centric site without maintaining a full session for each visitor is tough, though. To use Amazon as a well-understood example (substitute Facebook if you like), the site owners want to know who you are even if you’re just browsing or searching: every action you take on the website is valuable for their analysis of your personality and interests, and that knowledge in turn supports their commercial goals. As soon as you have logged in, your page choices and the timings of your every action are stored in some form as part of your permanent profile. Maintaining a session for each visitor is not a disadvantage for these kinds of sites, it is a necessity.

    If you accept that your own site needs sessions for all visitors, then Wicket does not look so bad. The detailed knowledge of each user’s interactions with your site are worth the resources needed to maintain sessions (which can be made lightweight even in Wicket, for example, by using detachable models). But if you want to optimize your site so that only visitors who are interacting with the site (in the “webapp” sense proposed by the article above) need to have sessions, you need a plan to separate page presentation mechanisms so that Wicket provides only the “webapp”-style pages while a low-overhead approach serves anonymous or non-session visitors. You will lose the detailed knowledge that Amazon can collect, but you will be able to serve more visitors and page requests per time period with the server resources you save.

    Our own approach has been to identify the website’s “content” pages and the mechanisms surrounding them (search, browse, etc.) and build them to work without user sessions (e.g., in HTML, Velocity, etc.). In contrast, every user-aware / session-aware function is a Wicket application. Most or all of these are handled as “mini-apps” performing only one function. For example, “Log On” is a stand-alone Wicket function that loads from a known URL.

    The minimum of state information is shared between these mini-apps: user ID, JAAS authorization array, data object keys (not entire records or object trees), and “current page state” indicators for any open “mini-apps”. For session-based “mini-apps” like the shopping cart, which have several pages in a linear or branching flow, the Wicket mini-application is built to show the correct page and contents based on your previous actions within the same session. For example, if you loaded some items into the shopping cart, viewed them, then jumped to “Log On” before you begin payment, you will return once “Log On” is complete to the shopping cart page you last saw, with your selected items still showing as you saw them before.

    This approach may not be ideal, but it is simple to set up and to communicate to developers. Unfortunately, I have no numbers for session size, requests / second, or maximum server session count to state definitively whether it is worth the trouble of doing it this way, as opposed to making the entire website a single Wicket application. Knowing that every site has different requirements means that you may have to answer the question yourself anyway, based on your own site’s server capacity, visitor statistics, and amount of web-page automation.

    Time constraints limit a full discussion here, but I would like to thank the author for raising this point.

  7. Some valid points, some incorrect generalizations.

    I certainly wouldn’t suggest Facebook, Google or Twitter guys to switch to Wicket, but all this ‘it doesn’t scale’ thing is mostly exagerated.

    Well, everybody hopes that the site their building will have gazillions of visitors, but… when was the last time any of you, author and readers of this post actually did it?

    The same happens with NoSQL. How many of you actually needed this Google-like scalability? That is not to say that using non-relational persistence in some cases saves a lot of time and money, even if your traffic is low (for example, too many or large files, stored as blobs in a database can kill your app, make DB administration very hard, and require very high hardware specs, even with low volumes of user access), but the idea that NoSQL data stores are intrinsically better, faster, and easier is complete BS.

    I’d say that I wouldn’t use anything other than Wicket (if I’m the one to choose, of course), for ‘enterprise applications’: internal use, moderate to very complex, large, with high security requirements, but with controlled access (even if it’s accessed through Internet, it needs authentication).

    For web sites, if it’s small, it’s perfectly fine to be built with Wicket, even with high volume access, since with few pages, you have more time to tweak your pages and make’em completely stateless. For example, blogs in genral have two to four public-facing pages (many post, one post, author profile), but the administration view (which is much more complex) have a much lower number of accesses (only the admin, or few admins), and it’s perfectly fine to allow them to have session state. A CMS will have similar needs. So do most of the web sites you see in the Internet.

    So, is Wicket not suitable for web sites? Maybe, it depends on your web site, your skills, even your taste.

    But, dear author, is there any framework you actually like? Your blog seems to be dedicated to say how web frameworks are bad and ugly 🙂

  8. Oh, @Nicolas, about GWT and SEO, if I say to my boss that we need to build the app twice, because of the technology we chose, I’d be fired in no time…

  9. @Erik van Oosten
    >> stateless Ajax components don’t exist
    > Not true, that is, they can be created. At tipspot.com we display information in a lightbox that is retrieved from stateless Wicket pages.
    When looking at tipspot.com, the “Netwerk” link seems to perform an ajax call to fetch the page http://www.tipspot.com/dialog/loginSignup/ and then shows it in a lightbox. But this solution bypasses Wicket; it’s a Javascript/Ajax solution that retrieves the page, it’s not Wicket specific.

    > We also found a filter that prevents the creation of a session from cookie-less visitors.
    You mean you filter out the jsessionid from URLs written via Servlets response.encodeURL() (which is used by most Java frameworks, including Wicket) ? Filtering out jsessionid from written URLs does not prevent session creation on the server. On a cookie-less client, this results in the opposite of preventing session creation: every HTTP request will create a new session for a cookie-less client instead of reusing an existing session. (I have just tested this at tipspot.com.)
    But filtering jsessionids can still be useful for SEO and pretty bookmarkable URLs.

    > I am not sure the distinction between webapps and websites can be made at all.
    Some frameworks target a very different kind of *websites* than other frameworks. Like GWT vs Rails. It’s impossible to make a websites written in Rails with GWT, SEO will fail. On the other hand, it’s also difficult/complex to make websites written in GWT with Rails, like Gmail or Google Analytics. These frameworks clearly target different kind of *websites*, which IMO can broadly be divides in websites and webapps.

    @Eelco Hillenius
    > There are certainly a number of problems where Wicket wouldn’t be the best tool for the job, and public facing (anonymous access) web sites are such jobs.

    I think public facing (anonymous access) are the majority of websites. It would be great if Wicket would also target these kind of systems using stateless Ajax and more stateless components.

    > what are good frameworks for such sites? Surely not the model 2 frameworks, as any complexity at all often forces developers into relying on session state or things get very messy.

    ASP.NET comes close by using viewstate postbacks (but also allowing session state), although this solution also has drawback (as every state solution). I think the best thing would be if the developer could choose between state solution. Each problem could require a different state solution. What keeps surprising me is that even though there are so many Java web frameworks, and only a few .NET web frameworks, client sided viewstate postbacks solutions aren’t available in Java frameworks, or very rare.

    @Nicolas
    >GWT offer support for both.
    Google does crawl Javascript a bit, but crawling a full GWT site is hard for bots I think. I searched for GWT (or Vaadin) SEO solutions, but haven’t seen good concrete solutions yet.

    @fsilber
    IMO shopping carts etc. should use sessions. I also don’t see a shopping carts as part of a public facing (anonymous access, Google crawlable) part of a website. Because you don’t want shopping carts to be indexed, and you don’t expect the majority of visitors to use it every time they visit a website.

    @Johannes Faustus
    Websites that need to collect data from visitors for intelligence don’t necessarily need sessions. Cookies can also be used to track visitors, but I see your point.
    When hardware costs are no problem and scalability is limitless, then sessions probably wouldn’t be a problem.
    Wikipedia doesn’t use sessions. If they would use Wicket (with session), they would probably have to invest more in hardware.
    I had some bad experiences using sessions in Wicket that caused low performance and memory issues. But maybe I was using Wicket models in the wrong way, I should look at it again. But I also hate sessions because of their timeouts. (Although there are some workarounds on that, but unnecessary imo, it adds complexity.) Sessions are also a problem when you redeploy often; e.g. when a user types a blog post, and a Wicket website is rebooted, than the user will have a problem when the website is up again, because his blog post will be posted to a missing session. (Of course there are workarounds for this, but again this unnecessary added complexity.)

    @Tetsuo
    >I’d say that I wouldn’t use anything other than Wicket (if I’m the one to choose, of course), for ‘enterprise applications’: internal use, moderate to very complex, large, with high security requirements, but with controlled access (even if it’s accessed through Internet, it needs authentication).

    I would like to see Wicket to be used for every type of website, especially public facing websites, like Wikipedia and blogs. That’s where its “just HTML” power shines. In Internal Enterprise apps, I wouldn’t care at HTML/javascript/flash/silverlight at all, because bookmarkability and search engine bots don’t play a role.

    >But, dear author, is there any framework you actually like?
    I like the ideas of Wicket and ASP.NET. But I haven’t found a webframework that I completely like. Every webframework I have seen yet, all have their problems. But I do think the one size fits all idea should be possible for a webframework.

  10. “There are certainly a number of problems where Wicket wouldn’t be the best tool for the job, and public facing (anonymous access) web sites are such jobs.”

    Eelco, I have to disagree. There is a public facing web site, with a very large number of users (casino.betfair.com) which, guess what…. is developed with Wicket. Myth busted.

  11. I used Wicket once…. NEVER again. What a terrible piece of software. They haven’t updated/upgraded/patched it since… when? I don’t know, but hell it feels like something older than Java itself.

    No rest support. Seriously? I wanted to create a symple AJAX API for my customers, in order to deliver my data in a different way for other applications (Iphone, facebook, etc)… who doesn’t nowadays. Geesh, I just installed Spring MVC servlet to do that simple task because Wicket is terrible obscure and nonsense. Documentation is poor (to say something nice) and many of the demos you should use to learn the thing (in the official website of wicketstuff site) doesn’t even work. Comparing GWT (and GWT support) with Wicket is almost offensive.

    Al the history thing in Wicket, all the sessions nightmare. This cannot be serialize, that constructor won’t be called in every page refresh, you cannot have 2 concurrent ajax request (imagine you have a long polling going on there) because a Page is not threadsafe and it will lock on access, you cannot get rid of wicket sh*t on the url really (try submitting a form with errors that is returned and tell me what you see there… and try to get rid of it!) … agggggg the pain. Thank God all that is finished now for me!

    Then, who’s using wicket. Oh yes, here https://cwiki.apache.org/WICKET/websites-based-on-wicket.html you will see that many of the pages list there DON’T use wicket anymore (try http://www.varma.fi, listed there). Who uses GWT? well, plenty of webpages, starting by Google that has recently migrated all google groups to GWT and more other services to come. Who uses SPRINGMVC? plenty of webpages out there. Technologies that are all the rage now.

    I’ll be honest here. Wicket is for people who really doesn’t know/want to do webprogramming. Doesn’t want to get dirty with the details. Buf if you want to do something like gmail, facebook, twitter or the like, you HAVE TO. Forget the magic formulas that promise you to do everything. No wicket will help here.

    Well, I’m sorry for this vent. I really needed it, I hate Wicket framework so deeply. I learned my leason regarding webframeworks, I guess.

  12. @Tetsuo

    GWT is just plain HTML, CSS and javascript. You can choose the templating engine of your choice for the public content (JSP, PHP, Wicket…) and instead of using javascript + JQuery (or YUI, or flash…) for the dynamic part of your site, you just use GWT.

    Typically you will not go for a “single page design” for parts of your site that are to be indexed and bookmarked. This is only if you do that that CEO, backward and bookmark support start to make you code some UI logic twice.

    One could say why not just javascript, why GWT anyway ?

    1) You use java for the server side, so using java for the client let you share the same code being a productivity advantage
    2) Some part of your client UI is really complex and show benefits from a statically typed and a real OO language.
    3) Optimisations that would require lot of effort to do by yourself and bring stellar performance to your website, allowing it to scale :
    – embed small images directly into the HTML avoiding unecessary round trips
    – automatically bundle pictures in image sprites
    – automatically deal with version of all your resources (picture, CSS, js, everything) so that all is cached forever but the new version is downloaded transparently as soon as it is available
    – localisation at compile time (compiler produce JS/HTML/CSS for each browser & locale combination)
    – compress and obfuscate the HTML & JS code so that is require less bandwidth
    – split you JS code in several files for a faster UI start if needed.
    – All UI code produced by GWT is plain HTML,CSS, javascript. All static files. You can serve them with apache or any webserver you like with no backend or application server. That’s mean that you can serve your RIA app as fast as you’ll serve any static HTML.

  13. @ulon are you some kind of FUD spread-manager? All you’ve mentioned about wicket is false and have an argument… but I don’t think anybody should bother to contradict you..

  14. @admin (I cannot find your actual name anywhere):
    > @Erik van Oosten
    > > > stateless Ajax components don’t exist
    > > Not true, that is, they can be created. At tipspot.com we display information in a lightbox that is retrieved from stateless Wicket pages.
    > When looking at tipspot.com, the “Netwerk” link seems to perform an ajax call to fetch the page http://www.tipspot.com/dialog/loginSignup/ and then shows it in a lightbox. But this solution bypasses Wicket; it’s a Javascript/Ajax solution that retrieves the page, it’s not Wicket specific.

    Of course it is like that, its the simplest thing that works (and it works well). I do not consider this by-passing wicket; its implemented with (our own) wicket components all the way.

    > > We also found a filter that prevents the creation of a session from cookie-less visitors.
    > You mean you filter out the jsessionid from URLs written via Servlets response.encodeURL() (which is used by most Java frameworks, including Wicket) ? Filtering out jsessionid from written URLs does not prevent session creation on the server. On a cookie-less client, this results in the opposite of preventing session creation: every HTTP request will create a new session for a cookie-less client instead of reusing an existing session. (I have just tested this at tipspot.com.)
    > But filtering jsessionids can still be useful for SEO and pretty bookmarkable URLs.

    I am not talking about that (though we do that as well). The filter I was talking about kills the session at the end of the request when it sees certain user-agents (those of some known crawlers). So its not entirely as I wrote in my first comment (sorry for that). Normal cookie-less browsers can create new sessions.

  15. @admin regarding your update, there is no framework which is suited for a public facing website without scaling it horizontally. The stateless pages support provided by wicket, allows you to build a website which doesn’t store state and can be easily deployed on unlimited number of boxes and handle virtually unlimited number of concurrent requests. It is true that you have to pay more attention to build a totally stateless page, but that doesn’t mean that it is impossible.

  16. @Alex
    My point is that the stateless support of Wicket is too low. Wicket is architectured to be stateful, and provides a limited set of small stateless components. Stateless Ajax support doesn’t exist. Of course you can hack your own way around Wickets architecture, and make your own Ajax solution in Wicket in a cumbersome/complex way, but then you can also take another framework with better stateless ajax support and try to do the same.

  17. About the list of Strings: You have to keep it somewhere. If you have it stored in the database (or file, or is generated on-the-fly), as you said, you don’t have to keep it in the session.

    If you’d have to keep a separate list per user in memory, no framework would help you with that (the difference is that, with Struts, you’d have to put it in session scope by hand).

    If you have a ‘singleton’ list, and want to show it without storing it per session, you just have to use it just like you do with database-backed lists, use a LoadableDetachableModel instead of passing the raw list to the ListView.

  18. .Thoughts on Tapestry 5.I was very interested in seeing if Tapestry 5 lived up to its promise of significantly better performance and scalability which is known to come at a cost a that treats web-pages as static structures that can be pooled. One example of what this means is that you cant rely on constructors anymore so you now have to figure out other ways of re-initializing your server-state if applicable after you are handed an instance from the pool.

  19. All these talks, yet not a single post for alternative. Yes, we all wish to have everything in a perfect world, and drive the flying car to work. But in reality compromises have to be made. You’re asking to buy a 120 MPG electric car with all bell and whistle…for the price of a Ford Focus.

    The truth is you can always hand code the heck out of a platform (say php) to get the max performance (yeah…like facebook, they write own freakin php compiler and engine), because they have that need and…RESOURCE. But wicket live on the other end of the spectrum….say the grad student in the basement with an idea, or the consultant w/ a yesterday deadline. They need a presentation layer thats fast to dev, great to refactor down the road, and integrate !00% to all the java libs they can use out there, with “decent” performance. If there are other alternative please let us know.

    There are so many diff Ajax/javascript, if it’s not complex, you can always hand code your own solution. wicket has one of the best API with javascript for rolling your own. If the functionality is heavy on javascript, light on server and no need for session, you can always use a velocity engine as well in the mix.

    Which bring to the final point……Website webapp…..THERE ARE NO DIFF! We’re moving faster toward more complexity/functionalities, thus abstraction (in logic/lang/hardware…etc.) are needed. 20 years ago they’d be happy using a cgi script site with a tiny database, now site ops are expected to know everything about the visitors, able to deploy they site/app in the cloud, and there are datacenter that devote great resource to run JUST the middle business logic layer for user sessions. Is ebay a webapp or a website I ask you? Plus we have advances in CPU/GPU and memory, so that we can pay the higher memory/cpu price for our site/app nowaday.

    Either you hire a team of architects and code monkey and build your own API. Or you use say PHP, a not-strongly-type lang with better performance in presentation layer. Or you use something like wicket.

    And for the guy that says wicket is for people who dunno web programming. No need to say anything, as every competent dev out there know that’s stupidity talking. The apache guy brought wicket under their umbrella for a reason, they ain’t bunch of hacks. And if you don’t know, then time for you to read up and learn more.

  20. @admin Wicket is not inventing sessions for the sake of making things complicated. Please don’t see it that way or tell people as if it were. In my opinion, Wicket aims to be capable of solving complicated problems of web applications in as a simple way as possible. If your page just presents plain static content, like 2253 strings in one page, mere plain html is enough.

  21. This blog just wants to gain audience, creating discrepancies, based on pure ignorance. Wicket is highly used for social networking, online banking, etc.. You can criticize, do not take too long on the market, or that their learning curve is high, but criticize issues of productivity, cost, maintainability and performance, borders on the absurd. Just check the technology decisions of some major companies (Wells Fargo, Coldwell Banker, Wall Mart, etc), who have created their “websites” in Wicket.

  22. Wicket RULES. During the 3-4 (since 2008) years ive been using it ive very seldom ended in dead ends or unsolvable problems. Ive tried many of web frameworks (ror, jsf, cappuchino, php/smarty) and all seem retarded in comparrison to wicket. Infact, after a while with wicket you realize you can almost do desktop applications with it. Many of us do backoffice applications/restricted sites that dont have 1000s of simultanous users. And for that job i wouldnt chose any other tool than wicket. Plus, ajax works like a charm and i dont have to write stupid timecounsuming server client integration code (often different languages).

  23. Since this blogpost is doing rather good in google, I decided to chime in like some others. Most of the comments regarding wicket not being suitable for public-facing stateless websites are quite frankly FUD.

    We’ve been using wicket for years now (since the 1.3 betas).
    One of the platforms we’ve built on it serves about 6000 public facing websites.
    When I just started with wicket it took a while to make the shift (I did a lot of php work before that), and I was a bit worried about performance. With php that was a legitimate concern: adding complexity meant measurable slowdowns.
    Ever since doing more wicket projects I have been blown away by it’s performance. Of course this is in big part due to the jvm being as performant as it is, but nevertheless: wicket shines too.

    The funny thing is that we monitor all of our apps using newrelic, including our php apps.
    The complex wicket app that hosts 6000 sites consistently pushes out pages in ~20ms (wicket time) plus about 10ms database. Even the simplest php apps we run take at least 35ms (of course we’re using an opcode cache, before you ask), and the performance is less consistent than the wicket/jvm combo. These apps I mention run on the same hardware.
    Also, in case wicket’s performance is not enough, there is always the option to stick varnish or nginx in front of it, like you would do with pretty much any other framework our there which can support complexity (e.g. website/webapp combinations like e-commerce).

    This is also shown by recent performance comparisons, e.g. the one by techempower.

    Long story short: yes, you need to have some experience with wicket to make it shine. Getting the hang of models and staying stateless takes some time. But once you have that knowledge wicket is a truly great piece of kit for most projects.

  24. Wicket is by far the best web framework out there.
    Session size can easily be managed via @Stateless pages
    The separation of html and code and AJAX support is phenomena and code is much easier to maintain.
    Coupled with JQuery, Bootstrap, Spring/JSON and Hibernate you can create any type of application you want, whether it be a small departmental web app with a focus on fast development, functionality and release or a REST based large user base site feature a mash of Stateless wicket pages and Jquery / JSON integrated components.

    LEARN WICKET. It is phenomenal

  25. “Example, if you have a list of 2253 strings, which in total is 17.5kbyte (7.96kbyte/string on average), that you want to be rendered on a stateful page, then it will cost you about 198kbyte in session usage when using the nested CompoundPropertyModel approach. It will even be larger when using a default label model. 198kbyte imo is way too much, that part of the page should be 0 kbyte.”

    Or you could just use a ListModel with where you override the load method. You might want to remember the criterias for the selection, for instance from date and to date. So 16 bytes total. If you get a session size of 198kbyte, you are not using models as they are supposed to be used.

    I have just been developing a webapp and the session size never gets over 3kbyte. Lots of lists, Ajax, click to edit single fields, and so on. Should be able to server around 350k users per gigabyte of ram. It could probably have been optimized better, but it’s not worth the time. If it was a public webapp, I might have bothered to optimize.

Leave a Reply

Your email address will not be published. Required fields are marked *