days
-4
-4
hours
0
-8
minutes
-3
-6
seconds
-1
-6
search
JAX Developers Puzzle deadline approaching: Play for a chance to win a complimentary JAX London 2018 ticket!

10 tips for Java developers exploring JavaScript in the enterprise

Geertjan Wielenga

In the brave new JavaScript world, here are 10 tips to help Java developers, in particular if your work is focused on “the enterprise”, i.e., large applications that need to be scalable and maintainable over time.

Over the past few years, much needed scrutiny has been brought to bear on how JavaScript can most optimally be used in the enterprise. That scrutiny has been particularly intense in the light of a set of recent developments that can be distilled down to three specific factors.

  • Multiple Devices & Responsive Design. The explosion of mobile devices and tablets means that terms such as “screen size” and “resolution” are hot topics. No longer can you assume that your users will have the same, or even similar, experiences when working with applications you create. You need to think about the devices your applications will target and investigate technologies that somehow deal with those different experiences, either hiding or loading content as appropriate for the devices you’re targeting.
  • The Browser Is Everywhere. Where Java developers with the “write once, run anywhere” mantra assumed that, in time, the Java virtual machine would dominate across all devices, it now appears, very clearly, that—at least for frontend development—the browser is simply everywhere, on all the devices that are new and shiny, i.e., tablets and phones, as well as on all the traditional devices, i.e., PCs and laptops. That does not mean, of course, that Java has no role to play in business logic and backend code but, for a large subset of applications, the popularity of the browser means that it is the ideal target for creating user interfaces for interacting with data, wherever that data may be.
  • Single Page Applications (SPA). A SPA is a web application or website that fits on a single web page, aiming to provide a more coherent and fluid experience for users, comparable to that provided by the desktop. Increasingly, development for the kinds of use cases outlined above are going back to the client, i.e., as much is done locally on the device as possible, as opposed to the server-based approach that most Java developers have been used to over many years.

The recent-ish developments above, i.e., recent in the sense that they have been taking place with increasing speed over the past 5 years or so, are certainly interconnected with each other. With a limited screen size on small devices, which continue to be increasingly popular to such an extent that the explosion of their popularity can be seen to be continuous, it makes sense to focus on SPAs, which require much less space than the earlier web designs that focused on multiple pages, lots of clicking and navigation from page to page, and which required more network bandwidth. Faster navigation is a requirement when you need to assume that your user is more than likely to be dealing with the battery life of the device that they’re using to access your application. The best navigation experience is zero navigation, i.e., the best solution is to provide the entire application withing a single page.

