This is SO close to the solution I need. If I could configure this form using typescript and then send them a link where they can't see or edit the typescript, but just fill out the form and send me the JSON, that would be incredible!!
No doubt. But do I need an app to read the information delivered by the website. I use the web as an information service.
curl -s -A "" https://jremissing.com/api/episodes|(tr \{ '\12';echo)
Sorry but I see no need to enable Javascript for reading text.Of course, the Ads by Google component of the page does require Javascript. For ads/tracking, one does need to enable Javascript.
But I really don't get the point of your comment. It's 2022. If some people publish work that visualizes information for all of us, I'm glad they have Javascript helping them do it.
In a Japan of today, you grow up with a plentitude of words taken from English and written + pronounced in Katakana. So you learn to pronounce "san-do-i-chi" for sandwich, "de-za-i-na" for "designer", "su-ma-ho" for smartphone, "ca-re-n-da" for calendar. And since you use and pronounce them wrongly on a daily basis you reinforce the Japanesified pronunciations. Then, actually pronouncing "calendar" in an English way becomes tricky.
So to me, the alphabets are a great example of a "historically grown" system, that's ripe for a "refactoring".
Most SaaS companies are just that: 1) Curated domain model (stored in their cloud db) 2) Some way for users do to almost raw CRUD on the tables 3) Curated high-level domain specific workflows that do n CRUD calls underneath
So many of these SaaS apps could have been a simple Excel / domain model template like Micasa.
But it seems like we haven't "cracked" the perfect UI on top of relational DBs.
Excel: Good: raw CRUD. Bad: too many degrees of freedom + the possibility to edit the domain model itself. That's too much for most users.
TUI: Good: raw CRUD with some guardrails, limited possibility to adjust the domain model / not by accident. Keyboard shortcuts, for professionals. Bad: inaccessible for non-tech end users + hard to build good UX for high-level domain specific workflows.
Full Web UI: Good: accessible for all. Great for high-level domain-specific workflows. Bad: looks and works different every time. Raw CRUD possible, but always a compromise with editable data grid libraries.