Monday, 29 October, 2018 UTC
Summary
Today’s post is written by Owen Buckley, Principal Architect of UI at Clarivate Analytics and founder of Project Evergreen,as part of our JS Devs Zone blog series, which highlights technical tutorials and thought leadership on JS Foundation technologies and the greater JavaScript ecosystem written by outstanding members of the JavaScript community.
What’s your favorite part about starting a new project? For me it’s always been the excitement of jumping into something new, understanding the problem domain, encountering new challenges, and taking all the opportunities I can to learn from previous projects.In the end, I value the common goal uniting all projects: to come out the other end with something meaningful such that the business, developers, and users all get a meaningful experience out of it.
Working in frontend development has been one of the most rewarding aspects of my career. Although it can feel daunting to keep up with the ecosystem at times, there is no shortage of amazing libraries, frameworks, tools and personalities out there to appeal to any developer or workflow, for any kind of project, all lead by an incredibly smart and talented open source community. I (and my employers) owe a lot to the OSS community for the great things that have come out of it over the years, constantly challenging the status quo and daring to think differently about how to approach web development. Node.js, jQuery, React, Angular, npm, Bower, Grunt, Gulp, Browserify, Babel, webpack, and many, many more have all had significant and meaningful impacts on the workflows of developers around the world. Even more endearing is the spirit of collaboration, not competition, that I see reflected in these various projects and their communities, reminding me something Steve Jobs said once:
Ideas are so bountiful, that whatever the needs of your project are, there are hearts and minds out there that are eager to share with you their tips and tricks, words of wisdom, and ways of working so that our jobs may be easier and that we may obtain clarity in our efforts. Apple understood that only they were responsible for their own destiny, and that sometimes they might be ahead, other times they may be behind, but what was most important was defining and establishing their own set of guiding principles and being disciplined enough to stay true to them.
In that spirit of what Steve Jobs said and echoed quite eloquently by Simon Sinek, is making sure to understand the why of something and the story behind its creation. React makes a great example. At the time React came out, the paradigm it introduced was certainly different than what was generally available at the time, and more than the striking visual aesthetics and ergonomics of JSX, was the embrace of functional programming and opinion on data flow that all reasoned well with the idea of UI as a set of components that helped establish the React paradigm and mental model.
Although React never claimed to be the fastest kid on the block, performance benchmarks and comparison articles between it and Angular (and others) inevitably (and continue) to come out. While being slow or “full featured” was certainly not the intention of React, what I often felt was lacking in many of those comparison articles was a good deep dive that spoke to the mental model of React (or Angular) more thoroughly. The React core team itself would tell you that the goal of React was for creating and maintaining user interfaces at scale that is easy for developers to reason about, and that what they created is just one way to approach it and that it’s OK if you don’t like it. Much like with Apple and Microsoft, for React to “succeed” does not mean that Angular has to “lose”. This is of course equally true for Angular, Vue, Polymer, et al.
One thing I like to remind myself of is that patterns aren’t exclusive to any one particular implementation. React doesn’t “own” the concept of components, much like Angular doesn’t own the concept of data-binding. While React may have popularized the idea of components (AngularJS had the concept too, they were just called directives), nothing prevents an Angular component from adopting a functional, “props” based API, like a stateless React component might. Having worked in both Angular and React across different kinds of domains, I have been fortunate to learn a lot of interesting ways to solve different kinds of problems, understanding their pros and cons, and ultimately a personal mental model of my own for software development that considers them all as shared tools in a common toolbelt. More than the just the technology itself though is the expectation of documentation, developer experience, accessibility of the paradigm, and a host of other institutional considerations that comes with evaluating now workflows and dependencies.
The New Face of JavaScript and CSS
The recent renaissance in the frontend development community has been nothing short of prolific and inspiring, in my humble opinion. Rising to meet the needs of users across all browsers and devices, have come amazing and powerful tools for building web applications. Frontend development is now supported by libraries and frameworks and build pipelines powered by webpack, Rollup and Babel, static site generators like Gatsby and Jekyll, great testing tools and libraries like Jest, Mocha, Karma,, Appium and Selenium just to name a few, and the rise of the Progressive Web Application (PWA). The amount of software available to build applications is near limitless and even more encouraging is seeing these tools all buy into a common goal of catering to developer experience as a critical component in their mission of creating software that aims to help others deliver great user experiences.
As a developer, what’s been inspiring to me has been over time seeing the paradigms driving libraries, frameworks, and early languages like CoffeeScript gain more traction in the community, and seeing that drive the rapid advancement of the JavaScript specification (ECMAScript / TC39), starting with the all-star release of ES2015, which brought a number of features seeing wide adoption within the JavaScript community like modules, classes, more functional programming oriented Array methods (map, reduce, filter), and Promises. Of course we can’t forget all the amazing work being done around CSS like Flexbox, CSS Grid and adoption into the specification of new syntax like nested selectors which are found in preprocessors like LESS and SASS. These new language features are also complimented with new browser APIs, like the set of specifications that make up “Web Components”. With the introduction of the Custom Elements API, developers can now create their own UI components, much in the way a browser already provides a
<video>or an
<input type=”date”>.
Impressive as all of this is given it is just the tip of the iceberg, there is one crucial element to all this that I think really makes it such a land of opportunity for developers and that truly “sells” the concept of the web as a platform; the shift to evergreen browsers. All major browser vendors have moved to a continuous release cycle that updates browsers in place, without the burden of users having to repeatedly seek out, download and install new software just to get access to new releases. This is also appealing to developers, as users with newer browser versions afford developers the ability to deliver modern JavaScript to users, which is often smaller in size and more performant than the transpiled alternative.
In essence, three factors have converged in the frontend ecosystem that are getting me particularly excited about exploring a new approach to application development; language specifications, browsers, and tooling. It’s safe to say, the landscape of the web platform is looking very promising! (pun intended)
The Evergreen Web Application
Although I’m certainly not the first to say this, I do agree that the case can be made for making web applications that adhere to a new set of “constraints” if you will. You may have heard the phrase “use the platform”, and an evergreen web application is full embrace of the spirit of that phrase. It is intended to provide a foundation for creating web applications of any size that are modern, performant, and that most importantly (to me) are intuitive to the developers creating them, and a great experience for the users using them.
This is all made possible by the three factors I cited above:
This is all made possible by the three factors I cited above:
- Language Specifications – New JavaScript / CSS features and browser APIs are getting added yearly that provide first class support for common primitives and developer experiences often required through additional dependencies, and in certain cases can just be polyfilled and removed once the polyfill is no longer needed (as browsers catch up).
- Browsers – Evergreen browsers are now offered by all the major browser vendors which means quicker adoption of new language specs, passive benefits to performance and security, and the comfort of long term support for it all.
- Tooling – Babel and PostCSS can transform modern JavaScript and CSS intelligently based on known browser statistics as shipping modern code is more easily optimized by browsers. This ensures that only the code that needs to be transpiled gets transpiled, which benefits users the most.
I think a visual aid always helps, so let’s take a look at an example of a basic custom element that may look very similar to something you might already be writing now. In the snippet below, we’ve defined our own HTML tag (custom element) using just JavaScript.
To break down some of what’s going on here:
- HTMLElement – native “base” class for creating an HTML element
- class – Syntactic sugar over JavaScript’s prototype based inheritance that pairs well with component based development
- attachShadow – creates a Shadow DOM tree
- connectedCallback – lifecycle method when the element is inserted into the DOM
- customElements.define – this is how we register our custom element with the browser
- getTemplate – Uses a template literal to interpolate JavaScript variables within a string
The idea is that by sticking to just browser “primitives” and APIs we can leverage it as a strategic advantage:
- Polyfills can just be removed over time and can be detected using progressive enhancement to only be loaded if needed
- The JavaScript “standard library” is growing, and you may find that utility functions you might have used libraries like lodash for, may already exist with no library needed!
- Browsers will continue to improve and optimize “native” JavaScript
- Babel / PostCSS keeps bundle transpilation optimized so as browser demographics shift, bundles will adapt and only transpile what is needed
- Developer documentation already available through terrific resources like MDN
- TC39 adoption / browser vendor support for modern features and APIs is happening quickly
Like with any technology, there will naturally be some considerations to keep in mind:
- The “platform” will never solve every use case, so routing, state management, etc. will require some sort of library, however this is often to the benefit of developer experience, which is always a justifiable exception IMO.
- Requires a bit more hands on knowledge of modern build tooling.
- Browser APIs tend to be a bit verbose, and could lead to a bit more boilerplate.
- Resources and documentation are a bit scattered about (but actively being worked on!).
- Not all tooling is “1.0” production ready, so YMMV.
At the end of the day, the complexity has to go somewhere, and for the particular needs of a given project, taking ownership of it may be appealing or strategically advantageous.
Project Evergreen (and Friends!)Personally, curiosity was my main motivator at first, to see what the development experience was like, and if I would be willing to recommend it to others in knowing how robust the ecosystems are for tools like Angular and React, which leads me to the next section…
Now you might have come this far and thought to yourself, “Wait a minute, I think I missed a section. There was no npm install or something to download. How do I get started or learn more?”
That is exactly what the spirit of this article is about! Naturally the web will never satisfy every use case, nor should it, but as a provider of primitives and standard APIs, the web does provide a surprising amount of developer features you can start using to write apps with, and plenty to pull off the shelf to fill in the gaps. As acknowledged at this time the experience may feel very much DIY and that yes, at larger scales, it may very well make more sense to use React or Angular, for a number of reasonable reasons.
However, I think for anyone starting a new project, evaluating an “evergreen” approach is worth exploring for any developer / business case. Just as important as the technology is to me, I am keenly aware of the importance of balancing developer experiences with being able to ship modern user experiences. For that reason I happy to report that that there is good interop with all the popular tools in the JavaScript ecosystem, like:
- npm / Yarn
- ES2015+ w/ Babel
- PostCSS
- webpack
- TypeScript
- Karma
- Redux
- Framework Interop (see Custom Elements Everywhere)
- Dojo
This ensures that we can get all our code splitting, lazy loading, unit testing, production bundling, etc. just like we would any other modern UI application!
I’m also very happy to report that there this an active and enthusiastic community and so I would like to share a few links to resources and repositories that can further assist in the evaluation of developing an Evergreen Web Application:
- Project Evergreen – A GitHub organization of my own focused on providing learning resources by sharing code samples, developer oriented documentation, guides, and future spec tracking. Try out the Create Evergreen App project to get started with developing a modern evergreen web application today!
- lit-html – A small library from the Polymer team combing tagged template literals and <template> for creating performant and dynamic HTML and SVG elements
- lit-element – Component “base” class for creating custom elements that uses lit-html under the hood, from the Polymer team
- create-lit-app – A starter project inspired by create-react-app, using lit-element
- hyperHTML – Template literal based library
- lit-html-examples – Examples of using lit-html
- Custom Elements Everywhere – Site scoring interop support of libraries and frameworks with Web Components
At the end of the day, developing applications should start from a place of design and thoughtfulness, bringing the right technology to bear where and when it makes the most sense. When choosing a library or framework, think about what each one brings to the table, and how it would fit in with the application design as well as the team tasked to develop and maintain it. In addition, libraries and frameworks like React, Angular and Vue provide more than just component / syntax models, and so I urge you to deeply understand their paradigms, ecosystems, and tradeoffs.
I think if the saying “the best code is the code not written” rings true to you, then I think you’ll be excited about what the web platform has to offer.
Happy developing!
Owen Buckley is an energetic and enthusiastic software developer specializing in web application architectures, build tools, and product development. He is most passionate about helping people learn more about technology and how it can help improve their process, teams, and products. He is currently Principal Architect of UI at Clarivate Analytics and founder of Project Evergreen.
You can find him most active on GitHub, Twitter, working on the Providence Geeks website, attending / speaking at local Rhode Island technology meetups, or maybe even cutting some tracks in his home music studio. Please feel free to reach out and say hi!
The post The Evergreen Web Application appeared first on JS Foundation.