In this brave new world, sketched out above, here are 10 tips or insights to help Java developers entering the JavaScript ecosystem, in particular if their work is focused on “the enterprise”, i.e., large applications that need to be scalable and maintainable over time.

  1. gw-java-in-js-ent-1One Size Does Not Fit All. Though there is now a very large subset of applications that are becoming smaller and more focused, be careful to—as always—think about your business requirements before choosing the technologies you’ll use to satisfy them. Don’t assume you need to throw away everything you’ve got and rebuild everything in the browser. There continues to be a need for the desktop and Java continues to be a solution in that space. Not everyone accesses and works with their data via a mobile device. Large applications for industries such as air traffic control continue to exist and it would be insane to create a mobile application for monitoring and managing planes landing and taking off from airports. Your users need a large resolution to do that, if they want to do that safely. In short, don’t assume that the new and shiny tools and technologies are applicable to each and every scenario. Take a look at what your users are actually doing and what they actually need. Don’t force the browser on your users if their usage won’t benefit from it.

    If you’re true to Agile principles, you’ll find out from your users what they actually need, as opposed to what your management wants, or what you’re assuming your users think they want. Remember that though there is now a new set of technologies available and new techniques and so on, these are not so much replacing those that already exist—instead, they’re supplementing them, adding new mechanisms and solutions for different types of users to interact with data. For example, rather than assuming you should be rewriting an air traffic control system, you should instead consider whether the existing system can be supplemented by a mobile app that sends warnings and other notifications as needed, since the screen size of these kinds of enterprise applications will always remain important.

  2. gw-java-in-js-ent-2Think About Framework vs. Library. Angular appears to be so popular right now that it is moving towards being a de-facto JavaScript standard. In particular, most Java developers one comes across who are experimenting with JavaScript start out with Angular, since that’s where all the buzz is, still, after several years of JavaScript frameworks becoming increasingly popular. Where there continues to be a significant amount of work done with Backbone, Knockout, Ember, and the like, Angular clearly dominates and doesn’t seem to be dissipating at all.

    Part of the reason for this is that Angular is a framework, not a library. It provides a set of related technologies, in particular in the testing space (e.g., Protractor), outside of the framework itself, i.e., an ecosystem of technologies, created by the same set of developers and community, and there’s a continual drive for the framework to expand with more and better related frameworks that are compatible with it. A downside is that users of Angular are more or less locked into the Angular way of working and if that ecosystem falls over for whatever reason they’re pretty much stuck. An alternative route is to be very specific about technology requirements, e.g., do you like the MVC pattern? Then choose Backbone. Do you want to narrowly focus on two-way databinding and nothing else? Then choose Knockout. Do you want to focus a lot on UI components? Then choose Ember or React. This library-focused approach spreads your bets, though does mean that you need to put the pieces of the puzzle together yourself, instead of letting Angular do it for you.

  3. gw-java-in-js-ent-3Evaluate Enterprise Frameworks. A sure sign of the growing maturity of the JavaScript ecosystem is that the big companies and corporations want a piece of it. For example, take a look at DoubleClick by Google, the Salesforce1 Platform by SalesForce, SpectINGular by ING, and MobileFirst Platform by IBM.

    In each case, a set of existing frameworks is taken as a starting point and business-specific components are added. ING made waves a year or two ago at Devoxx and other conferences, where they showed how a range of public ING sites, i.e., for personal banking and so on, are now being developed in JavaScript, together with HTML and CSS, and related technologies. Best practices and full blown GUI components, expressed in JavaScript, are made publicly available by these organizations, in an attempt to create communities around the subset of technologies that constitute their internal business solutions. Open source plays a role here too, with all or parts of these solutions being available on GitHub.

    Watch large corporations and see what they’re doing with JavaScript. At least corporate solutions using JavaScript have a lifespan that is longer than their underlying component parts. Seeing where the corporations are going and tailoring your choices to match them might be a path to take for smaller organizations entering the JavaScript landscape.

  4. gw-java-in-js-ent-4Include Modularity. Whenever a new language on the JVM is announced, the key feature that is trumpeted is its built-in modularity (“unlike Java itself, of course”). Being able to organize code into meaningful structures is something that a large subset of developers clearly finds interesting and, even, important. For years, OSGi has been the de-facto standard in this space for Java developers. The only alternative has been for those creating applications on the NetBeans Platform, where the NetBeans module system, very similar to OSGi, is normally used.

    Of course, not only does JavaScript not have a built-in module system, it doesn’t even have a package system. For the scenarios where JavaScript is becoming dominant, that may be fine. However, if you’re creating some kind of enterprise application, i.e., large scale, with concerns about maintainability and the like, it is good to know that JavaScript does, indeed, have module systems at its disposal. Clearly dominant at this stage appears to be RequireJS, though Browserify is also in this space. Investigate both and see which fits your purposes.

  5. gw-java-in-js-ent-5Examine Responsive CSS vs. Responsive JavaScript. CSS3 is all about media queries. While the CSS2 specification provides the capability to use CSS rules dynamically based on media types, the CSS3 specification goes further and introduces media queries. A media query constitutes a media type and a set of expressions, which check for specific conditions of media features. For example, media queries can check the current size of the display screen. Media queries can then be used to show or hide content based on the defined conditions, such as screen size.

    However, something interesting can be noticed when you use tools such as the Chrome Connector plugin in NetBeans IDE. With these kinds of tools, you notice that when you have a media query that applies to, for example, as shown below, the width of the screen being less than 480, the related content, such as a logo or other image, is still loaded.

    @media (min-width: 481px) {
        .logo:before { 
              content:url("images/coca_cola_logo.png"); 
              display: block; 
              text-align:center;
        }
    }
    @media (max-width: 480px) {
        .logo:before { 
              display: none;
        }  
    }

    The DOM contains the elements and attributes, even though the media query hides it. Imagine that you could dynamically swap content based on breakpoints and data attributes defined in your JavaScript—which is what Response.js and Foundation Interchange are all about. Both provide a responsive JavaScript solution, avoiding the situation where JavaScript libraries and other artifacts would be loaded even though they’d never be used, such as enabling a Google Maps viewer to be swapped out of the application, instead of simply being hidden from the HTML view, whenever you decide to exclude it, ultimately saving resources, such as battery life, download time, and the like.

    Let’s briefly take a look at one of these solutions. Foundation is a UI framework, comparable to Twitter Bootstrap and Angular UI. In the 5.0 release of Foundation, Interchange was made available. Interchange is responsive JavaScript, allowing you to do powerful stuff on the client side, within the HTML view of your application. Predefined resolution markers are available, i.e., “small”, “medium”, and “large”, each of which you can map to an HTML file, as shown below.

    <div data-interchange="
         [fragments/small.html, (small)], 
         [fragments/medium.html, (medium)], 
         [fragments/large.html, (large)]">
    </div>

    Thanks to the above code, automatically, when the screen size changes, Foundation Interchange loads or unloads (instead of showing/hiding) the appropriate fragment.

  6. gw-java-in-js-ent-6HTML is Now an Application Framework. You may not have noticed it—HTML is now an application framework, i.e., it provides full-blown component-oriented solutions. In the HTML5 specification, the decision has been made to ensure that all new features are based on HTML, CSS, and JavaScript, following the new Shadow DOM specification, and that the need for external plugins, such as Flash, should be reduced. Moreover, high-level features, such as error handling and device independence are two other indicators that something big has been going here.

    For example, did you know that you can create a code completion box, i.e., “intellisense” functionality in HTML?

    gw-java-in-js-ent-11

    Here’s all the HTML for the above, with Knockout used to load data from JavaScript. Take note of the “list” attribute in the input element, which connects the input element to the datalist element below it. Both the “list” attribute and the “datalist” element are new in HTML5.

    <input id="countryInput" 
           type="text" 
           data-bind="value: selectedCountry" 
           list="countryList" />
    
    <datalist id="countryList" data-bind="foreach: countries">
        <option data-bind="value: country"></option>
    </datalist>

    Far from being a simple markup language, the basis of a fullblown multimedia experience is now available via HTML, with a specific applicability to applications, animations, games, and movies. New HTML media types have been introduced, such as “audio” and “video”, as well as new semantic markup, such as “article” and “header”, together with new validation attributes (e.g., “required” and “pattern”) and input types (e.g., “email”, “url”, “color”). These new standards are implemented, or planned to be implemented, by all browsers. Be aware of these new capabilities and begin to see HTML in a new way, as an application framework, if you haven’t caught on to these new enhancements already.

  7. gw-java-in-js-ent-7JavaScript is the Assembly Language of the Web. Just because JavaScript is the language of the browser does not mean it is the language that you must code in. If JavaScript, as a language for programming, is not for you, explore the transpilers that are available, as well as related solutions. For example, take a look at CoffeeScript, TypeScript, Vaadin, and DukeScript, which are just a few of the many technologies out there that provide one solution or another to simplify and firm up coding work in JavaScript (i.e., CoffeeScript and TypeScript) or that let you work completely in Java (i.e., Vaadin and DukeScript, compare their ‘hello world’ scenarios here) while letting the framework, in one way or another, create the code needed for running the application in the browser.

  8. gw-java-in-js-ent-8Find Abstractions. Unless you’re happy coding directly in JavaScript, HTML, and CSS, try to find abstractions on top of these low level technologies. I.e., find tools, such as Emmet for HTML, SASS and LESS for CSS, and CoffeeScript (and other technologies mentioned above) for JavaScript.

    Especially for Java developers, we who have been spoiled by having one single language (not even XML anymore, since we’ve been given Java annotations to work with), it helps to have tools and technologies that hide the fact that multiple languages need to be used, with the related context switching and productivity loss as a result.

  9. gw-java-in-js-ent-9“Write Once, Never Touch Again”. Often, the applications written in this space do not need to be maintainable. Or, maintainability means something different to what we knew in the past. The business case is often extremely narrow—”write an app to sell my product”—”let the user reserve a room in a hotel”. The team of developers—about 2 or 3 in total—works on the app, delivers it, and then moves on to the next app. When there’s a new feature request, 6 months later or so, a new app is put together from scratch, with the new version of all the technologies originally used or their replacements.

    OK, so this is not the enterprise, is it? Or is it the new enterprise? It’s not the enterprise as we know it with long development cycles, though it fits in very closely with the ideas of agile development. The technologies and frameworks in the JavaScript ecosystem are ideal for these kinds of apps, a far remove from the large scale complex and scientific apps that Java developers may be familiar with. Domain knowledge is a thin layer that everyone knows, e.g., everyone knows the basic parameters of a hotel booking system. Time to market is rapid and the lifecycle of the app matches that cycle.

  10. gw-java-in-js-ent-10Volatility of Ecosystem is OK. A typical “feature” of the JavaScript landscape is that just as you’ve learned a new technology it will (a) be supplanted by one of its competitors, (b) turn out to be irreparably awful after all, (c) not work with one of the other technologies you’re using, (d) die, (e) a combination of the above. If this kind of volatility is a problem for your scenario, don’t touch the JavaScript landscape. Stay with the technologies you know and the solutions that have stood the test of time.

    But ask yourself whether the volatility of the JavaScript ecosystem is truly a problem for you. Is it only a problem because you’re not used to it? Again, most applications created in this domain have a shelf life of about a year or two, which matches the shelf life of most frameworks and other technologies in the JavaScript landscape. Few Angular users cared all that much that Angular 2.0 wasn’t, originally anyway, backward compatible, since many of them were going to be rewriting their apps anyway by the time that Angular 2.0 will be released. On the other hand, if you’re creating an app that should be pretty much the same 10 years from now, or you don’t have the time and resources to continually tinker and update your system whenever new tools and technologies are released, possibly the JavaScript ecosystem might not be the best fit for your needs.

As can be seen from the above list of factors to consider, the JavaScript ecosystem is not for everyone. Moreover, the JavaScript ecosystem might be slightly different to what you’ve assumed it to be. It’s a weird and wacky place, cowboy land, really. It’s an interesting place and an innovative place. Innovation and change is something we, as Java developers, have not had all that much of, which is fine for stability, though less fine if you’re ready for something new. Saddle up and ride into it, Java developers everywhere. But,  be warned, there’s a cactus or two and more bears and wolves than you might initially have thought!

Ten image via Shutterstock

Author

Geertjan Wielenga

Geertjan is product manager of NetBeans IDE and lives in Amsterdam, the Netherlands. He blogs at blogs.oracle.com/geertjan.