DEV Community

Discussion on: Less Javascript, more HTML and CSS

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