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 development process by skipping the Java compilation to Javascript. This 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 soon. 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 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, www.material-ui.com there is also Angular 1 material.angularjs.org and Angular 2 material.angular.io 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. Em 15 de out de 2016 07:42, "Andrea Del Bene" <an.delb...@gmail.com> escreveu: > 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: 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 > >
