The web is mostly links and forms(gomakethings.com) |
The web is mostly links and forms(gomakethings.com) |
Many things on the web are not interactive at all (news, blogs, shopping) or have almost no interactivity (forums). These things could just be HTML with a sprinkle of JavaScript for some flair like it's 2002. Ironically Facebook falls into this category; almost nothing on their site needs to "react" to anything (except to spy on every mouse movement you make, obviously).
Something like tax forms should probably be xforms in a better universe. It's literally a form, but some fields might be calculated from other fields.
A word processor as a web page is a funny technical demo, but it's mostly an artifact of how Windows and Mac didn't have app repositories for 20 years (still basically don't? Idk). There's no way in hell that it was easier to use JavaScript and CSS to make a cross platform UI than something like Qt, especially at the time.
I get a chuckle whenever people talk about "supporting dark mode" like that's a modern feature. You used to be able to set your color palette in the OS settings, and every program had dark mode by default (this still works with native apps on KDE at least). It would be a lot less work for web developers and make for a better experience if the browser just respected that preference for default page styles, and then web pages/apps used canonical style names to access that palette, but here we are.
hed ("HTML ed") is the standard CGI text editor! hed, the greatest in-browser editor of them all! hed, which requires only HTML 2 forms, and is compatible with every browser since November 1995! hed will not eat your RAM, hed will not serve you ads, hed will not RowHammer your secrets through the JS virtual machine! Simply type your commands into the form to edit the text on-server.
The CGI errors are terse, yet forgiving, and do not overwhelm the user with spinning beachballs or arcane browser-console CORS errors.
hed! the standard CGI HTML text editor! HED. Do not give in to giant janky masses of Javascript spying on you and losing your keystrokes. HED. Accept no substitutes! HED. Near-infinitely scalable due to the extraordinary performance of text-only operations. HED.
HED HAS SPOKEN!
Your interpretation of "much worse user experience" is the opposite of the "work well!" that the author is claiming:
>Every single core function of these apps could work—and work well!—without a single drop of JavaScript.
https://gomakethings.com/the-web-is-mostly-links-and-forms/#....
> Every single core function of these apps could work—and work well!—without a single drop of JavaScript.
...what? I'd really love to live in a world where we could deploy an app like Google Docs or Discord without JS but that's just not the reality.
> Most of what we build is links from one page to another, and form submissions that send data from the browser to the server.
I'm not sure who the "we" being described here is, but it doesn't really describe the day to day of the web engineers in my circle.
My cynical guess is the motivation for this piece is more rooted in advertising Chris' bootcamp and consulting services than it is sharing earnest expertise.
>Discord-like apps have existed since before JavaScript did. Back in the 90’s, chat rooms where literally form elements that you typed into. You’d submit to the server, the page would update, and your post would be displayed. If you wanted to see new posts, you’d refresh the browser.
I don't think this is the kind of thing I'd want to hear from someone I paid to improve my website :)
It’s the styled components bit that makes everyone reach for react over ERB/HTMX/whatever. Web components wants to solve this but the API is just not there yet for smaller teams.
I think people who want simplicity are on a great path, but without addressing how bad the intersection of CSS and HTML frameworks is compared to React & friends, it’s an uphill battle.
Can you expand this sentence a bit? Thanks
Right with that well known html tag built into all browsers.
<MultiUserRealTimeOfflineCloudSyncDocumentEditorWithPDFAndDocxSupport />
It's been in the browser for years. Wake up sheeple.
Imagine a split for a Rails app (like what was common in 2000-2010) where you have
- Backend engineers managing most of the logic in ERB templates
- One designer-turned-frontend guy who is deep on HTML/CSS/JS, spends most of his day writing CSS so the backend engineers don't have to
CSS, even for people deep on it, is not very fun. It's especially not fun if your backend devs control the codebase where you can actually define the HTML tags that make up a component. So a really common situation was
- Designer-turned-frontend guy burns out, or wants to transition into pure development
- You have a hellish search for their replacement, since the pitch is "seeking a person who is interested in a low terminal IC position, is interested in the least fun part of web tech, and whose hand will be slapped if they dare to touch the backend engineers' code." In practice once you lose that one guy, you have months of a gap before you find your CSS expert again.
- In the meantime, you have a workforce that doesn't get why look & feel is important and stakeholders who can't understand why no one can put polish on any of their new GUI features, despite building a GUI.
SPAs made this much, much easier. Now, frontend devs
- Have full control over the structure of a component for styling
- Don't have to get the backend devs' permission to change things they know they need to change to style things correctly
- Can make reusable components with the same styles, allowing design systems to take off in ways they didn't before
- If the person wants to branch out and get more programming experience, some of the logic is on the frontend too. The job isn't "all styling, all the time, leave the logic to the other teams" and there are areas to show skill. Retention is 10 times easier and there are fewer key people who can never take a vacation.
- And critically - you have a team for whom look and feel is not an afterthought, with the power & ability to make code changes. No more explaining to stakeholders why buttons look totally different page-by-page and why the team can't be convinced that consistent branding is important for businesses.