4 Reasons To Ditch Apache Struts and Embrace JavaScript

Guest Author
Nov. 08 2013, 08:00AM EST

This guest post comes from Dev Anand. Dev is the Director of Product Management for the Datacenter and Network Management Division at ManageEngine that develops IT Management software for Datacenter Visualization, Datacenter Infrastructure Management, Network and Application Performance, Change Management, Network Traffic Analysis and Virtualization Monitoring. You can follow him @irdevanand (Twitter).

ManageEngine spent a decade developing the front-end of one of our most popular IT management applications — OpManager — in Apache Struts. Recently, however, we abandoned that 10-year investment in favor of Ember.js, even though JavaScript itself has been repeatedly slammed as a technology that’s “not ready for prime time” in the enterprise. So why did we make the switch? Here are our top four reasons.

1. JavaScript instills discipline

As a server-side MVC, Struts’ proximity to the database regularly tempted our developers to query the database right from the client code. That’s quick and easy, but it also bypasses all the MVC rules. Blame it on our agile development model. Take 50 to 100 developers and push them hard on things like features and support, and corners inevitably get cut.

We were seeing JSP pages full of unnecessary database connections, as well as scattered business logic. Hard to spot initially, the effects of such violations slowly surfaced as we reworked our UI. Simple redesigns or additions were just taking too long.

Here, JavaScript-based, client-side MVC really helps because the JavaScript client framework distances itself from the database. The only way to issue a request from framework to server is via API call. Client-side hacks and roundabout connections are no longer possible.

2. JavaScript accelerates page loads

With JavaScript, every page in the Web client makes an API call to the server and gets a JSON object as the response. That’s it. Every other static HTML element on the page is already compiled and loaded in the browser as something.js. With hardly any HTML code for the browser to render on the page load, the Web client renders pages pretty fast.

With our server-side MVC framework, the client made a request to the server, which generated the required data and encapsulated it in HTML with HTML tags and conditions and then sent the whole page to the client. Only then did the client render the HTML. Yes, this model imposes no extra load on the client because the server does all the work. But JavaScript has come a long way in 10 years.

With the new JavaScript-based client, we can script, or “templatize,” everything--including static HTML with tools such as handlebars.js used along with Ember.js. By shifting our static HTML to the client side, we can just fetch the dynamic portion—that is, the data--of any UI. API calls to the server return JSON objects, which get rendered into templatized static HTML pages in the client.

3. JavaScript saves development time

A lot of application development time gets spent on the UI when you don’t follow a UI-driven development approach and make UI adjustments towards the end. That’s what we used to do. And it slowed us down.

For example, if we had three developers working on three different features in parallel, Struts required all three developers to finish the server-side and client-side coding. By using API calls for server-side functionality, JavaScript frees all but one of those developers from client-side, UI development.

Now, we have dedicated UI developers who can start working on UI prototypes at the start of each deliverable, and the rest of us can test functionality along the way simply by calling the APIs and checking the responses. A UI developer, meanwhile, can work on the new feature with a dummy JSON file. The result? We can prepare for a common exit in far less time when compared to Struts.

4. The JavaScript ecosystem is mature

Until a decade ago, Microsoft set the standard for enterprise software development with a complete suite of .NET development tools, testing tools, integration tools, and so on. No one since has matched Microsoft on a product-for-product basis. Alternatives such as PHP and Ruby on Rails managed to capture developer interest, but neither really caught on in the enterprise.

Today, there is no enterprise software development framework that offers excellent functionality on both the server and the client. But what we have discovered is that we don’t need one. The JavaScript ecosystem—with its countless libraries and frameworks--is amazing. Everything fits together like Lego blocks. As a result, client development over JavaScript has become so good that we can build a great Web client over a modest server-side framework, basically masking any server-side shortcomings and still delivering a cool user experience.

Betting on JavaScript

Even though JavaScript has matured, the JavaScript image is stuck in adolescent awkwardness. For the rest of the world, especially the enterprise application development world, JavaScript still brings to mind a technology used to create little pop-up dialog boxes instead of commercial-grade applications.

From our perspective, however, Ember.js and other JavaScript-based MVC frameworks are enterprise ready. After a long flurry of this.js, that.js and something.js, we are finally coming to a point at which full-fledged frameworks are available over JavaScript. I think Almigthy.js has finally smiled upon JavaScript.

Guest Author

Comments

Comments(1)

If your developers are writing database calls from .jsp's, using javascript won't make them better programmers. I love Ember, but there's a lot here I disagree with.