The Rise of Front-End Technology
Due to this phenomenon, user expectations have significantly grown. We no longer evaluate a web application based on its practicality alone, but we also consider its appearance, responsiveness, animations, and overall experience. As a result, web developers are now starting to rely on front-end technologies more than ever before.
Unfortunately, most technologies fulfill only half of the requirement, meaning they are designed specifically for one side; either the client-side like AngularJS or Bootstrap for delivering a fancy look & feel, or the server-side like the JSF, which focuses primarily on data integration. Either way, you would have to deal with one side completely on your own, as well as the communication between the two sides by yourself. Consequently, in the attempt to minimize losses, developers face a difficult decision in choosing which side.
Combine Existing Rich Front-End Technology with Server-Side
ZK 8 is created to present developers with an ideal solution: combine the strengths of both sides. It aims to leverage the advancing client-side power with client-side command binding and template injection while still allowing you to enjoy the equally important server-side integration and security. In short, with ZK 8 you can stay true to your Java roots, but also effortlessly keep up with the ever-evolving world of front-end technologies.
Template injection is done by the introduction of shadow components – a pure server-side reusing mechanism. The shadow components can easily turn HTML pages created by a web designer into a dynamic web page with data binding. Using shadow components is similar to using standard ZK UI components through MVVM approach. By manipulating the shadow components, developers can inject different HTML templates based on the given condition.
It is heartening to see more client side support in ZKOSS.
I think going forward support for web components will be crucial
Today each front end library builds its own set of components.
If these components are built using WebComponent standard then these components can potentially become reusable across frameworks.
Imagine what a windfall will that be for web developers.
ZKOSS should position itself to help web developers take advantage of that.
Hi Satguru, thank you for your suggestion. We are definitely on the same page here.
It will be great if you can provide an example which show how to integrate JS libraries/components that need large volume of data from the back end.
Good example will be updating data series in D3 component, or sending additional drawing instructions to existing HTML5 canvas, in response to use actions.
Thank you…very useful.
Hi ZK guys,
correct indeed – I have been told many times:
“Still ZK?! Server side?! too heavy… we are going client side, man!”.
So I am eager to know more how to reply consistently!
To Yair: thank you! We appreciate your feedback.
To Robin: I’m glad you had a good read!
To Stefano: It’d be great if you can let them know that ZK 8 is the ideal solution, as it combines the strengths of both client-side and server-side. No choosing necessary. Have the best of both worlds!
Are there any future plans to base/convert zkoss components on/into web components?
What about a true Osgi version of ZK?
[…] dengan tetap mengutamakan kenikmatan server-side integration dan security. ZK 8.0 memiliki filosofi baru, yaitu “With ZK 8 you can stay true to your Java root, but also effortlessly keep up with the […]
I wonder if this answers what Vicente asked above. The iDempiere ERP project (a fork of Compiere/ADempiere) is on the OSGi framework and uses ZK7 and last month been upgraded to ZK8 in its experimental branch. You may take a look at its source at https://bitbucket.org/idempiere/idempiere/
We agree with this article concerning complexity issues of which ERP apps such as ours faces tremendously.
We coded our ZK in pure Java and avoid scripting for typesafe visibility and as the ZK8 front page says, leverage on Java roots for a shorten learning curve.
Kudos to ZK team from the community of iDempiere!