For 5 or so years I've been the guy who immediately started a SPA and I've turned 180 degrees. I now think SPAs are basically a cancer, with some exceptions where an app-like website is justified (Gmail, etc) or a hybrid app. SPAs introduce unnecessary complexity and bloat for the vast majority of use cases.
The html version of gmail still works great! It also loads in under 30 seconds (near instantly for me) and is incredibly snappy. It also doesn’t look like a PM vomited google product integrations over the screen.
"SPA" is a fine, if difficult, architectural pattern. One needs to make a distinction between the processes and tools, and the pattern itself. SPAs are bad because of how they are built; personally, I blame the rise of front-end build tools for this. When it's easy to add dependency after dependency, then you get a bloated nightmare. Transpilers don't help, either, since they just remove you even further from "bare metal" of the browser, which is itself already at a dizzy height from the bottom. You might say that modern javascript programmers are too high, so to speak.
I'm with you. It occurred to me that what I love about things like react or vue has nothing to do with SPA capabilities. It's just developer ease in building reusable, composable, testable components.
I've had similar experiences with scaling too early into microservices for example. I need a seriously compelling reason to consider building around these paradigms now. The overhead is unreal.
Both great ways to solve a problem, but not really a problem I've yet encountered - ever.
I'm still glad I've had great opportunities to learn this, at least.
Thing is, building reusable components was always a feature of SSR Web frameworks since early 2000's, so there is no need for react or vue for bundle the HTML/CSS/JS that makes a fancy calendar widget.
And with WebComponents being supported across the board, even less so.
There is so much entertainment in SPA vs HTML and similarly Vim vs Visual Studio, static vs. dynamic types etc. debates. But to be boring (sorry!) it all comes down to the most approriate tool for the job. At work it's a SPA because it's an application delivered via the web. Delivering via not the web wouldn't work as well, and delivering it as not an application is a non starter.
My current side project is a HTML sprinkled with JS, turn off JS and you can use most of the site kind of thing. Why? Because ... well mainly SEO to be honest. But there you go ... reasons!
> But to be boring (sorry!) it all comes down to the most approriate tool for the job.
It does. But, depending on how you look at it, either most web companies absolutely suck at picking right tool for the job, or the job isn't really what you'd think it is.
Taking your typical plain webpage done as an SPA, you could either say (as I would) that the authors picked wrong tool for the job, introducing completely unnecessary complexity both on their end and customer end - or, you could tell that the job of that website isn't to be useful to and considerate of the visitor, but to be e.g. CV-fodder for web developers, a way for the team to show off their sophisticated infrastructure, or for the marketing to play their A/B testing shenanigans, or for the company to show off to the investors, etc.
Once you account for all the "parts of the job" that are orthogonal or even opposite to delivering value to users, suddenly a proliferation of frontend complexity makes perfect sense.
Google recently updated their crawlers to understand "full Javascript websites" ; I don't like the term spa as one could build one with pure css and html and still have a single page.
Now onto the js frameworks, it depends on which one is used. One could build a website watching web.dev and use a budget to make sure it's app is lightweight. There are numerous tools to make sure an app is properly made. But tbh, I like my js framework because the community is so great, I know the framework is good even tough there are arguments there and there.
I guess it all depends on the tool you choose and how you build your end product. Now having a website that loads in 30s is a joke I haven't experienced in the modern web, and my js framework actually provides a powerful caching system that makes the website available even tough I could bring down my dns. To this point I presume we are just in a odd point in web evolution where we have discovered a new paradigm and rushed into it's usage without maturity.
These things will change but I think it is important to know that some JS front framework are not incompatible with a lightweight web.
Bah, to hell with your boring moderate stance! I would much rather have endless debates with others about why MY hammer is better than their hammer, and ignore the fact that maybe not everything is a nail ;)
If you use the right tools, SPAs reduce complexity.
The problem is that most of the popular frameworks today add unnecessary complexity.
I still can't believe that we live in a world were most developers are OK to coding with a 5 to 15 second build delay and source mapping during development. I find is extremely frustrating. It slows me down and breaks my train of thought.
If you go the SPA route you have to, at the minimum, add some form of routing and manage application state and logic. It doesn't matter how good the tools for doing that are, there is always going to be an overhead to do that.
I'm working on a dashboard for a personal project. It involves a few dynamically populated dropdowns and a map with custom markers. In the past I might've used jQuery and maybe Backbone in more extreme cases. After looking into the "modern" options available I ended up writing the damn thing in jQuery. I did it in a few hours without having to involve Node, npm (or yarn), hundreds of dependencies (and associated security concerns) or "(com|trans)pilation)" of anything. The whole process reminded me again of why I went from fullstack to working exclusively on backends years ago.
Out of curiosity - did you chose jQuery because it's so ubiquitous or was it the better choice? There are frameworks like vue.js where you don't have to deal with node, yarn, explicit dependencies and transpilation, that offer virtual DOM and have very little overhead.
Better choice ultimately but I suspect the hype around "modern" everything these days would still lead a lot of people in that direction, even for simpler things like this. I did briefly look into Vue and didn't completely hate it. Although the docs (at least from my cursory glance) were suggesting you would need Node to get up and running with it. Good to know it doesn't need to be that complicated.
Good to know. For small personal things that need JS, I too tend to just go for jQuery, or increasingly stick to vanilla JS. React is ridiculously overcomplicated for small projects[0] IMO. I always thought that Vue is just a React competitor/copycat, so never bothered to investigate it. Since you say it offers more lightweight vDOM with no JS NPM tooling bullcrap, I'll look into it, so thanks!
--
[0] - I used React a bit, and I can only stomach it when working with ClojureScript, which gives some sanity to the syntax and language - but that's another pretty large and very complex dependency to be included in the pipeline!
For these cases I like to use Vue with a script tag. It's smaller than jQuery, probably more convenient, and depending on your use case you can get away with writing ES6 with no babel.
I don't know, on the one hand, JavaScript is without doubt neccessary for a lot of useful things on the web. OTOH, I always thought of JavaScript as a way to get a better declarative web long term, by experimenting with UI paradigms and trying things that eventually can become part of new declarative HTML UIs. But that feedback into HTML never happened, and it seems we're stuck with an incredibly poor language we're enslaving the next generation of both users and developers in. The worst part is IMHO where we attempt to shoehorn JavaScript into a "serious" language with ES6+ classes, modules, new syntaxes, type decorators and what not; all we've achieved with these inessential extensions is to make future browser implementer's life difficult.
I haven't listened to the audio, but all it takes to get rid of JavaScript-heavy pages (that only exist because young webdevs are being taught and drool about mostly JavaScript, React, and other overkill rather than web basics), we just need to step up the game and demand power-efficient webapps, or no webapps at all.
Experienced engineers use react when it is needed for the enhanced ux. JavaScript is actually a decent programming language if you use the functional paradigm and read enough books and ship enough products to understand its strengths and weaknesses. It’s even better with typescript.
The static pages are in static HTML, because of course they are.
But the product pages need to be interactive. To do that, I need to use JS, and an SPA framework (I use Vue) makes that easier and way less effort than (e.g.) JQuery.
I have one problem, though... the marketing folks want to be able to change the copy on the static pages, but they don't want to learn HTML. They're pushing for me to implement the static pages as a Wordpress site, with a list of pluging that they want, because that's what they're used to.
It’s fairly trivial to setup a simple text file with all the websites copy so that when the file is updated a script can automatically fire to rebuild the static pages and deploy it.
That doesn't answer the marketing folks' concerns in GP. They don't hate HTML because they prefer markdown or whatever; they want a WYSIWYG/drag-and-drop site builder because it's what they're used to.
I'm tired of discussions concerning "Javascript" and "the web" where absolutely conclusions appear to be drawn. JS is a language, the web is a platform. Ofcourse overusage of JS results in annoying bloated websites, but when you want to build interactive applications that can easily be distributed to the entire world, the combination of JS + web is a virtue. The web isn't only for displaying static content, it's time to accept that.
Does this mean Svelte 3 is the Tesla of the web? No virtual DOM it's like it doesn't even use gas. XD
tl;dl around 20:45: They're comparing javascript and the tools you use for it to transportation modes. Saying things like Angular was the H2, React is the H3, vanilla javascript is riding a bike. They really are just saying don't over engineer things and use the right tools for the job.
Douglas Crockford's Javascript the Good Parts, is imo the best when it comes to getting a feel for what the right/wrong tools are. That book was a perspective changer for me. People like to get very passionate about frameworks and how Javascript should be done. JS The Good Parts made me realize it's better to play the strengths of what's available to you here and now. To accept the tooling as it is with its pros and cons - exploit the strengths and minimize the impact of the cons.
I'm wanting to enhance a server-rendered template with a bit of JavaScript to fetch data from the server and update the DOM.
I like that Vue can be "dropped in" to any HTML page, like jQuery, without completely taking over the frontend development process, but it still weighs in at 30k. Also, the Vue docs are primarily oriented towards a pre-processing SPA workflow.
Are there any light-weight libraries like Vue, around 2k-5k, that enhance static HTML with declarative DOM manipulation reactive data binding?
Is there a "plain JS" approach to declarative DOM manipulation?
Keep a sense of scale. 30 KiB is small. If all the libraries you use add up to less than 50 KiB, then really, no one will notice.
Think of a "modern best-practices" site that uses a big framework and some big addons and feature libraries, and ends up with like 500 KiB of JS. Some end up with megabytes! That's crazy. I think these developers don't have a sense of scale. They probably think I promote premature-optimization, that they're good engineers who follow best practices and use best-in-class tools and techniques ... but they don't have a sense of scale to see how the results are not reasonable.
30 KiB is small. 100 KiB total is probably quite OK. 500 KiB is very fat. 2 MiB is crazy town. Sense of scale :)
I also like that it comes with no virtual dom, but just remembering direct references to the "holes" that need filling. It's funny that vdom has gotten so much traction albeit being inherently inefficient.
Yeah, I really like the idea of Svelte. I'm just coming from the perspective of wanting to sprinkle in a little JS in my development flow, and avoid pre-processors or compilers, if possible.
Check out reLift-HTML, https://github.com/mardix/relift-html, A very small (3kb) view library that allows you to create Web Component, Custom Element, and helps you make any HTML page reactive without the bloat of big frameworks.
I just write the DOM updates into a controller layer’s setter functions, or use event listeners. I find it easier to work with than angularjs, but haven’t used angular 2+ or react so maybe I’m missing out on something.
Correction, Vue minified and gzipped seems to be around 20k, so might still be my best bet for sprinkling declarative DOM manipulation into the static HTML.
Is there perhaps a library in the 2k-5k range, or somehow a way to use only specific parts of Vue (like a custom build)?
I think that VueJS is a great framework because it's very flexible. I love being able to build entire apps without a bundler and no build step. I hate bundling during development. It's so slow.
Readit News
For 5 or so years I've been the guy who immediately started a SPA and I've turned 180 degrees. I now think SPAs are basically a cancer, with some exceptions where an app-like website is justified (Gmail, etc) or a hybrid app. SPAs introduce unnecessary complexity and bloat for the vast majority of use cases.
Jesus Christ what is going on with the web.
I've had similar experiences with scaling too early into microservices for example. I need a seriously compelling reason to consider building around these paradigms now. The overhead is unreal.
Both great ways to solve a problem, but not really a problem I've yet encountered - ever.
I'm still glad I've had great opportunities to learn this, at least.
And with WebComponents being supported across the board, even less so.
My current side project is a HTML sprinkled with JS, turn off JS and you can use most of the site kind of thing. Why? Because ... well mainly SEO to be honest. But there you go ... reasons!
It does. But, depending on how you look at it, either most web companies absolutely suck at picking right tool for the job, or the job isn't really what you'd think it is.
Taking your typical plain webpage done as an SPA, you could either say (as I would) that the authors picked wrong tool for the job, introducing completely unnecessary complexity both on their end and customer end - or, you could tell that the job of that website isn't to be useful to and considerate of the visitor, but to be e.g. CV-fodder for web developers, a way for the team to show off their sophisticated infrastructure, or for the marketing to play their A/B testing shenanigans, or for the company to show off to the investors, etc.
Once you account for all the "parts of the job" that are orthogonal or even opposite to delivering value to users, suddenly a proliferation of frontend complexity makes perfect sense.
Now onto the js frameworks, it depends on which one is used. One could build a website watching web.dev and use a budget to make sure it's app is lightweight. There are numerous tools to make sure an app is properly made. But tbh, I like my js framework because the community is so great, I know the framework is good even tough there are arguments there and there.
I guess it all depends on the tool you choose and how you build your end product. Now having a website that loads in 30s is a joke I haven't experienced in the modern web, and my js framework actually provides a powerful caching system that makes the website available even tough I could bring down my dns. To this point I presume we are just in a odd point in web evolution where we have discovered a new paradigm and rushed into it's usage without maturity.
These things will change but I think it is important to know that some JS front framework are not incompatible with a lightweight web.
The problem is that most of the popular frameworks today add unnecessary complexity.
I still can't believe that we live in a world were most developers are OK to coding with a 5 to 15 second build delay and source mapping during development. I find is extremely frustrating. It slows me down and breaks my train of thought.
Like? I am curious: built a few SPAs (quite complex ones) and it sucked; I got the tools/frameworks from HN.
If you use the right tools ‘tradional’ websites are not complex either.
--
[0] - I used React a bit, and I can only stomach it when working with ClojureScript, which gives some sanity to the syntax and language - but that's another pretty large and very complex dependency to be included in the pipeline!
I haven't listened to the audio, but all it takes to get rid of JavaScript-heavy pages (that only exist because young webdevs are being taught and drool about mostly JavaScript, React, and other overkill rather than web basics), we just need to step up the game and demand power-efficient webapps, or no webapps at all.
The static pages are in static HTML, because of course they are.
But the product pages need to be interactive. To do that, I need to use JS, and an SPA framework (I use Vue) makes that easier and way less effort than (e.g.) JQuery.
I have one problem, though... the marketing folks want to be able to change the copy on the static pages, but they don't want to learn HTML. They're pushing for me to implement the static pages as a Wordpress site, with a list of pluging that they want, because that's what they're used to.
I don't think JS is the problem here...
Vue Router, a plugin, adds the SPA functionality.
I wonder how much of this is a reaction to the complex and volatile nature of frontend patterns, in a psychological sense.
tl;dl around 20:45: They're comparing javascript and the tools you use for it to transportation modes. Saying things like Angular was the H2, React is the H3, vanilla javascript is riding a bike. They really are just saying don't over engineer things and use the right tools for the job.
Douglas Crockford's Javascript the Good Parts, is imo the best when it comes to getting a feel for what the right/wrong tools are. That book was a perspective changer for me. People like to get very passionate about frameworks and how Javascript should be done. JS The Good Parts made me realize it's better to play the strengths of what's available to you here and now. To accept the tooling as it is with its pros and cons - exploit the strengths and minimize the impact of the cons.
I like that Vue can be "dropped in" to any HTML page, like jQuery, without completely taking over the frontend development process, but it still weighs in at 30k. Also, the Vue docs are primarily oriented towards a pre-processing SPA workflow.
Are there any light-weight libraries like Vue, around 2k-5k, that enhance static HTML with declarative DOM manipulation reactive data binding?
Is there a "plain JS" approach to declarative DOM manipulation?
Think of a "modern best-practices" site that uses a big framework and some big addons and feature libraries, and ends up with like 500 KiB of JS. Some end up with megabytes! That's crazy. I think these developers don't have a sense of scale. They probably think I promote premature-optimization, that they're good engineers who follow best practices and use best-in-class tools and techniques ... but they don't have a sense of scale to see how the results are not reasonable.
30 KiB is small. 100 KiB total is probably quite OK. 500 KiB is very fat. 2 MiB is crazy town. Sense of scale :)
I can probably stick with the 20KiB Vue dependency, particularly when it doesn't require any build system or other dependencies.
I'll read more about lit-element. Thanks :-)
Why?
and this https://youtu.be/AdNJ3fydeao
Disclaimer: I'm one of the maintainers.
Can Preact just be "dropped in" to an existing HTML template, like jQuery?
Basic MVC goes pretty far
Is there perhaps a library in the 2k-5k range, or somehow a way to use only specific parts of Vue (like a custom build)?