Posted by admin
22 September 2017

By: Nelson M. Nones CPIM, Founder, Chairman and President, Geoprise Technologies Corporation

So-called "Full-Stack JavaScript Single-Page Applications" (SPAs) were all the rage a few years back. What's a Full-Stack JavaScript SPA, and how is it different from other Web applications?

LAMP, WAMP and HTML

Before Full-Stack JavaScript SPAs gained traction, many Web applications were written and deployed on "LAMP" or "WAMP" solution stacks. "LAMP" refers to a combination of the Linux operating system, Apache Web server, MySQL relational database and the PHP scripting language, all deployed server-side. A "WAMP" stack is similar, but uses a Windows operating system instead of Linux.

There is also a "Java Stack" consisting of Apache Tomcat/Jboss, Apache and MySQL; and Microsoft's .NET stack.

On the client side, when users request a page from a Web application using their browsers, the Web application server returns a document written in HTML (hypertext markup language). HTML is a global standard which all popular browsers are built to support. Those browsers will have no trouble displaying the page just as the developer intended.

But "pure" HTML pages can be a bit boring; and they're not quite as pretty or rich in features like PC applications or smartphone apps which are installed and run on client devices. That's because HTML is mostly static. Aside from displaying dropdown and radio lists dynamically, and allowing users to enter text from the keyboard, the only thing it can do is receive an instruction—such as a user's gesture or mouse click on a hyperlink or button—and relay it to the server along with any text entries. The server does nearly all the work.

JavaScript

Enter JavaScript—not to be confused with the Java programming language—which is far and away the dominant client-side scripting language these days. All popular browsers support JavaScript in addition to HTML. A Web application's HTML pages can either contain embedded JavaScript, or load the JavaScript from the server when the page is loaded into the browser.

Judicious use of JavaScript can make Web pages considerably more dynamic and user-friendly than static HTML pages. For example, the GM-X ERP application uses JavaScript for:

  • A popup date picker that appears whenever a user selects a text field containing a date, and allows the user to interactively browse a calendar and select a date instead of typing the date from a keyboard;
  • A password strength meter that interactively measures and graphically displays how easy or hard it would be to guess a new password, while the password is being entered from a keyboard;
  • Dynamic combo bar-line charts for visualizing employee performance in the GM-X Strategic HR subsystem;
  • Dynamically expandable and collapsible Gantt charts for visualizing project plans and progress in the GM-X Project subsystem; and
  • Dynamic drag-and-drop workflow process authoring and visualization canvas in the GM-X Workflow subsystem.

Starting about a decade ago, JavaScript's capabilities led a great many developers to believe that it could be employed much more extensively to make Web pages every bit as feature-rich and user-friendly as PC applications or smartphone apps. To facilitate this, a number of model-view-controller (MVC) frameworks that run in browser JavaScript engines, such as AngularJS, were introduced.

Lean, MEAN and Single-Page

It was at this point that these developers began to ask, "Why not use JavaScript on the server side also?" (JavaScript, after all, was first introduced as a server-side scripting language back in the 1990s.) Their motivation was to make software development leaner and more agile by reducing the number of skills and people required to build and maintain Web applications. Instead of having to field two teams of developers—one specializing in JavaScript and the other in, say, PHP—only one team would be needed. Because they all speak the same programming language, teammates could work in perfect harmony.

And so Node.js and Express.js were born. Node.js is a server-side JavaScript execution environment for Web and networking applications, and Express.js is a Web application framework that runs on Node.js. Hooked up to the MongoDB NoSQL database, and together with AngularJS on the client side, they form what is known as a "MEAN" solution stack—MongoDB, Express.js, AngularJS and Node.js. Because it uses JavaScript on both the client and server, MEAN is a "Full-Stack JavaScript" solution. And it became all the rage.

Many Web applications built upon the MEAN solution stack are known as SPAs because the server only ever sends a single Web page to the browser. This page is an HTML page, but the HTML tags are only wrappers for the JavaScript. This approach is thought to be cleaner and faster than a LAMP or WAMP solution stack—not to mention a lot more feature-rich and user-friendly—because the server doesn't have to refresh the Web page with each user request.

Reality Check 1: Performance

So, why didn't Geoprise jump on the MEAN SPA bandwagon? Well, as they say, "If it sounds too good to be true, it probably is ..."

Consider the purpose of the GM-X ERP application. Unlike a lot of Web applications—such as online retail banking portals—which are designed and built to serve marketing as well as purely business purposes, the GM-X ERP application is designed and built strictly for business. In business the only things that matter are performance, security, end-user productivity and cost. Performance, in turn, is judged by an application's speed, reliability, accuracy and the extent to which functional requirements of the business are satisfied. Moreover, enterprise applications typically don't use a NoSQL database like MongoDB; instead enterprises prefer to use proven relational databases like Oracle or Microsoft SQL Server for performance and high availability.

