A Backend is a REST apiEvery backend should be seen as a REST api and every controller as another resource. You want to analyze your problem domain, find your resources and design proper paths for them. They become the M in your MVC Architecture. Developing a webapplication first, and adding an extra REST api later on has to be considered an antipattern. If you do make a REST api, you want to consequently use it yourself, making your frontend its first consumer. This procedure allows you to smoothly add different kinds of clients later on, such as a mobile app or even a desktop application. It's also the foundation to integrate your applications features into other applications.
Mobile Web & Responsive DesignMobile devices are becoming more powerful in terms of hardware whilst html5 support is also rapidly increasing on mobile browsers. Html5 could potentially make native mobile applications obsolete one day. Localstorage, SQL, Geolocation, Multimedia, Camera Access, Web Sockets, Graphics, Touch Events, WebGL, Filesystem Access, Notifications and many more are all features to be completely available to mobile html5 webapplications one day, hopefully working on all devices. So far, we have been developing multiple applications for android/ios/windows mobile and so on, being an economic nightmare.
Mobile clients have gained a substantial amount in web consumership, and cannot be ignored anymore. Therefor you want to make your GUI reponsive, beeing able to scale down to smaller display-resolutions. Wise companies have even started designing userinterfaces for the smallest resolution before even thinking of a desktop resolution. This makes scaling more easy, since the other way round is harder and tends to force painfull workarounds. Bootstrap is one of many libraries that help you make your gui responsive. You can use initializr to get started.
GWT or ZK Framework? Use Neither!GWT/ZK are trying do deliver a framework that makes it possible to develop modern ajax web applications using Java only. So they are basically building a java wrapper for frontend technology. Other than that, they deliver a huge amount of components. BUT ... i'd like to question their philosophy for many reasons.
- They Both produce quite bad html code making you end in an element and dom-id nightmare that gets hard or even impossible to test, debug and style. Html5 allows to write short, clean and readable code, organized way better. You want to write html yourself.
- Their AJAX calls are not based on the REST api that you need. If you want a REST api, you may have to write that again. RPC is GWT's primary communication-technology and i am really concerned about that. But you can still make a REST api work with GWT if you like to.
- They keep you away from the technology that you are actually producing. Tiny customizations can get hard or even impossible in the end. You are basically giving up control and limiting your possibilities. This might in many cases lead to dead ends, that are based on the framework, not the technology. GWT helps to overcome this problem offering JSNI.
- They are never up to date. While browsers are evolving rapidly, new features have to be implemented in the Java-Wrapper before you can even use them, delaying your up-to-dateness.
- I doubt that wrapping native front-end technology is a good idea, and i don't see a reason for doing it. One pro GWT argument might be: it's generating optimized JS code.
They defintively have their place right now and aren't a bad choice in some cases.
I'm not so sure about the last postulate... Isn't it all about context and tradeoffs? In the same way the bytecode produced by JVM may be "unclean" for ASM or even C gurus but... who cares? ;) Also being on the edge of technology is not necessarily critical I think. The product is the ultimate goal and if we don't aim to have extreme performance and super-awesome-customized look&feel, just plain functionality behaind standard widgets, I think frameworks like ZK or Vaadin have their place in webdev. Or am I wrong? :)ReplyDelete
Well, they definitely have their place right now. They aren't a bad choice in some cases. But i want to question their ideology. My experience on GWT is rather limited so i want to get deeper onto ZK.ReplyDelete
Question yourself. Does using ZK give you any advantage over using native frontend technology?
One might say:
- "I get a great debugging environment using Java".
- "I can deliver web and mobile web out of a single framework".
- "I can choose from a great amount of components".
- "It shields me from ajax complexity".
- "It gives me better productivity".
But non of those statements are an advantage.
- Native frontend technology can also be debugged.
- There are many frontend technologies that help you deliver mobile and web out of a single framework
- You can choose from way more components in the frontend world.
- And it doesn't even give you better productivity. thats nonsense. if you are used to your technology you are fast. if you have yet to learn it, you are slow.
So there is no real advantage other than beeing able to stick to your primary language.
But when i try to list the disadvantages, it gets outrageous:
- It does not follow REST architecture, thus forcing you to separately implement that.
- It's html output is garbage. It is table inside table inside table inside multiple divs and so on. The Ids are automatically generated, not interpretable. How do you debug that. How do you style that, how does your browser deal with that. Is it W3c Valid? Can you make it barrierfree? I don't think so. Html5 and CSS3 shine by their ability to make the source clean and short, you want to do that.
- Because of the id-nightmare, you cannot automatically test your gui using the defacto standard: selenium. you have to use their proprietary ZTL.
- Instead of learning HTML, you are forced to learn a proprietary view-language.
- It is limiting your possibilities. you can only do, what ZK allows you to do. Sometimes thats not enough.
do i really have to go on?
Thank for the ideas and advice, it can truly help me ;)ReplyDelete
your Genius! I hope you can post more about this, it really help thank you.ReplyDelete
Hey Greg! your a good one.. hope you continue your work, thanks for info like this it helps a lot.ReplyDelete
keep up the good work.