Why EJS?

Introduction

Check out the EJS Introduction.

Power, Flexibility, and Freedom

Elentra JS represents a long-term investment in the platform, providing flexibility by enabling full control of our architecture, high cohesion through normalized interfaces, code stability through enforced standards, and upgradability by avoiding technology lock-in – all of which is simply not possible with direct use of any third-party libraries.

Avoiding Technology Lock-in

Technology lock-in occurs when a specific technology's interface is used directly across a software system. When it comes time to replace this technology, it could prove costly or even impossible if the change requires updates to every part of the system.

For small and short-lived projects, this is not an issue as the entire project is thrown out each time. For long-lived enterprise products, this could prove to be a significant impediment to future growth and development.

An often missed but important part of avoiding technology lock-in is allowing technologies to be upgraded. If a technology changes drastically from one version to the next, the affect on lock-in is the same as if it were a new technology altogether: every part of the system requires a change. Or we do without the update. Neither is a great solution.

A good example of this is the Bootstrap CSS library. As it touches nearly every single HTML element across an application, upgrading to the latest version (with breaking changes) is impossible without a rewrite.

By abstracting all architecture, business logic, internationalization, networking, and templating it makes it possible to change or upgrade existing technologies without rewriting the entire application (e.g. changing the template library doesn't require changing the routing library). As developers write code for EJS (which we control) instead of for third-parties (which we don't), it provides us with the option of swapping out functionality 'under-the-hood' without affecting any downstream developers. Martin Fowler calls this the Gateway Pattern.

With EJS, technology lock-in is a thing of the past. This could represent years of work and millions of dollars in savings per product, each time the industry shifts – this is agility in action.

Agile vs Agility

Agile is a popular concept in the industry to describe a process for managing projects with predefined processes and ceremonies, powered by various software tools (such as Jira). Scrum and Kanban are the most common Agile methodologies.

Agility is a focus on design that prioritizes the best solution (defined as the one that is easiest to change) instead of the quick solution (which often costs several times more over the life of the product). When things are easy to change, they can change quickly (perhaps to react to industry trends or a failure event), and are less likely to introduce bugs as changes are focused and do not have unexpected side effects – you only need to test your change, not the entire system.

High cohesion, object-oriented design, and a dedication to simplicity all ensure developers can accurately reason about their code which reduces the learning curve (code is easily understood), improves productivity (changes are focused and easy to test), raises morale (easy tasks are easy), lowers churn (daily frustration reduced), and reduces bugs (due to less developer confusion).

Best Practices and Standards

Standards and conventions are extremely useful tools in any software project. However, these tools put the onus exclusively on each developer to be disciplined and follow them. With EJS, we are able to not only document best practices and standards, but also to enforce them.

For new developers, this is a very important aspect of EJS, as it can catch and prevent countless mistakes while providing guidance and training. And, for experienced developers, it additionally provides a mechanism for maintaining a consistent design methodology across the platform.

Latest Technologies, No Build Required

From its inception, EJS has operated with the core requirement of not requiring a build step, while still supporting one if necessary (to support a legacy browser, for example).

With unified file handling, EJS is able to provide on-the-fly support for functionality that typically requires compilation (such as VueJS single-file components). This greatly improves developer productivity by reducing the amount of time they spend waiting for code to compile. As the code you write is the code that runs, debugging and development are greatly simplified and do not require special tools.

Designed with an eye on the future, certain parts of EJS may seem a bit unconventional at the moment. However, its design aligns with recent and forthcoming web standards such as the Fetch API, Async Functions, Class syntax, Service Workers, HTTP2, Shadow DOM, and more.

Use Statements vs Native Imports

When EJS was first created, its target browsers did not all support native imports or the Service Worker API (neither of which could be polyfilled). Given the requirement to avoid compiling, the use statement was the only solution.

That said, all target browsers do now support these technologies and EJS will support them in a future release (the Imports 2.0 epic).

Another advantage is the ability to keep imports clean and organized. Native imports are very often used rather unscrupulously, creating quite the tangled mess that all-but-guarantees bugs and maintenance nightmares.

Where's Webpack?

Webpack is a technology that is designed to overcome an important limitation of HTTP 1.0/1.1, namely the limits on how many files can be simultaneously loaded by a browser. However, the HTTP 2 specification resolves this limitation natively.

In addition, Webpack provides integration with other technologies like SASS. However, SASS's most useful features are now included in the CSS specification and the forthcoming Shadow DOM.

Based on these industry trends, it is likely that the value of Webpack will continue to wane in the future.

Regarding performance, EJS performs at least 30% better on HTTP 1.1 than Webpack does on HTTP 2. The numbers speak for themselves:

Library	HTTP Version	Chrome Audit Score	3G Score	Build Step
EJS	HTTP 1.1	98 / 100	43 / 100	No
Webpack	HTTP 2/SPDY	75 / 100	1 / 100	Yes

Note: Values compare the EJS Component Library Docs to this page on GitBook.