You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by fzb <na...@bzforce.com> on 2016/10/14 04:33:13 UTC
Wicket vs JS frameworks.
Hi,
I am a fan of Wicket & had been working on for last 6 to 7 yrs using the
same. Recently had evaluated few frameworks Angular, ReactJS etc in view of
developing new applications, I did not feel them appealing may be due to my
very bad java script knowledge.. if at all i learn and start working on it,
I felt I am not going to be productive on it. Currently I feel Wicket due to
its Component based is very much productive and helps to give the
consistency across application in terms of look n feel etc.
Just thought of hearing comments from others as well .. Are those using
Wicket, using other frameworks as well. Are there any combinations which
works well with Wicket or otherwise.
- fzb
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-vs-JS-frameworks-tp4675771.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket vs JS frameworks.
Posted by Martin Grigorov <mg...@apache.org>.
On Sat, Oct 15, 2016 at 3:44 AM, fzb <na...@bzforce.com> wrote:
> Thanks Martin for the reply. Understood the points conveyed.
>
>
> Martin Grigorov-4 wrote
> > It scales with the knowledge of the engineers.
> > It is not just Wicket when you need big scale application.
> > It goes from the OS configuration, to the selection of the databases, the
> > web server config and good application code.
>
> Is there any place or topic, where we consolidate all best practices &
> learnings ?
>
There are some best practices in the user guide.
I have some more in my training materials.
But anything that is applicable for other web frameworks is applicable for
Wicket too.
If you have specific questions how to do something then ask here.
>
>
> Martin Grigorov-4 wrote
> > I personally try to use only technologies that *I* like, not because the
> > marketing team of some company said that their product is the best.
>
> Yes, agreed. But not just marketing team of that company, the industry
> trend
> is more towards those JS frameworks like Angular, React etc.. So wanted to
>
Since you mentioned Angular.
Angular 1 is not very scalable.
Any performance test will show you that after some size the logic it uses
for diirty checking becomes its bottleneck.
So for me Angular became popular because of its easier testability, not
because of its performance.
Angular 2 has almost notihng in common with Angular 1. This should tell you
a lot!
There are much more performant JS frameworks than Angular and React but
since they were not created by big players (like Google and Facebook) they
didn't got the same attention from the industry. I.e. your manager will
more easily approve you to switch from Wicket to Angular 1 (despite its
known problems) because it comes from Google than to switch to Ractive.js
that is developed by just few people, no matter it is has much better
performance than Angular.
> know where do Wicket stand against those.. We wil be in a better position
> to answer questions down the line.. As an Architect when you make
> decisions,
>
I see no concrete questions so far in this thread.
Asking someone to compare you X vs Y vs Z in general is way too broad.
> you need to stand by those and prove it.. This topic was intended to
> clarify & get more insights to be able to make decision.
>
> - fzb
>
>
>
>
>
>
>
>
> --
> View this message in context: http://apache-wicket.1842946.
> n4.nabble.com/Wicket-vs-JS-frameworks-tp4675771p4675798.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Wicket vs JS frameworks.
Posted by fzb <na...@bzforce.com>.
Thanks Martin for the reply. Understood the points conveyed.
Martin Grigorov-4 wrote
> It scales with the knowledge of the engineers.
> It is not just Wicket when you need big scale application.
> It goes from the OS configuration, to the selection of the databases, the
> web server config and good application code.
Is there any place or topic, where we consolidate all best practices &
learnings ?
Martin Grigorov-4 wrote
> I personally try to use only technologies that *I* like, not because the
> marketing team of some company said that their product is the best.
Yes, agreed. But not just marketing team of that company, the industry trend
is more towards those JS frameworks like Angular, React etc.. So wanted to
know where do Wicket stand against those.. We wil be in a better position
to answer questions down the line.. As an Architect when you make decisions,
you need to stand by those and prove it.. This topic was intended to
clarify & get more insights to be able to make decision.
- fzb
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-vs-JS-frameworks-tp4675771p4675798.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket vs JS frameworks.
Posted by Martin Grigorov <mg...@apache.org>.
On Oct 15, 2016 3:05 AM, "fzb" <na...@bzforce.com> 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..
One of my former client runs the biggest mail provider in Europe.
There the application was serving 200 000 users at normal load and 500 000
at peak times.
It is not like Facebook but also it is not the average web application.
>
> 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 ?)
See above.
It scales with the knowledge of the engineers.
It is not just Wicket when you need big scale application.
It goes from the OS configuration, to the selection of the databases, the
web server config and good application code.
>
> 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.
First you need to answer yourself what kind of application you need. What
is its target audience. What developers you have. Wicket is just a tool in
the box.
If you want to be developer above the average then experiment with new
technologies. Only this way you will have an opinion. I can tell you
anything good or bad about any technology (they all have their
shortcomings) but this should not be a reason to use it or drop it from the
options.
I personally try to use only technologies that *I* like, not because the
marketing team of some company said that their product is the best.
Good luck!
>
> - fzb
>
>
>
> --
> View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Wicket-vs-JS-frameworks-tp4675771p4675796.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
Re: Wicket vs JS frameworks.
Posted by Sebastien <se...@gmail.com>.
Hi,
> 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/)
>
>
Wicket Kendo UI too (Material & Material Black)...
http://demos.telerik.com/kendo-ui/themebuilder/
Re: Wicket vs JS frameworks.
Posted by Martin Grigorov <mg...@apache.org>.
On Sat, Oct 15, 2016 at 6:55 PM, Marcel Barbosa Pinto <
marcel.power@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...@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-unsubscribe@wicket.apache.org
> >> For additional commands, e-mail: users-help@wicket.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
Re: Wicket vs JS frameworks.
Posted by Marcel Barbosa Pinto <ma...@gmail.com>.
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...@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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: Wicket vs JS frameworks.
Posted by Andrea Del Bene <an...@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
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.n4.nabble.com/Wicket-vs-JS-frameworks-tp4675771p4675796.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket vs JS frameworks.
Posted by fzb <na...@bzforce.com>.
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.n4.nabble.com/Wicket-vs-JS-frameworks-tp4675771p4675796.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket vs JS frameworks.
Posted by Andrea Del Bene <an...@gmail.com>.
The "new" JS Frameworks in combination with JSON have made quite cheap
building CRUD web app. But there are a number of factors that I
personally don't like at all with this type of solutions:
- they only work with single-page applications. period. SPA is not a
silver-bullet, it's not the best solution for everything.
- the same can be stated for JSON. I might need to use another data
format and maybe I might prefer a relational db instead of Mongo...
- hard to test your app in isolation. With wicket you can test your
generated HTML without even using a server.
- standard "bending": you have to use something that is not pure HTML
(custom tags, JSX, ...) and then COMPILE it to something standard (most
of the time JS) :-(
- ...
My 3 cents.
On 14/10/2016 06:33, fzb wrote:
> Hi,
>
> I am a fan of Wicket & had been working on for last 6 to 7 yrs using the
> same. Recently had evaluated few frameworks Angular, ReactJS etc in view of
> developing new applications, I did not feel them appealing may be due to my
> very bad java script knowledge.. if at all i learn and start working on it,
> I felt I am not going to be productive on it. Currently I feel Wicket due to
> its Component based is very much productive and helps to give the
> consistency across application in terms of look n feel etc.
>
> Just thought of hearing comments from others as well .. Are those using
> Wicket, using other frameworks as well. Are there any combinations which
> works well with Wicket or otherwise.
>
> - fzb
>
> --
> View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-vs-JS-frameworks-tp4675771.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket vs JS frameworks.
Posted by fzb <na...@bzforce.com>.
Tobias Soloschenko wrote
> I think because Wicket uses HTML5 and Java you can combine JS Frameworks
> with many of the features of Wicket. Example: Because you have a java
> backend you can build a rest API with wicket-rest-annotations and
> configure your Angular JS to work with it - if you have a page change you
> could use Wicket components and even the pages could be served with Wicket
> containing the Angular content.
Yes, we can embed some components from React or Angular if this works. But
again maintaining compatibility over release cycles is an issue.. If there
was some built in mechanism in wicket, it would be ideal.
Is any one attending this conf ? ApacheCon Europe 2016
https://apacheconeu2016.sched.org/event/8UL4?iframe=no
May be he might touch up on these topics ? If any one attend, please post ..
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-vs-JS-frameworks-tp4675771p4675785.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket vs JS frameworks.
Posted by Tobias Soloschenko <to...@googlemail.com>.
Hi,
this is a topic every web developer is facing currently.
I think because Wicket uses HTML5 and Java you can combine JS Frameworks with many of the features of Wicket. Example: Because you have a java backend you can build a rest API with wicket-rest-annotations and configure your Angular JS to work with it - if you have a page change you could use Wicket components and even the pages could be served with Wicket containing the Angular content.
There are some things I want to point out:
Java Frameworks:
* Compiling / JUnit tests (with WicketTester) let you know if you break something - in my opinion this is currently working better as JavaScript-Testing with no compilation
* You have a better IDE support for the Java Part than for JavaScript - all the time I spoke to JS developer they all the time give me a complete different tool setup they use which at least do not cover the whole stuff needed to ensure alle facets if you refactor something (this gets better with TypeScript which also Angular decided to use)
* NPM itself does not guarantee that the versions you are using of a released module are the same all the time - you have to use additional plugins like Shrinkwrap to do so - this is way better in maven!
* You don't have to build up the interaction client<>server yourself (Wicket and others) this is done by the framework for you - with Angular you have to handle every REST call yourself
JavaScript Frameworks:
* You don't need a VM to run it just a simple browser and the library
* A big community of developers, because every frontend developer used JavaScript before can build up the presentations layer.
* Less overhead on server side (memory consumption)
As you can see there are advantages and disadvantages on both sides, but as I mentioned - if you want to you can combine them, but you have to evaluate which fits the best to your requirement.
kind regards
Tobias
> Am 14.10.2016 um 06:33 schrieb fzb <na...@bzforce.com>:
>
> Hi,
>
> I am a fan of Wicket & had been working on for last 6 to 7 yrs using the
> same. Recently had evaluated few frameworks Angular, ReactJS etc in view of
> developing new applications, I did not feel them appealing may be due to my
> very bad java script knowledge.. if at all i learn and start working on it,
> I felt I am not going to be productive on it. Currently I feel Wicket due to
> its Component based is very much productive and helps to give the
> consistency across application in terms of look n feel etc.
>
> Just thought of hearing comments from others as well .. Are those using
> Wicket, using other frameworks as well. Are there any combinations which
> works well with Wicket or otherwise.
>
> - fzb
>
> --
> View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-vs-JS-frameworks-tp4675771.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket vs JS frameworks.
Posted by fzb <na...@bzforce.com>.
Ernesto Reinaldo Barreiro-4 wrote
> 2- In some places, companies I have worked for as consultant, I have seen
> projects that they considered complex because the JS paraphernalia. They
> were be just trivial using Wicket. The sad thing is they did not have any
> need to scale. So, something like wicket was more than a perfect fit.
Very much true. I am working on a system, where it is a mid or small (100 to
250 users) scaling requirement... I felt wicket is more than sufficient for
this. But I do have some issues, i will post a separate topic on the issues
to get clarified. This is more general topic.
Ernesto Reinaldo Barreiro-4 wrote
> They all used REST and some JS machinery (they also did not plan for
> mobile so
> REST was not needed). Some of these applications were not very DRY... and
> REST layer was kind of a mess where you never knew for sure what was
> actually used and not.
REST should not be a criteria for going with JS based systems. We do have
mobile apps, we expose REST services using Spring. We dont need the same
data in web & mobile most of the time. For mobile it is very much limited.
So having a separate REST layer works well.
Lets wait n hear from some more experts on this topic. People who had done
lot of apps on JS side & Wicket side will be a good candidate, not being
Biased :)
--
View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-vs-JS-frameworks-tp4675771p4675783.html
Sent from the Users forum mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: Wicket vs JS frameworks.
Posted by Ernesto Reinaldo Barreiro <re...@gmail.com>.
Hi,
My opinion might be a little biased as I love Wicket... but
1- Except maybe for Web Components I haven't seen anything as reusable as
Wicket (http://webcomponents.org/) on JS world (disclaimer I'm not a big JS
expert, just maybe an advanced user)
2- In some places, companies I have worked for as consultant, I have seen
projects that they considered complex because the JS paraphernalia. They
were be just trivial using Wicket. The sad thing is they did not have any
need to scale. So, something like wicket was more than a perfect fit. They
all used REST and some JS machinery (they also did not plan for mobile so
REST was not needed). Some of these applications were not very DRY... and
REST layer was kind of a mess where you never knew for sure what was
actually used and not.
3- IMHO wicket adoption was hampered by big players support to JSF.
4- One big advantage of JS is how easy it is to find developers and how
large/active communities are.
On Fri, Oct 14, 2016 at 6:33 AM, fzb <na...@bzforce.com> wrote:
> Hi,
>
> I am a fan of Wicket & had been working on for last 6 to 7 yrs using the
> same. Recently had evaluated few frameworks Angular, ReactJS etc in view of
> developing new applications, I did not feel them appealing may be due to my
> very bad java script knowledge.. if at all i learn and start working on it,
> I felt I am not going to be productive on it. Currently I feel Wicket due
> to
> its Component based is very much productive and helps to give the
> consistency across application in terms of look n feel etc.
>
> Just thought of hearing comments from others as well .. Are those using
> Wicket, using other frameworks as well. Are there any combinations which
> works well with Wicket or otherwise.
>
> - fzb
>
> --
> View this message in context: http://apache-wicket.1842946.
> n4.nabble.com/Wicket-vs-JS-frameworks-tp4675771.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
--
Regards - Ernesto Reinaldo Barreiro