The web is mostly links and forms(gomakethings.com)
gomakethings.com
The web is mostly links and forms
https://gomakethings.com/the-web-is-mostly-links-and-forms/
20 comments
This is most fluff article I read in recent times. Take one line, repeat it differently 8 times without adding anything and you have the article.
Non-article teasing an HTMX tutorial if you sign up to their newsletter?
dog, Google Docs is not a website, its core functionality requires javascript
introducing the new utility, 'hed'.
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!
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!
My understanding is that the author is saying you could build google docs to go from one state to another by submitting a form and doing server side rendering returning the entire webpage of the new state. This is obviously much worse user experience and way less efficient, but I guess it technically would work.
>My understanding is that the author is saying you could build google docs to go from one state to another by submitting a form and doing server side rendering [...] This is obviously much worse user experience and way less efficient,
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/#....
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/#....
You could do everything a computer does with a turing machine
A Turing machine can't use the internet, nor can it do things like play music or watch videos.
A turing machine could simulate all of those!
> Google Docs? A website
> 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 :)
> 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 :)
I agree, with one caveat - the web is links, forms, and styled components.
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.
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.
Are markup/styling issues why people are reaching for react components? I would think of state and logic management being the main point of difference. Most markup and style classing I see from react projects/packs is not great, but they tend to “just work”, at least for specific use cases
Yep! Picture this from the engineering or product manager's point of view (especially in the case where it really is simple, and the app is links and forms with a consistent look and feel.)
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.
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.
Life is mostly carbon, hydrogen, oxygen and nitrogen. The arrangement and the bits of other elements turns it into much more than the isolated components.
> Google Docs? A website. Accounting software like QuickBooks? A website. Discord and Slack? Websites. Apple Maps? A website.
Can you expand this sentence a bit? Thanks
Can you expand this sentence a bit? Thanks
The web is mostly we care for your privacy form modals concealing the buy me a coffee link buttons.
I did a cartoon double take when they said (paraphrasing) "Google docs can be run without JavaScript"
Right with that well known html tag built into all browsers.
<MultiUserRealTimeOfflineCloudSyncDocumentEditorWithPDFAndDocxSupport />
It's been in the browser for years. Wake up sheeple.
Right with that well known html tag built into all browsers.
<MultiUserRealTimeOfflineCloudSyncDocumentEditorWithPDFAndDocxSupport />
It's been in the browser for years. Wake up sheeple.
Let me summarize the web for you. You have static websites and dynamic ones. It's a UI for the filesystems of every computer with a domain (abstracted ofc so people can make sense of it). Lately, there is this trend where you have a way to interact with dynamic websites (usually a database, [still a file]) using forms tables and routing (links).
Code?! Still files. The end.
and porn
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.