Gregor Riegler

About Gregor Riegler

Gregor is a passionate software engineer and RESTafarian who loves to continuously improve. He is interested in modern web development, oo-design and extreme programming. He is also serious about clean code and TDD.

Modern Web Development

In the last few years web technology has lived through rapid growth and heavy change. We went from frames to table layouts, to column layouts, to responsive layouts. From html4 to xhtml & flash to html5. From heavy server to rich client. From rpc to soap to rest. From sql to nosql and big data. From MVC to MVP and so on. In the following post i want to describe what has become state-of-the-art from my perspective.

A Backend is a REST api

Every 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.

Separate your Frontend

The days when you made up a form using jsp with a jstl form validation are fading. You don’t want to mix client with server technology anymore. The V and C of MVC has shifted over to the client and your backend just represents the Model. You want your frontend to be completely separated using client technology only (html/css/js) and consuming your REST api. GUI logic, building and aligning proper html elements can be achieved within javascript. The most appropriate content-type for information exchange between the backend and frontend would be json or even xml.

Rich Client & Hail JavaScript

The MVC pattern is nowadays implemented on the client side using javascript and it’s fellow frameworks. There is no full-blown complete javascript framework that can achieve everything out of the box, but there are tons of smaller libs solving atomic tasks. This should not be considered bad or overwhelming, but advantageous. It causes a great variety of tools that focus on solving single problems outright. Backbone is a popular mvc framework built upon underscore, a js library delivering great utility with remarkable functional programming features. A template engine like mustache or handlebars could be added and requirejs would manage the dependencies within your modules. Of course, a dom manipulator like jquery cannot be left out. The trend is leading towards SPA‘s (Single Page Applications) with heavy AJAJ/AJAX, routing through html #anchors representing bookmarkable view-states.

Implement a Buildprocess for your Frontend

As Browsers are continously increasing javascript performance and adding more and more support for html5, frontends have become complex and sophisticated. You now want to add a build process for your frontend, compiling all your js and css files. You want to deliver only a single minified js file to the browser. Other than that we don’t break the DRY principle writing styles anymore. We use dynamic stylesheet languages like less to make our styles smarter and cleaner and compile them to css in our build process. Node and rhino are possible engine candidates to build your frontend. While node is much faster, it requires an easy installation on the build server. Rhino runs in a jvm, thus not requiring an installation. You can add it to your project as a maven dependency.

Mobile Web & Responsive Design

Mobile 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-technologym 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.

In the end they make it easier to build webapplications for former java.awt/swing developers, who have no to little knowhow of html/css/js.
They defintively have their place right now and aren’t a bad choice in some cases.
 

Reference: Modern Web Development from our JCG partner Gregor Riegler at the Be a better Developer blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