I've recently been required to use an enterprise application hosted by one of our Geoprise clients. It's a well-known business process and electronic document management system available from one of the world's largest software houses, and it happens to be a Full-Stack JavaScript SPA which has been commercially available for several years. Here are some of the issues I've encountered as an end-user:

  • The application relies on the node Node.js server runtime to communicate with the database. However the relational database integration capabilities of Node.js are immature, causing SQL queries to execute slowly or fail in high-volume deployments. For example Node.js doesn’t properly handle the Microsoft SQL Server snapshot isolation feature. As a result, the failure rate for finalizing approval workflow cases is about 4%—meaning that 4% of those cases need to be re-started and approvals sought from multiple users all over again.
  • If you think JavaScript is browser-independent, think again. JavaScript behaves differently in each browser (Internet Explorer, Chrome, Edge, Firefox, etc.) so as a result the application behaves differently in each browser. For example, lists appear in a different sequence on the same screens in Internet Explorer and Chrome. On some browsers, but not all, certain buttons will not work unless the display is enlarged to 125%.
  • The client-side JavaScript isn’t written to properly handle all Unicode characters (such as Chinese) or keyboard actions (such as backspacing past the first character in an input field), which causes the browser tab to crash unexpectedly.
  • One of the goals of client-side JavaScript is to make forms input as dynamic as possible (dynamic dropdown controls, for example) but this approach makes the application's screens perform very slowly. That’s because it requires the browser to query the server in real time when constructing dynamic controls such as dropdowns. Performance would be much faster using pure HTML controls, but the Full-Stack JavaScript SPA architecture doesn’t allow that.
  • JavaScript introduces security vulnerabilities like cross-site scripting (XSS) and man-in-the-browser attacks. For this reason, some security-conscious organizations use group policy objects (GPOs) to disable scripts in the browser. However any Full-Stack JavaScript SPA will not work at all on a disabled browser, so this security measure is not available to any organization which deploys the application.

Some readers might object that the issues I've found are bugs one would normally find in any complex enterprise application, which can be fixed in due course. They could be making a fair point for some of these issues, but others point to systemic flaws in the entire Full-Stack JavaScript approach. Most significant is the fact that JavaScript behaves differently on different browsers, which is something beyond an application developer's control. Instead of supposedly becoming leaner and more agile, developers are forced to spend time testing and dealing with the idiosyncrasies of each brower. This in itself is a constantly moving target as new browser versions are released. By contrast, because it relies far more on HTML than on JavaScript, the GM-X ERP application behaves consistently on all the popular browsers that business enterprises typically use today.

Reality Check 2: Security

The last of the issues I observed above has become an urgent concern as incidences of security breaches continue to proliferate. Earlier, I chose the phrase "judicious use of JavaScript" deliberately. Of course none of the GM-X JavaScript features I mentioned will work when scripting is disabled for security reasons; but GM-X screens will remain fully functional nonetheless. For example, the date picker won't pop up, but users can still enter dates from their keyboards. It may not be as convenient for users as the date picker, but when security really matters it's the price an organization has to pay for the added security.

Reality Check 3: Mobility

During the time Full-Stack JavaScript SPAs and the MEAN solution stack became all the rage among developers, so did mobility. It's a common misconception that JavaScript is needed to make applications work just as well on smartphones as on full-screen browsers, but this in fact is true only if an "adaptive design" approach is taken. Adaptive design requires several static layouts to handle different screen sizes, and JavaScript can be used on the client side to detect the user's device and choose the best layout to display. A "responsive design" approach, on the other hand, delivers an optimized view of a Web page no matter what device is used. It also loads much faster, because only a single rendition of a page is required instead of several static layouts.

For this reason, Twitter recently discarded its SPA approach and introduced Bootstrap, a responsive design framework that relies entirely on cascading stylesheets (CSS) instead of JavaScript. Geoprise deployed Bootstrap to implement the responsive design approach for all 2,580 visible GM-X screens earlier this year—a process that took our developers about 3 weeks from start to finish with results that have drawn nothing but praise from our clients.

By contrast, the Full-Stack JavaScript SPA application I reviewed earlier isn't useable for any practical purpose on smartphone devices. It only has a single static layout, which is optimized for full-screen browsers only and could also be useable on a horizontally-oriented tablet device.

GM-X: The No-Page Web Application

Proponents of the MEAN solution stack would likely point to those 2,580 GM-X screens as a key reason why the SPA approach is leaner and more agile. They'd be right if all those screens were static, handcrafted HTML. But they aren't.

GM-X also uses an MVC framework at run time, just like AngularJS. Our MVC framework doesn't require static HTML pages. Instead, it generates HTML pages on the fly whenever users request them. Technically speaking, when responding to each request, our framework organizes and then constructs an eXtensible Markup Language (XML) document, which it then transforms to HTML using eXtensible Stylesheet Language Transformations (XSLT). As a result, the GM-X ERP application doesn't have any static pages. It is truly a "No-Page Web Application."

That's a 100% reduction in the number of Web pages compared to an SPA, yet GM-X works on any full-screen, tablet or mobile device and remains fully functional even when scripting is disabled for security reasons. The Web pages which GM-X generates at run time work identically on every modern browser and are fully equipped to handle UTF-8, which is by far the most widely used Unicode encoding standard for Web applications today. They are fast, reliable, accurate and secure; and require no applications other than a browser to be installed on end-user devices.

How simple, lean and agile is that?

Tags: