481–490 of 605 posts
I've tried this before and I think this constraint is something that has to be kept top of mind for a designer not just the engineer. Most designs these days assume a single page app and there are interaction patterns that make plain HTML not suitable. But if you incorporate this in from the start and stick with it, there's no reason you can't do this.
Earlier quoted context omitted.
I used to think that was true but I now think it’s only true for very interaction-heavy apps: if you have hundreds of interactions on a page over many minutes, using an SPA is amortized across a lot of time, but if it’s something you could do with e.g. a simple Django app you’ll not only be done faster but will spend an order of magnitude less time on maintenance and accessibility work.
That's usually not even in the books of a typical SPA: It doesn't have fallbacks at all, and just shows a blank white page. Accessibility is always taking a rear seat with such SPAs.
Earlier quoted context omitted.
Starting a few years ago, I realized some junior and medior engineers never once considered the possibility of building a website (app, experience, etc.) in anything other than a heavy SPA framework. But they're not stupid people! If you directly asked "Can you build a website without React?" they know the answer is obviously "Yes." However, if you asked them to build a new website, they would unthinkingly start a ne…
In the olden days, people wouldn't take office jobs or factory job necessarily because they thought: "Yes! That's my passion! That's exactly what I've always wanted to do." Passion isn't your first and foremost thought when you have a family to feed. A few decades ago, IT jobs were for the most part done only by people who were in it for the kick they got out of working with computers. They already hacked at their da…
Not me, if they want shit I give them shit. I used to care 30 years ago, but they beat it out of me. Now its all for the money, HODLing to retirement.
Old people. They exist. Not even that old. 60 year people can't user your fancy site because then don't have an internal model of how a computer works. You know that when pressing a button a hidden engine runs in the backend (or something runs in the backend). You expect an answer and if the expectation do not match the result, the model in your mind creates an hypothesis about what maybe happened and iterate from th…
Many developers are unaware how many people are not comfortable with computers.
Here's an example with my dad, 64. During Covid, he had to get his medicine by emailing his GP instead of going to him. He received the email address as a photograph of a piece of paper over WhatsApp. (Clearly the doctor wasn't comfortable with tech either.) The paper said:
Send your medication request to:
- john.smith@some.long.medical.site.org
He said "I tried everything: lowercase, uppercase, spaces between '.', no spaces, space between '-', no space... Nothing works!"
He thought "-" was part of the email address. To some people it might seem like he was being dumb, but he's never had to seriously use computers before. When he bought our first computer he was 38 and never used it. He got his own laptop at 46, and only used it for movies and Skype, before WhatsApp existed. It doesn't seem that odd to know how email addresses work. (He is a technical person, but not a computer person. For example, decades ago he etched a circuit to make an HBO decoder so we can watch HBO for free.)
Earlier quoted context omitted.
Well that's horribly reductive. I certainly do not expect everyone in a given field to know absolutely everything there is to know in that field. Crazy enough, I also hold doctors and surgeons to higher standards than web developers.
If those web developers fail a critical government service, or online pharmacy or financial service, it can mess up peoples life pretty badly as well.
Much like how relying on a resident nurse instead of a cardiologist when you are experiencing a heart attack can end your life pretty badly as well.
As a non-web dev, I have a question about this part: > There was a sad coda; as is the way of contract work, I moved on. I explained what I had built to my replacement, that it always worked even without javascript. He was appalled and said, “but that’s a lot more work for us.” Why is it more work? The approach described in the article seems honestly reasonably simple: just write the standard components for the form,…
A lot of developers have made or just perceive very strong silos between frontend and backend today. Any coordination that needs to happen between frontend and backend is potentially a communication challenge. It seems like a lot more work because you have to keep the backend and frontend in closer sync. The backend has to be aware of and able to store every sub-form in the full process (which sounds like a "wizard f…
Then they just validate on the front end, and we validate on the backend.
As a non-web dev, I have a question about this part: > There was a sad coda; as is the way of contract work, I moved on. I explained what I had built to my replacement, that it always worked even without javascript. He was appalled and said, “but that’s a lot more work for us.” Why is it more work? The approach described in the article seems honestly reasonably simple: just write the standard components for the form,…
that menu is maintained manually, and every time a page is added, all copies of the menu have to be updated. at some point that will get tedious. then i have a few options:
i generate the menu using a backend framework. the downside: the website is no longer fully static. i now depend on a backend framework for hosting. static hosting is out. i also have to edit the content through the backend, and i have to continuously maintain the backend for the lifetime of the site.
i generate the menu using a static site builder. the downside: i can no longer edit the content directly in html. i have to keep a source version for the static site generator, and more critically, i have to keep a copy of the site generator in my repo because i want to be able to make changes to this site 10 years from now and not find that the version of the site generator i was using is no longer available for download and my source is not compatible with the new version of the site generator.
i generate the menu using xslt. works, but xslt is no better than javascript security wise. it's possibly even worse. and xslt support may be removed from browsers in the future.
the final option is javascript. using some framework that doesn't need build tools, or something homegrown. i am afraid javascript is the only option that is futureproof while letting me avoid manual work to maintain the menu.
As a non-web dev, I have a question about this part: > There was a sad coda; as is the way of contract work, I moved on. I explained what I had built to my replacement, that it always worked even without javascript. He was appalled and said, “but that’s a lot more work for us.” Why is it more work? The approach described in the article seems honestly reasonably simple: just write the standard components for the form,…
Starting a few years ago, I realized some junior and medior engineers never once considered the possibility of building a website (app, experience, etc.) in anything other than a heavy SPA framework. But they're not stupid people! If you directly asked "Can you build a website without React?" they know the answer is obviously "Yes." However, if you asked them to build a new website, they would unthinkingly start a ne…
Most of my apps are now simply HTMX + Go + SQLite. I've found it's enough for most projects. One of my sites is image heavy and serves 10 TB of traffic per month. For this, I use the following setup: 1. S3 (I wanted reliable data storage) 2. In front of it, I have Cloudflare (with Tiered Cache enabled, which makes POPs prefer pulling from Cloudflare rather than the origin). I've set rules to cache everything on both…
> I wonder why there isn't a mobile OS that simply lets you build apps with JavaScript, HTML, and CSS and gives you reliable storage without all this effort. There is! You just have to time travel all the way back to 2009 when webOS was launched by Palm. Time travel is the easy part, you then also need to somehow prevent Palms demise and webOS fading into obscurity as a smartphone OS. If 2009 is too far back you can…