21 Responses to "Modern Web Development"

  1. Gonzalo says:

    Excelent post!

  2. bettomcrose says:

    Excelent post! (2)

  3. Mike says:

    Fat-client + RESTful is a nice pattern. But calling GWT/ZK anti-pattern is too much. Actually the philosophy of GWT and ZK are quite different (so is REST). They have their own strong applications.

  4. Alex says:

    About Mobile Web Apps, you should read an article from Drew Crawford pointing out why they won’t replace native apps, at least for now: http://sealedabstract.com/rants/why-mobile-web-apps-are-slow/

  5. Marc says:

    Rich client + RESTful API is great. I am favoring it for years. However more often than wanted I have to put it down and use template based HTML generation because of heavy SEO requirements which demand for distinct pages.

  6. Jarda says:

    GWT:
    1: false
    2: false
    3: false
    4: you can always get into native JS if you need to

    • Gregor says:

      Hi,
      I’m the author of this post. Can you please go into more detail for the points that you have stated false?
      From my experience GWT creates a lot of unnecessary divs/table elements, and inline styles. I mean just go on the GWT showcase page. They are generating nested Tables for what is in fact a List. This is pretty terrible.
      For the second point: GWT-RPC is the default way, and RPC is not optimal. I stated in my post that there is a REST extension.
      On the third Point i know its true for ZK. But i might be wrong for GWT. Can you please explain why, and how GWT allows direct JavaScript access?

      Greetings, Gregor

      • rabbit says:

        1. Using GWT widgets is not mandatory. My code isn’t using any and the produced html is very clean. (Check http://gwtbootstrap.github.io/#base: for examples)

        2. All my GWT applications are using REST backend.

        3. That’s totally wrong.

        4. Partly right, but even if you do not have a wrapper for new features, you can still access them.

        GWT main interest is to avoid writing js which allow you to build complex applications.

        For JavaScript access there’s JSNI http://www.gwtproject.org/doc/latest/DevGuideCodingBasicsJSNI.html

        • Christian Kütbach says:

          Thanks for your comment.

          I am a GWT developer since some years and I completely disagree to the original post.

          1. There may be some widgets, which may have a large DOM. But you always can write slim widgets

          2. AutoBeans are cool, if you simply want to transform JSON into Objects
          https://code.google.com/p/google-web-toolkit/wiki/AutoBean

          3. What should I add here? I never got into serious problem using GWT.

          4. JSNI is really cool. But only use iit, if you really have to.

          Thanks for you clarification

          Christian

        • Christian says:

          Thank you for outlining that the GWT idea in it’s core is to abstract the writing of JS into a language that has a way better tooling environment than JS has right now.

          Widgets, DOM, JS native invokations, backend communication and so on is packaged with GWT, but you don’t have to use it. Write your own widgets, invoke your own JS code to adapt third party libraries, connect to your own backend using your own style of communication.

          But instead of doing this in native JS you can do it in your IDE with the whole power of it for refactoring/debugging and so on.

  7. Roger says:

    Really stupid post. Suggesting to use XML for client-server communication. Please (especially if you’re talking about mobile clients). And then all reasons stated against GWT/Zk are so wrong that they’re in reality the reasons you want to use them!

    • Gregor says:

      I suggested json primarily, of course. But since XML is practically possible, it’d be wrong to not mention it. Of course, as everyone knows XML is slower, thus not very optimal for mobile.

      About the second Part. If you really think this is why you want to use ZK/GWT: Go ahead and give some reasons for what you have argued. I’m very curious.

  8. Nick says:

    ▪ They produce the most garbage html code you can think of making you end in an element an 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.

    This sounds more like a review of GXT than GWT. GXT results in a complex DOM that you probably wouldn’t want to try styling by hand, but thats OK since you are relying on GXT to provide the style for you.
    If on the other hand you are using plain GWT, there’s no reason why your DOM structure should be complicated or difficult to style since GWT provides direct access to the DOM tree.
    If you prefer to write plain HTML, there’s no reason why you can’t do that within GWT too.

    ▪ 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. Well, there is at least this rest-gwt extension.

    It’s unfortunate that GWT provides an easy-to-use Java RPC mechanism that isn’t a pure JSON REST API… but that doesn’t stop you from leveraging your own pure REST API using RequestBuilder.
    The fact that it provides you with an alternative to REST out of the box is a benefit though, not a drawback. You can always choose not to use it.

    ▪ 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.

    I guess you didn’t play with GWT long enough to discover JavaScript Native Interface (JSNI)? That provides you with direct access to external JavaScript, so there’s nothing that you can do in JavaScript that can not be done from within GWT.

    ▪ 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.

    While pre-built component wrappers may not be available, again, there’s no reason why you can’t use JSNI to directly access any functionality that is not already wrapped. Also, have you heard of Elemental (http://www.gwtproject.org/articles/elemental.html) ? It’s part of the most recent GWT releases that provides you with direct access to the most recent HTML 5 features.

    Essentially, JSNI is the golden fall-back within GWT that, in the worst case scenario, allows you to code in JavaScript where necessary. In all other cases, you can (and should) stick to coding in Java to take advantage of superior tooling, code completion, easy refactoring, compiler optimized output (dead code removal, minification, inlining…), deferred binding for optimized per-browser/locale downloads, asynchronous code-splitting… the list goes on…

    So the question is not why SHOULD you use GWT… but why SHOULDN’T you use GWT :)

    • Gregor says:

      thank you for your constructive feedback. my gwt experience is limited so might in fact have leveraged zk weaknesses onto gwt too much. it seems that gwt really tries to overcome the problems that i stated. so i will have to edit my post.

      nevertheless im really concerned that
      – rpc is the primary gwt ajax way
      – generated code in the showcase and example apps is really bad. inline styles, and nested tables for a simple list are just too much.

      but the optimized javascript ouput is really a good thing

  9. Dan says:

    Good post regardind rest but no real understanding of GWT as pointed out by others.

  10. koma says:

    GWT :

    1) They produce the most garbage html code : NO, GWT produces optimized code. Or else, never use jquery.min.js only jquery.js.
    2) Their AJAX calls are not based on the REST api that you need : Why can’t a GWT client talk to a REST service ?? Have you ever even used GWT ?
    3) They keep you away from the technology that you are actually producing : Why don’t you write everything in assembler then, you will have more feeling with your underlying technology !
    4) They are never up to date : check Elemental in GWT, or JSNI.

    None of your claims on GWT makes sense, man … better check your subjects before making claims.

  11. Emilio says:

    First, ZK is a server-side framework, GWT is a client-side SDK (not framework).

    “They produce the most garbage html code you can think of making”
    Think as bytecode. javascript DOM handle is a nightmare. GWT solves this in an elegant way.
    Yo can layout with HTML + CSS with http://www.gwtproject.org/doc/latest/DevGuideUiBinder.html
    Native integration of twitter bootstrap https://github.com/gwtbootstrap/gwt-bootstrap , You can also directly use twitter bootstrap for layout.
    http://www.jboss.org/errai , pure HTML + CSS

    “Their AJAX calls are not based on the REST api that you need”
    http://www.gwtproject.org/doc/latest/DevGuideCodingBasicsOverlay.html
    https://code.google.com/p/google-web-toolkit/wiki/AutoBean
    http://restygwt.fusesource.org/

    “They keep you away from the technology that you are actually producing”
    http://www.gwtproject.org/doc/latest/DevGuideCodingBasicsJSNI.html
    this sentence reminded me times of assembler and C :-D.
    http://en.wikipedia.org/wiki/Abstraction_(computer_science)

    “They are never up to date”
    http://www.gwtproject.org/articles/elemental.html -> up to date HTML5 integration based on WebIDL especification.
    Same reasoning can be applied to browsers.

    For more info http://www.gwtproject.org/

Leave a Reply


one + = 4



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close