On Sat, Oct 15, 2016 at 6:55 PM, Marcel Barbosa Pinto <
> I am working on a complex and demanding Angular 2 project for marketing
> analytics, and I can tell that with Typescript the development process is
> exponentially improved.
> First we need to understand that the Angular project came from the GWT
> project. The Google devs realized at that time that they could speed up the
> was not something that they could do in the past because the web platform
> was not evolved to support complex frontend applications. Now they can
> leverage all the js tools, like npm and typescript, web components, etc. So
> Google put a lot of workforce in Angular. Now they are dropping GWT
> applications like Google analytics in favor of Angular.
> The next thing they are planning is Angular Universal, they already have
> versions for PHP and .Net Core and a version for Java will be available
> Angular server side will enable the pre rendering of pages in the server
> and the client router will communicate with the server side router enabling
> a faster startup time.
> I am using wicket by 4 years now. Indeed components based apps are a good
> choice to go. Maybe Wicket should evolve with the web components
> specification. In wicket the view (html) is logic less. But this is the
> wicket approach. With Angular you put all the view logic in html using the
> crazy Angular attributes and components tags. This can be messy but it
are there more ? :-)
#fourth is something like Wicket 7.x queued components.
All of those work with reflection but this is not a problem in JS world. JS
developers don't care much about such small details.
> greatly speeds up things, as you also don't have to follow an hierarchy
> which is required by Wicket. And I know this is a Wicket solution for the
> view, and can enabled better testing of components.
> I believe that the browser it self became a real platform for applications.
> Would be nice to have a material design implemented also in Wicket, like
> the React version,
> there is also Angular 1
> and Angular 2
Wicket Bootstrap library provides a MD theme (
> And some investigation in the reactive streams program model. I think this
> can be applied to many aspects of component hierarchy and models. In
> Angular 2 supports rxjs for form validation and many other things.
> Wicket is a very good framework letting you choose between stateless or
> statefull or both! You can't use just Angular, you also need a server
> counterpart and for this wicket is a good choice because it is simple and
> intuitive to maintain, but if you need performance that the servlet can't
> deliver. You need to go for Netty/Akka based frameworks.
For some reason Akka based web frameworks (e.g. Akka HTTP, Play) do not
show good results at TechEmpower benchmarks (
Wicket is also not top-performer but it never claimed to be.
> Em 15 de out de 2016 07:42, "Andrea Del Bene" <an.delb...@gmail.com>
> > 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
> > 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
> >> 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
> >> 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
> >> depending on the scenarios in hand.
> >> - fzb
> >> --
> >> View this message in context: http://apache-wicket.1842946.n
> >> 4.nabble.com/Wicket-vs-JS-frameworks-tp4675771p4675796.html
> >> Sent from the Users forum mailing list archive at Nabble.com.
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> >> For additional commands, e-mail: users-h...@wicket.apache.org
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> > For additional commands, e-mail: users-h...@wicket.apache.org