it's difficult to keep up with the design expectations of the modern web with just HTML and CSS.
It's possible but extremely difficult to create a "modern" experience with just html. Just like how we don't build houses with mud-bricks anymore even though it's easier than steel and wood.
On the contrary, I generally browse with JS disabled and there's a strong correlation between sites for which this is existentially problematic and sites whose content or utility are garbage.
I have a personal toolkit of components I call "you might not need Javascript". Dropdowns, slideovers, toggles, modals, tabs, accordions, autocomplete, lightboxes, all with nice transition animations, and all in pure server-rendered HTML+CSS. A lot of it is just semantic elements being used appropriately. How many developers use <datalist> or <summary>/<details>? or :target and :focus-within? In my experience, not enough. How about, using <details> in combination with a CSS [open] selector? The palette gets rich in combination.
Overall, no, it's not hard, but it does require one to study. A couple of times a year, I'll re-read through the HTML LS and CSS specifications. There's a lot in there to build from, and almost all of it has broad evergreen browser support. For the leading-edge stuff, "caniuse.com" remains an essential reference. I currently have my eye on the <dialog> element, high expectations there, works well already in Chrome; Firefox just has a couple of bugs to shake out, and it's experimental (but incomplete) in Safari.
All that said: a light dusting of JS can still provide progressive enhancement, but we can limit this to minor cosmetic improvements & optimizations, for browser compatibility, and where dynamic ARIA markup is necessary.
The motivation as to why I prefer this style is another matter, and it's do with product strategy, and in particular, not crystallizing your architecture in the front end (where it is brittle) but in the backend (where it is much faster to pivot and/or rapidly prototype/spike/redevelop, by proximity to business logic and persistence schema). These are understandings that've been long (and sometimes painful) in the learning, but they're pretty much universal.
Survey monkey is completely broken without js. I did a survey this afternoon on it. Considering it looks like a few radio buttons and simple forms.. I just don’t understand.
How so? One of the most popular (if not the most) websites for developers out there is pretty much HTML + CSS. JavaScript is used, but minimally.
"Modern" experience is not necessarily the same as "good" experience. Good old server side rendered pages are fine; SPAs are being built just because "we can", not because they are actually needed (sure, in some cases,SPAs are needed, e.g., chat sites).
Are you talking about Reddit, StackOverflow, or something else?
I have yet to see a proper web app (not a blog/collection of static pages, but something that does something complex like let you manage inventory, do payroll, do your taxes, monitor sensors in real time, interact with geographical maps, or edit documents) that is done without JavaScript and has even OK UX.
SPAs are great because of separation of concerns. Sever takes care of the data (storing it, syncing it, authenticating your access to it, serving it, sharing it). Client takes care of presentation. I build SPAs because they are better. Imagine if all the apps on your phone or computer were effectively HTML documents rendered on the server. Emacs over HTML/CSS? Minesweeper? World of Warcraft? Would that be an OK experience? Probably not because you don’t want to wait for a page load every time you do something in your Minesweeper game or check stock prices or whatever. Why should web apps be inferior?
When people complain about SPAs it’s because they don’t like web apps running in the same environment as their document-based content. I guess some people prefer the ActiveX/JavaApplet model, which to a degree I can understand. Slack is an application, not a website. But let’s not overlook the fact that implementing a Slack client with just HTML and CSS would be miserable to do and miserable to use.
I'm not going to call your statement nonsense but unless you have proof that SPAs make up the majority of the websites/web apps online today, I'm afraid I must disagree.
Frontend dev is a hot mess of garbage JS cobbled together to make a psuedo native experience.
> but something that does something complex like let you manage inventory, do payroll, do your taxes, monitor sensors in real time, interact with geographical maps, or edit documents) that is done without JavaScript and has even OK UX.
This is not what the web was built for. The same things you mention dismissively (server side
Static pages) are the core and norm ,by and large, the vast majority of what constitutes "the web"
Good, lightweight native apps can do all the above without breaking a sweat, and you can have multiple native clients for things you care about. I don't always have an internet connection but I still want to type my documents. I fire up word. Not google docs. I need to do some serious data wrangling - I fire up excel not google sheets. Need to do some networking for my router, wireshark. Need to read an ebook - adobe acrobat. Need to write some shader code - Sublime text.
So the way it looks to me that SPAs are trinkets - not at all mission critical beyond loading cat pictures faster or bending the web backwards to do things it wasn't supposed to. Server side static pages rule the web.
Complexity is just a good way to justify a large paycheck.
I’ll give you two counter arguments and if they don’t work I think our best bet is to agree to disagree. First, I think your premise that apps are not what the web was built for is flawed. Sure, this isn’t what the web was built for, same as the Internet wasn’t built for the web, and the phone and cable lines were built for the internet, and so on. The web had a vision that changed mid way. No we can either try to go backwards and give up a really important feature (forthcoming) or we can move forward and push past what is essentially a tooling problem. In other words, just because in the 1980s web apps could not be envisioned does not mean that they shouldn’t be envisioned today.
The second argument is that there isn’t a technology today that supersedes the web in one crucial feature: no installation required and updates are transparent. Various app stores are trying to solve this in a platform specific way but do you really want to live in a world where to publish an app you must include Apple and Google and Microsoft in your deploy path? You and I may be able to go to GitHub and download OpenStreetMaps code, then download all the data, install it all locally (most of the documentation last I checked was still in German BTW), and then use it to find directions to the nearest Starbucks. An average user will give up before spelling out “GitHub”. If you can point at any platform that lets me type in the name of an application and stat using it in under 1 second without installing anything whatsoever on my system, I will eat my hat.
That isn’t to say that we can’t have nice things. With time and effort you can create such a platform and get all OS vendors to support it and all the developers to move to it. But I will postulate that fixing the JS frontend mess will take at least an order of magnitude less effort. Therefore the web is where these types of applications will live.
Again I am not talking about things that are static. This isn’t about a blog. This is about whether a real application is better server-rendered or as an SPA and I argue that in 99% of cases an SPA will be a cleaner architecture AND provide better experience to the user. The fact that coding one up is annoying (arguable at best) is a temporary tooling problem, not a fundamental design flaw.
I'll use an analogy. We web developers are building a boat using a 1992 Toyota Hilux as the hull.
Top Gear proved it was well and truly possible. It's a popular mode of transport. It carries things. It has an engine and a mostly metal body.
It still isn't quite a boat
Web apps can walk and talk like native apps, but they aren't. Sure one off things like a Facebook or spotify or meme generators can rightfully be served from a web app - but applications for computing and getting work done?
Oh and don't forget about mobile devices - what amount of web apps do you prostulate people use there?
> SPA will be a cleaner architecture AND provide better experience to the user.
I won’t debate your analogy because I think it is flawed for reasons such as you can’t change the fundamental definitions of a car as easily as we can change web standards, as we have done over the past 30+ years.
I will point out that I routinely use Reddit on mobile Safari and it is most certainly a web app. Things like Twitter, Facebook, etc. are also apps, and while you can download a native version, for privacy reasons I prefer their web app counterparts as they are less able to spy on what the rest of my phone is doing.
I will also again point out that Google Maps is a better experience than downloading OpenStreetMaps and setting it up yourself. Even something like Slack and Discord and Google Docs are perfectly good experiences on desktop browsers and require no installation whatsoever. You aren’t really addressing the zero installation point at all and that’s at the crux of why web apps are a thing and their main draw. You quoted my conclusion and called it nonsense without any basis since you provided a straw man argument and didn’t address the main point at all.
You can build a poor UX with either technology. That does not to me condemn the technology itself. If a technology makes it easy to create a bad UX that may be grounds for condemning it. I have written horrible SPA code in my early career using nothing but straight up jQuery and yeah that can lead to bad UX. I like the way Vue does things and liked the way Angular 1 worked pretty OK. I don’t love React but don’t have anything against it. None of these inherently lead to a bad UX, IMO.
