DEV Community

Cover image for Less Javascript, more HTML and CSS

Less Javascript, more HTML and CSS

Matt Levy on October 29, 2020

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,...
Collapse
 
rtivital profile image
Vitaly Rtishchev

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:

  • React has community and I believe that those bloats of npm packages are actually useful, web components do not – this means that it will take more time from average developer to build required interface – company will pay more
  • Modern applications have ssr, code splitting and other tools to improve load speeds and perceived performance – you can deliver a product that will feel event faster than web components one without ssr
  • Routing, state management and other stuff that backend left for us – we are making these small tasks so backend engineers can focus on important tasks (like API performance improvements)
  • Good luck with hiring someone who can efficiently work 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).

Collapse
 
winstonpuckett profile image
Winston Puckett

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.

Collapse
 
rtivital profile image
Vitaly Rtishchev

Collapse
 
ducksoupdev profile image
Matt Levy

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).

Collapse
 
ducksoupdev profile image
Matt Levy

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?

Collapse
 
rtivital profile image
Vitaly Rtishchev

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.

Thread Thread
 
ducksoupdev profile image
Matt Levy

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.

Collapse
 
okikio profile image
Okiki Ojo

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.

Collapse
 
ducksoupdev profile image
Matt Levy

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.

Collapse
 
okikio profile image
Okiki Ojo

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.

Collapse
 
aewing profile image
Andrew Ewing

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.

Collapse
 
ducksoupdev profile image
Matt Levy

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.

Collapse
 
bretgeek profile image
bretgeek

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)

Collapse
 
jkhaui profile image
Jordy Lee

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.

Collapse
 
ducksoupdev profile image
Matt Levy

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.

Collapse
 
jkhaui profile image
Jordy Lee

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)

Collapse
 
ije profile image
X. • Edited

you need the WYSIWYG!!! no/low code is the future, i would say: Less Javascript, HTML and CSS!

Collapse
 
ducksoupdev profile image
Matt Levy

I agree with you. It is often less overall that makes applications more performant and provide better user experience.

Collapse
 
cekvenich2 profile image
cekvenich2

I 100% agree with the title and article!