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,...
For further actions, you may consider blocking this person and/or reporting abuse
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 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.
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 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.
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.
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.
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)
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)
you need the WYSIWYG!!! no/low code is the future, i would say: Less Javascript, HTML and CSS!
I agree with you. It is often less overall that makes applications more performant and provide better user experience.
I 100% agree with the title and article!