IMHO things are quite simple. JS base app are told to be highly scalable because they rely on a REST, stateless architecture. So scaling is just a matter of adding servers without worrying of replicating a user session. This is true until you need to log a user into your app. At this point someone, somewhere (usually in a oauth server) has to "remember" your logged in users somehow, which means that you are no more stateless :-). When Wicket was born people didn't use to care about been stateless at any cost, and unfortunately for many years Wicket was labeled as stateful framework. This is absolutely wrong as "by default" a Wicket app is stateless. The user guide explain in details such concept. With the last release we also made an additional effort to keep AJAX features stateless-friendly.

The bottom line: no matter which framework you use. if you want to be scalable be stateless. If you can't, keep user session the smallest you can. :-)

On 15/10/2016 02:57, fzb wrote:
 From the posts so far this is what i understand..

1. JS based apps are best suited for high scale applications.. It is worth
the effort you take to build and maintain such apps..

2. Wicket can scale only to certain extent based on the server capacity ? If
so how to quantify ?
(What about load balancing ? What about stateless pages ? Why it does not
scale ?)

3. JS based apps resource availability is plenty.. So for new projects
better to go with these ?
  - What if the maintaining these apps becomes tedious due the cons of these
JS discussed earlier.

May be some more insights will help us all understand, how to choose what
depending on the scenarios in hand.

- fzb

View this message in context:
Sent from the Users forum mailing list archive at

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

Reply via email to