I'm a big fan of modern Javascript frameworks. I use them every day and they make development fun again (even if you dislike Javascript!). However, more and more Javascript is something that is making me increasingly uncomfortable. For a number of years now, I've been worried about web obesity. I'm not alone https://idlewords.com/talks/website_obesity.htm
We use Javascript for everything! As cool as it is, it's not good for our front-end health.
Maybe I'm old school but I remember when Javascript was used to sprinkle web pages with interaction and other loveliness not available in HTML and CSS. This kept web pages lean, mean and Javascript to a minimum.
Less Javascript
As I said modern Javascript frameworks are amazing to work with but I've seen them used badly. This results in bloated web applications. It is common to see web apps that are over 2 MB in payload - even after tree-shaking!
This is in part due to the awesomeness of NPM. NPM seems to be a default for many developers looking to solve problems with a library and not considering the extra payload it will add to their applications. NPM packages are primarily for NodeJS and although many do provide browser bundles, often these are transpiled using polyfills and other unnecessary code to make them compatible with all browsers.
In a recent internal hackathon, an open clinic was set-up to allow developers to ask front-end questions at the start of their hacks. One question was asked more than any other "how can I use this NPM package I've found in my hack?". One of the limitations of the hack was that build tools were not allowed - no Webpack, no Rollup, no transpilation - just pure HTML, CSS and Javascript in the browser. Are developers lacking the understanding of how web applications run in the browser?
Progressive Web Apps (PWAs) are web applications that have been designed so they are capable, reliable, and installable. They are meant to be lightweight and fast - to feel like native applications in the browser. PWAs are an excellent set of principles for developing any web application. Performance is key in providing a great experience in your application. Too much Javascript can easily degrade the performance of your application.
More HTML
Whilst it is easy to fall into the trap of using Javascript for everything, it bloats unnecessarily.
Component based frameworks are amazing but they ultimately mean more and more javascript. Javascript is needed to generate HTML, Javascript is needed to provide user interaction, Javascript is needed to do all the things.
HTML has a rich set of elements for building modern web applications. Using more HTML and sprinkling Javascript where required will result in less Javascript. Less Javascript means more lightweight, fast web applications.
Use of more HTML elements for creating the application shell - navigation, menus, page structure means that Javascript is reserved for the areas where it is needed - a form, a data grid, a tree view.
Web components, whilst Javascript, provide a very lightweight way to extend HTML and provide baked-in solutions for common component problems. Web components can provide a way to implement common UI elements like tabs, dialogs and dropdown menus that work across all modern javascript and server-side frameworks.
More CSS
Styling web applications can be tricky and there are some great solutions for developers out there. Unfortunately, many of these rely on Javascript - all adding more and more Javascript bloat. Is this really necessary?
Being able to style components and enhance them in a progressive way can all be done natively with CSS. Using modern features like CSS variables and taking the time to split CSS into per page (or route) styles can lead to good web application performance.
In summary
The governing body for professional cycling in Great Britain, hired Dave Brailsford in 2003 as its new performance director. At the time, professional cyclists in Great Britain had endured nearly one hundred years of mediocrity. Since 1908, British riders had won just a single gold medal at the Olympic Games, and they had fared even worse in cycling’s biggest race, the Tour de France. In 110 years, no British cyclist had ever won the event.
Brailsford had been hired to put British Cycling on a new trajectory. What made him different from previous coaches was his relentless commitment to a strategy that he referred to as "the aggregation of marginal gains" which was the philosophy of searching for a tiny margin of improvement in everything you do.
This philosophy works well for web application development. In particular, addressing the issue of bloated web applications that have too much Javascript.
We need a new trajectory in front-end web apps; More HTML, CSS, Web components and a little Javascript.
Just imagine how better the user experience will be.
Latest comments (19)
I 100% agree with the title and article!
I agree with you. It is often less overall that makes applications more performant and provide better user experience.
I agree with the principal of what you're saying, but I don't want to go back to jQuery. I like where Svelte is headed: building web applications using HTML, JavaScript, and CSS and some magic to help with reactivity.
I totally agree with you - I don't want to go back to the jQuery days! Svelte is an excellent library and is born out of a desire to make things lighter and more performant with less runtime dependencies.
React and other framework are for Web Apps, HTML, CSS, and general JS is for a website. People have a tendency to conflict the two but they serve different purposes and act differently depending on the situation. So, I agree websites shouldn't use React, etc.... but web apps should.
I agree it is often hard to know where that line is. I work in a corporate environment where most software is web applications rather than websites. However, I'm not sure that the two are necessarily miles apart. It does depend on the context of course but there are many applications I see that would benefit from alternative choices - more lightweight libraries or good use of native browser APIs.
You aren't wrong, embracing native api would be generally best, but there is an easy way to identify a web app and a website, and it's all based on how interactive the site is. A website is a showcase of digital presence while a web app is an interactive application built on web technologies. A website can be very interactive but if the main goal is to showcase a companies digital presence then it is a website.
When you do use Javascript you could use less JavaScript via some JS libraries that have smaller footprint/bundle sizes like cashJS, Dabby, YumJS :)
cashJS- github.com/fabiospampinato/cash
dabby - github.com/hexydec/dabby
YumJS - github.com/bretgeek/yumjs (small with reactivity)
you need the WYSIWYG!!! no/low code is the future, i would say: Less Javascript, HTML and CSS!
I love that you're also an admirer of the marginal gains ethos espoused by Dave Brailsford. However, I have a different view of how it should be applied to developing web apps.
I prefer to build complex web apps entirely in React and JS because I only need to think in one paradigm. Therefore, I can develop and iterate much more rapidly.
If I were to apply the marginal gains philosophy to my approach, I would look for all the 1% performance gains possible in JS (e.g. memoisation, using switch case instead of else-if, etc.).
As business requirements for web apps seem to get more and more demanding, I believe this is the best approach for optimal developer experience and user experience.
An interesting view. I agree that business requirements seem to get more demanding. I'm not suggesting that we drop libraries like React - far from it. Often React is a perfect fit for applications. What I wanted to highlight was an overall awareness of an increase in bloat. I often see libraries used as sledgehammers where lightweight alternatives would fit better. I also see a lack of skills in how to develop for performance because there is no understanding of the underlying web platform - just knowledge of the library.
Yeah, I have the same sentiments about JS frameworks being used unnecessarily for completely static sites, so I guess we actually agree on most things.
The only other aspect my view differs is how much underlying knowledge is required - imo, if someone knows how to optimise performance within a framework, then it's probably not necessary to know lower-level optimisation techniques (although it would be better if they did, of course)
Less JavaScript != better UX != business value
JavaScript and modern libraries that make 2mb bundle are here not for fun.
Let's compare React application with web components:
In any case, remember that applications that we are building have business value and should both cost as little as possible and be as performant as possible – modern libraries (no matter what you choose – react, angular, vue, svelte) will provide both good performance and low cost (developer time).
I do strongly believe that a knowledge and awareness of the target platform will result in better choices. The W3C have a comprehensive process for evaluating and including standards for browsers to implement. These standards are what applications should target. Whilst many do not agree with web components but do follow standards such as HTML and CSS3, I often wonder why? If the web component APIs were a carefully considered platform API, why are they dismissed so quickly? Wouldn't libraries become naturally lighter when adopting native APIs internally whilst offering the same gains in developer productivity?
You are missing the key point – business value, as I said before, web components do not provide any advantage when compared to other tools and usually they are even harder to work with.
Let's take react for example. I believe that engineers that worked on it at fb are not stupid and the decision to build library on top of virtual dom and jsx was not made in one day. When building something this huge you need to appeal to largest possible audience. Everybody know html and javascript – everybody know 80% of react before even starting. This provides better DX, larger community and business value.
Business value is a broad argument - it depends on what that value delivers. In my organisation, we have dozens and dozens of products all built over many years using a range of technologies. Modernisation, building new products, support, developer skills (and more) all have an influence on delivering business value. Most of these products are web applications and therefore aligning to standards will offer the most business value - this is very contextual and organisations/strategies vary so business value is a broad comparison.
These are all great advantages of using React - I agree with you and often choose React for these reasons.
What I wanted to highlight was not a comparison of libraries but an awareness of good choices when developing applications that are targeted at browsers.
As an architect, I see many projects that default to a particular library or technology regardless of the context/scope of the app. Many developers I work with have little awareness of the impact of their choices and not all develop with performance in mind.
As you mention, tools are designed to help with many of these issues, particularly when apps need to scale. An increased awareness of the end result and utilising what the runtime provides natively will result in better products (often less bloated).
I didn't see a mention of web components in this post... Also, web components are built from JavaScript. It's the same problem. I believe what Matt is saying is that we use JS for things html and css were supposed to do. I agree with him. A good alternative to using a framework is just using html, css, and js. No fancy stuff.