On Sat, Oct 15, 2016 at 6:55 PM, Marcel Barbosa Pinto < marcel.po...@gmail.com> wrote:
> 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 > Crazy indeed! (first)=... [second]=... [(third)]=... #fourth=... 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, > www.material-ui.com > there is also Angular 1 > material.angularjs.org > and Angular 2 > material.angular.io Wicket Bootstrap library provides a MD theme ( https://fezvrasta.github.io/bootstrap-material-design/) > > > 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 ( http://www.techempower.com/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> > 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 > > > > >
