It's genuinely fascinating to me how many professional web developers these days - smart people who produce good work - don't know how to build interactive features using HTML on its own (and maybe don't even know it's possible).
Being able to do things like this is really useful:
I've seen teams estimate a full day to add a link to a contact form because they need to refactor a bunch of React components to achieve that. I like being able to do this:
I worked with a team of developers tasked with creating a few 100% static websites. Single page, no interactivity, nothing dynamic. They were talking about which React components to use, server APIs to build, etc when I asked why they didn't just write HTML or use a static site generator and host the page in S3. They didn't know how to write vanilla HTML, they had never used it for more than bootstrapping a React app.
I'm still fascinated by a website linked on HN some time ago that was written in MarkDown, but then not translated to HTML and served, but sent as MarkDown along with a JavaScript renderer that would then translate and render it on the client. Sure, it works, but why?
(As a marginally related aside, I've recently spun up my mother's old 12" Powerbook G4 from 2005 or so. It worked fine and was reasonably fast and snappy (for a HD based machine), except when I opened the browser. A few tabs brought the machine to a standstill. Goes to show how much crap is on the modern web.)
Writing good HTML is not what employers, hiring managers, HR, and resume algorithms consider to be a skill worth paying for. You gotta know React or GTFO. From the perspective of a newbie developer, why waste time learning the grandpa way of making webpages when React can do all the things?
I'm not saying that situation is ideal. Most of the web should be less JavaScripty.
Yes, but remember: static HTML is a one-way street. Better tell your manager otherwise they will one day come up with functionality that can't be done in your website and it's your fault.
EDIT: For example: manager/designer wants to add an assistant to the website; it should be draggable; it should also animate and keep animating smoothly no matter where the user navigates on the website. If your website is a SPA, this is conceptually easy. If your website is static this is going to be a nightmare and suddenly a simple change requires lots of work.
It's frustrating the lack of simple tooling out there for static site generation. I have had to write bespoke static site generator build scripts just to get things working.
Everything is React and SSR these days - like people please - it's not that complicated. TypeScript is an acceptable amount of overhead. Use React only if you absolutely need it and even then, use it super carefully because it has no seatbelts.
Petite-vue is a nice middle ground for 99% of websites and I am sad that this approach (templating) to build dynamic content doesn't have more investment.
As the old man screaming at the cloud, about the insane complexity of modern JavaScript frameworks, who hasn't done much with them and kind hates the experience of dealing with them at all, I hope you are right.
Can I still use my basic HTML knowledge and be productive? I've instead just given up doing any frontend work because I don't want to spend my time in React. Give me something simple, concrete, and understandable like an advanced algorithms textbook, and I'll go to town. Reading user guides or documentation of Typescript/Javascript frameworks feels impossibly hard in comparison.
Core Front-end Team (we are currently full, check back later)
- Passion for creating delightful and swift user interfaces.
- Proficiency in HTML, CSS, and an understanding that JavaScript can be used sparingly to enhance, not create, product experiences.
- You are comfortable not using any FE frameworks, and rather like to be in full control of the DOM and as close to browser as possible.
Fun fact: At Kagi, we prioritize speed, to the point where all functionalities of Kagi Search (except Stripe checkout and Maps) work perfectly without JavaScript. We see JavaScript as a tool to enhance the UX, not create it.
I can't think of any job postings I've seen recently that only wanted straight-forward web development. Everything was asking for a major framework + other supporting libraries for the front end. I'm only 40 and also screaming at the clouds, but I simply don't have the luxury of ignoring some of the larger things like React that gave me a job today.
This is the market pressure which is driving things towards more abstraction. Another iteration will add more abstraction on top of that. I'm fairly certain it can't be stopped now. Doing so would mean convincing tech leadership to start actively managing what technologies go into their products and striving for a "less is more" or minimalism approach.
Working with Turbo and Stimulus with Rails is such a breath of fresh air for me for this reason. Sure its not just writing HTML, but its such a vastly simpler framework for creating a responsive web page than React, Vue, Angular, etc. I don't know how React and the like became the de jour of Web development, its quite a complicated beast. I am partial to DHH's interpretation it was off of zero interest rates and free money.
I totally agree. It's like we've forgotten what browsers and HTML are meant to do.
Back in the day we used to rail on Flash websites because while they looked nice, they weren't accessible to screen readers etc, sites weren't consistent, links didn't turn purple, and the back button didn't work.
I don't think that's an exact analogy....maybe if you're using react in some oddball/low skill way. Flash (and ...javafx/applets/whatever the id equivalent was...I can't remember) were 1000x more bumpy than react.
React and similar frameworks are still generally better for accessibility compared to Flash, but at the same time can be worse because pages may behave sporadically and in unexpected ways, whereas Flash would be a blindspot for many screenreaders and related software.
I strongly encourage new junior hires to read MDN, specifications, etc. However, for some, it is like they cannot absorb information if its not in video format.
I'm frustrated at how often a how-to for something that takes three sentences to explain is a video. At the same time, it's amazing for things like simple home and car maintenance.
It doesn’t take a day to do it. It doesn’t even take a day with refactoring. But add in writing the tests, running through QA, code review, getting release approval &c &c and almost anything can take a day.
It looks all these rants are from people who need "Hello World" equivalent of web and are angry that there are tools for more complex use cases. I am primarily a backend developer with couple of decades of experience, who is now working on his own startup. I have built a simple HTML/JS site as our launch page. But I would kick out anyone who'll suggest that we should use plain HTML/JS instead of a frontend framework for our main app.
A form submission is not just a post submit. You have to do client+server error handling, dynamically show/hide/add fields, show char count, handle intermittent state and still more. All of these are possible with JS but is faster and more reliable with a purpose-built library. Same goes for a draggable dashboard, filters for search results...
It's because submitting a form interferes with all the other stuff running on the same page. E.g. after submission animations stop or disappear or skip a frame, annoying designers, etc. etc.
It's not always the right tool but in more cases than modern devs believe, it is.
I've built several web applications recently that don't use any modern JavaScript framework. You'd be surprised how quickly a page can fully reload and equally surprised at how okay of a UX it is to not always persist state.
I don't think there is really anything in your "etc. etc." I have never heard from any real user a complaint about animations stopping mid-flow. I think people know how pages work, in that I think they expect clicking things to do something disruptive, altering, changing. It's only been the design astronauts that have argued these discontinuities are "confusing" to users.
If anything, sometimes I think they make the transition too smooth, to the point that it can be possible to miss it. Sharp changes are generally easy to notice.
The sites that genuinely need a react frontend are fewer than the sites that use a react frontend. If you forgo react from the start, you have simplicity. At most, track your "state" in a session cookie + "rendering" on the backend. The good old days. I miss them.
Only one day? They must be juniors, that's at least a month or two - few hundred story points, dozen alignment meetings, QA, stakeholder buy-in, A/B tests, security consult, PM/PO/SM/EM/TL sign off, heck just catching up with the UX team alone would add a day's worth of calls.
> I've seen teams estimate a full day to add a link to a contact form because they need to
Has it ever occurred to you that maybe it only takes them 15-30 minutes (still too much, obviously) but that it is great to be able to only work 15 minutes/day?
Estimates reflect what managers will say ok to, not how much real work it takes.
this is why I dislike the modern web so much. I love to find websites that are nice and simple, load fast, and have no JS bullshit to render "modern" UIs. But yeah, old man yelling at cloud and stuff... but you know what, I'm fine with that. And I do have the hopes of building something useful and successful that gives the middle-finger to all these "modern" frameworks.
An underappreciated reason people pad estimates is that it gives them some time to breath and know what business goals they personally need to deliver.
In the case of 1 day to add a button, let the developer have a day of knowing "today, my goal is to add a button". Without the padding the developer would be thinking "I'll add that button, but after that I have no idea what's coming, whatever bullshit comes down the pipe I guess".
It's really hard to shift mental gears. People can do multiple tasks well, but only if there is a coherent thread they can follow through those tasks. Current software management philosophies are very hostile to those coherent threads.
I don't do web stuff for a living, but I've been hacking since the early days of JavaScript - what I don't understand is what happened to separation of content, layout and interactivity - most of these react et al. monstrosities start with a big mess of JavaScript generating the html as lisp-like nested trees of tags. in that case, why not just use lisp?
woah! i couldn't agree more. i built my own router for React because i was exhausted by having every link be some overly heavy abstraction around... a few characters of text. KISS is key for me.
The complexity makes automated testing easier. We arrived here for reasons that may or may not not be critical to you but warranted implementation nonetheless. There is no conspiracy.
I often help younger developers with problems that involve absolute vs. relative paths - their code doesn't work because they're invoking it with the wrong working directory. It's immediately obvious to me because I grew up using the command line, where files and paths are elemental. They're usually _really_ interested in properly understanding what's actually happened here, but they've been so intentionally shielded from the fundamentals of files and directories that they need quite a bit of time to let it all sink in. The solution, of course, is to teach things bottom up, but I have some sympathy for beginners who lose patience with spending so much time dealing with something that doesn't even _look_ like a computer from their perspective.
It has been very eye opening watching young and brilliant programmers who have grown up with mobile devices struggle when it comes to traditional environments. Many struggle with things that seem basic, like file systems, processes, memory management, how to use desktops and even mice, etc. However, once you solve or abstract away those things, many are able to churn out complex software at an impressive rate, particularly when they are able to assemble tool chains and frameworks together like legos. Then they go back to the struggle bus when something in that chain fails or functions unexpectedly.
Differences in the types of environments and how they interact with them between age groups makes sense in a pretty boring sort of way, and at any rate is solvable through simple experience. It’s more interesting to me that this observation is another point of correlation in the notion that the industry has aligned itself with productivity over any other metric. While productivity is important, this unbalanced favor has introduced fragility and unsustainability into the industry and end user market.
So much of the modern computing environment goes incredibly far out of its own way to hide information from the user. It's getting difficult just to see the URL in mobile browsers, and in some fairly general-purpose computing environment (iPads, etc) the concept of a "filesystem" has become very abstract and increasingly difficult to ascertain.
It doesn't surprise me that people half my age have difficulty with some of these - it's much harder for them to play with and explore the concepts.
I see kind of a mix of wonder and frustration - I don't know if I'm projecting, but I kind of suspect they're secretly accusing me of making things seem more difficult than they need to be.
1. Every generation of programmers typically only has a certain window of knowledge, and everything before their time is simply foreign to them. Most developers aren't programming history buffs, they don't read books from the past to learn about technologies or how they work, how we got to now, etc.
2. When you're starting off on your journey as a programmer you're using a lot of things without understanding their implementation, and that understanding for most individuals whom I've worked with comes from having to debug issues.
> Every generation of programmers typically only has a certain window of knowledge
That's true, of course, but I think the disconnect he's pointing out is: a) deeper than that and b) new. I grew up a ways before he did and my first serious computer was a commodore 64. Like his 286, there was nothing you could do with it _except_ program it, and programming was hyper accessible. I immediately understood C's pointer syntax when I first came across it because the only way to show graphics on a C64 is to write to a specific memory address and the only way to intercept keypresses is to read from one.
Fast forward to the 21st century. My son is a smart kid - graduated valedictorian of a competitive high school - but he grew up with "computers" that hid the programming interface down so far that most of his experience with actual programming has been through emulators so the whole thing feels (and is!) artificial. He still struggles differentiating between what's "real" and what's emulated and I can tell from interacting with other programmers his age that he's not alone.
The GP's point is more general and stands. Technologists inevitably start off "in the middle" of a stack of technologies, and then choose to dig down and/or build up from there. It is inevitable that newcomers will not understand the technologies upon which their current work rests. A certain fraction of those will become fascinated and drawn to understand the underpinnings of their work, for an edge, or for the love of it, or both.
This process happens more naturally over time if you grow with the technology. For example, if you started programming with HTML in 1995 you not only have ~30 years of experience, but you've also seen the changes as they occurred, and have a great deal of context about the how and why each of them happened. That kind of experience can only happen in real-time, unless some kind soul is willing to write a manual to help newcomers speed-run it. Such a manual is often called a "textbook".
Dude/ette; pointers WRECKED people's minds (myself included) when we learned about them in CS101 (modified for computer engineers) in 2006. I don't know why either; they make so much sense.
I think people just focus on problems entirely within their own domain and rarely branch out to anything else. The amount of times I've had to explain to senior devs of 20+ years how DNS works at a very simple level would astound you, which is something that I would assume should be picked up if not by learning, through sheer osmosis, but you'd be surprised. If you lack a formal education, and maybe went through a bootcamp - which there's nothing wrong with - you may not know a lot of things that would surprise this author.
I wonder if every generation is doomed to feel this way. Socrates was horrified about the corrosive effect of reading upon young people's ability to memorise speeches. Plus ca change etc.
On the other hand, as the guy on twitter recently said, "it's not fair that I spent my childhood teaching my parents to use a printer and as an old man I'm spending my old manhood teaching my adult children to use a printer".
My older relative is complaining that their working life roughly coincided with the time where computers became mainstream but were still hard to use, and now that computers have become easy to use (think smartphones and tablets) their (the relative’s) productive days are more or less over and all their hard-earned difficult computer knowledge is becoming obsolete. So they were the generation that had it hardest, because they had to deal with computers (unlike earlier generations) but had to do so before computers became easy to use (unlike later generations).
To be fair, "reading" in Socrates' time was viewed as social media or Netflix is seen today. Mindless entertainment. There was more of an emphasis back then to focus on a few solid works, memorize and really chew on the content and not consume religiously.
To some extent I'm sure the answer is yes, so I think the operative question is not "Are kids learning what I learned?" Instead it has to be something more subtle.
Perhaps "Is kids' knowledge broadened and deepened by the media they consume?" more generally would do. It allows us to evaluate extent, change, and appropriateness more broadly. Not just the accessibility of a given topic, but how readily one can dive into the details and truly learn something.
The landscape of media then can change, but this question does not react to any and every change in the landscape the way a nostalgic argument does. Socrates would have no reason to worry; a book can broaden and deepen knowledge, too. Are we?
Agree to some context. Maybe every generation we have 'why is this thing so hard', so html/css was hard. I think in early 90's, one might say so hard with styling issue due to lack of standardization (page layouts and hacks needed to ensure working on all major browsers). Then there was Flash, jQuery. Now plethora of modern stack __how__ we do this and with magnitude more features.
If you don't need the features, React isn't an abstraction over HTML, it's a complication. Plus CPUs aren't getting exponentially faster anymore - that is a real game changer.
I’m a new developer (2-4 years experience, all self taught) and I get what they are saying.
I obviously have gaps in my knowledge (started with Python, moved to frontend). Frontend is too abstracted from actual CS.
But I actively take University papers in my spare time on CS, and do C in my spare time to appreciate the lack of abstraction in low level code.
I really enjoy this (learning and C) more than economic programming (frontend, web, career).
I just love learning and realising how little I know. The latest thing I’ve learnt is that structs can have holes, and struct packing for situations where you need specific address offsets. Made my own bitmaps from scratch etc.
The Jblow and Muratori rants are contentious. Try arguing for formal methods some time.
The industry has had enough time to expand to include many different zeitgeists. I find myself smirking when I read old ewd essays decrying how programmers then didn’t understand programming. Seems like we’ve continued down that path.
From my part of the pond you’d expect the Computer Science questions to cover areas of combinatorics, abstract and linear algebra; satisfiability, search, and the like.
But we are talking about a pop culture type of show and what is the most popular form of programming today?
I would really like to try writing something along the lines of “the web from scratch” one day. I wouldn’t want it to be just a retelling of the history of the internet, but rather building up a set of abstractions from some physical example of communication to your own mental model of a hypertext standard on top of a simple transport protocol, sort of like Charles Petzold’s Code.
The web is complex nowadays, but it also actively hides its implementation from you to be a better product. Dialing a phone number with a modem on both ends has a sort of real tactility to it that’s pretty alien to young people that expect it to be “harder”. You can pick up the phone on the line and hear that something is going on. The computers are “talking” on the phone.
A metered Internet connection means I was constantly aware of how much data is going over that phone call. What takes huge chunks of that budget and what barely touches it.
My ISP even gave our family some web space to use. Like just the peek behind the curtain you get from putting a file on an FTP server, then requesting it in telnet and seeing every letter I typed zip in from the other side really illuminates a lot. If I ask the computer I called for a file in a special way, it sort of shouts it back at me over the phone call, and my computer can listen and understand that.
It’s not like it was the best implementation of the “product” that is the Internet. Anyone saying the contrary really is an old person shouting at a cloud. But I do have some sense of being lucky to get to explore the web in that era!
Readit News
Being able to do things like this is really useful:
I've seen teams estimate a full day to add a link to a contact form because they need to refactor a bunch of React components to achieve that. I like being able to do this:(As a marginally related aside, I've recently spun up my mother's old 12" Powerbook G4 from 2005 or so. It worked fine and was reasonably fast and snappy (for a HD based machine), except when I opened the browser. A few tabs brought the machine to a standstill. Goes to show how much crap is on the modern web.)
I'm not saying that situation is ideal. Most of the web should be less JavaScripty.
EDIT: For example: manager/designer wants to add an assistant to the website; it should be draggable; it should also animate and keep animating smoothly no matter where the user navigates on the website. If your website is a SPA, this is conceptually easy. If your website is static this is going to be a nightmare and suddenly a simple change requires lots of work.
Everything is React and SSR these days - like people please - it's not that complicated. TypeScript is an acceptable amount of overhead. Use React only if you absolutely need it and even then, use it super carefully because it has no seatbelts.
Petite-vue is a nice middle ground for 99% of websites and I am sad that this approach (templating) to build dynamic content doesn't have more investment.
Can I still use my basic HTML knowledge and be productive? I've instead just given up doing any frontend work because I don't want to spend my time in React. Give me something simple, concrete, and understandable like an advanced algorithms textbook, and I'll go to town. Reading user guides or documentation of Typescript/Javascript frameworks feels impossibly hard in comparison.
https://help.kagi.com/kagi/company/hiring-kagi.html
"""
Core Front-end Team (we are currently full, check back later)
- Passion for creating delightful and swift user interfaces.
- Proficiency in HTML, CSS, and an understanding that JavaScript can be used sparingly to enhance, not create, product experiences.
- You are comfortable not using any FE frameworks, and rather like to be in full control of the DOM and as close to browser as possible.
Fun fact: At Kagi, we prioritize speed, to the point where all functionalities of Kagi Search (except Stripe checkout and Maps) work perfectly without JavaScript. We see JavaScript as a tool to enhance the UX, not create it.
"""
This is the market pressure which is driving things towards more abstraction. Another iteration will add more abstraction on top of that. I'm fairly certain it can't be stopped now. Doing so would mean convincing tech leadership to start actively managing what technologies go into their products and striving for a "less is more" or minimalism approach.
Back in the day we used to rail on Flash websites because while they looked nice, they weren't accessible to screen readers etc, sites weren't consistent, links didn't turn purple, and the back button didn't work.
Now we've done that again with HTML and React.
Flash is dead, long live Flash.
A form submission is not just a post submit. You have to do client+server error handling, dynamically show/hide/add fields, show char count, handle intermittent state and still more. All of these are possible with JS but is faster and more reliable with a purpose-built library. Same goes for a draggable dashboard, filters for search results...
Lots of complainants I read seem like people who would do all in plain html never worked on actual web app.
At the same time seems like JS stuff is overused in lots of places and a lot of React or Angular is done by people who want to have it on their CVs.
Can be. And still work better than a lot of JS-heavy monstrosities.
I've built several web applications recently that don't use any modern JavaScript framework. You'd be surprised how quickly a page can fully reload and equally surprised at how okay of a UX it is to not always persist state.
Here's an example video of an app that does a mix of "state persistence" and "good ol' reload the page" approaches. https://withlattice.com/documentation#nav-create-application
1) Chat interface maintains state (but uses minimal JavaScript)
2) Application status requires a reload
Is this the absolute best UX? Possibly not, but users haven't said anything about it and it's such little code with almost zero dependencies.
If anything, sometimes I think they make the transition too smooth, to the point that it can be possible to miss it. Sharp changes are generally easy to notice.
Or worst case scenario, fetch().
But honestly, forms are fine. Not all apps need beautiful animations.
It's better to have great UI, but it's not free.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
Has it ever occurred to you that maybe it only takes them 15-30 minutes (still too much, obviously) but that it is great to be able to only work 15 minutes/day?
Estimates reflect what managers will say ok to, not how much real work it takes.
Deleted Comment
In the case of 1 day to add a button, let the developer have a day of knowing "today, my goal is to add a button". Without the padding the developer would be thinking "I'll add that button, but after that I have no idea what's coming, whatever bullshit comes down the pipe I guess".
It's really hard to shift mental gears. People can do multiple tasks well, but only if there is a coherent thread they can follow through those tasks. Current software management philosophies are very hostile to those coherent threads.
The htmx guy has a small post on this. https://htmx.org/essays/locality-of-behaviour/
For web apps it breaks especially for SPAs really quickly.
So I believe it went out of the norm like 10 years
Forever grateful to you folks.
Differences in the types of environments and how they interact with them between age groups makes sense in a pretty boring sort of way, and at any rate is solvable through simple experience. It’s more interesting to me that this observation is another point of correlation in the notion that the industry has aligned itself with productivity over any other metric. While productivity is important, this unbalanced favor has introduced fragility and unsustainability into the industry and end user market.
It doesn't surprise me that people half my age have difficulty with some of these - it's much harder for them to play with and explore the concepts.
Most jr devs these days aren't like this.
1. Every generation of programmers typically only has a certain window of knowledge, and everything before their time is simply foreign to them. Most developers aren't programming history buffs, they don't read books from the past to learn about technologies or how they work, how we got to now, etc.
2. When you're starting off on your journey as a programmer you're using a lot of things without understanding their implementation, and that understanding for most individuals whom I've worked with comes from having to debug issues.
That's true, of course, but I think the disconnect he's pointing out is: a) deeper than that and b) new. I grew up a ways before he did and my first serious computer was a commodore 64. Like his 286, there was nothing you could do with it _except_ program it, and programming was hyper accessible. I immediately understood C's pointer syntax when I first came across it because the only way to show graphics on a C64 is to write to a specific memory address and the only way to intercept keypresses is to read from one.
Fast forward to the 21st century. My son is a smart kid - graduated valedictorian of a competitive high school - but he grew up with "computers" that hid the programming interface down so far that most of his experience with actual programming has been through emulators so the whole thing feels (and is!) artificial. He still struggles differentiating between what's "real" and what's emulated and I can tell from interacting with other programmers his age that he's not alone.
This process happens more naturally over time if you grow with the technology. For example, if you started programming with HTML in 1995 you not only have ~30 years of experience, but you've also seen the changes as they occurred, and have a great deal of context about the how and why each of them happened. That kind of experience can only happen in real-time, unless some kind soul is willing to write a manual to help newcomers speed-run it. Such a manual is often called a "textbook".
https://www.perseus.tufts.edu/hopper/text?doc=Perseus%3Atext....
Times haven't really changed.
Perhaps "Is kids' knowledge broadened and deepened by the media they consume?" more generally would do. It allows us to evaluate extent, change, and appropriateness more broadly. Not just the accessibility of a given topic, but how readily one can dive into the details and truly learn something.
The landscape of media then can change, but this question does not react to any and every change in the landscape the way a nostalgic argument does. Socrates would have no reason to worry; a book can broaden and deepen knowledge, too. Are we?
I obviously have gaps in my knowledge (started with Python, moved to frontend). Frontend is too abstracted from actual CS.
But I actively take University papers in my spare time on CS, and do C in my spare time to appreciate the lack of abstraction in low level code.
I really enjoy this (learning and C) more than economic programming (frontend, web, career).
I just love learning and realising how little I know. The latest thing I’ve learnt is that structs can have holes, and struct packing for situations where you need specific address offsets. Made my own bitmaps from scratch etc.
Next I’m thinking of picking up a Lisp.
The industry has had enough time to expand to include many different zeitgeists. I find myself smirking when I read old ewd essays decrying how programmers then didn’t understand programming. Seems like we’ve continued down that path.
From my part of the pond you’d expect the Computer Science questions to cover areas of combinatorics, abstract and linear algebra; satisfiability, search, and the like.
But we are talking about a pop culture type of show and what is the most popular form of programming today?
The web is complex nowadays, but it also actively hides its implementation from you to be a better product. Dialing a phone number with a modem on both ends has a sort of real tactility to it that’s pretty alien to young people that expect it to be “harder”. You can pick up the phone on the line and hear that something is going on. The computers are “talking” on the phone.
A metered Internet connection means I was constantly aware of how much data is going over that phone call. What takes huge chunks of that budget and what barely touches it.
My ISP even gave our family some web space to use. Like just the peek behind the curtain you get from putting a file on an FTP server, then requesting it in telnet and seeing every letter I typed zip in from the other side really illuminates a lot. If I ask the computer I called for a file in a special way, it sort of shouts it back at me over the phone call, and my computer can listen and understand that.
It’s not like it was the best implementation of the “product” that is the Internet. Anyone saying the contrary really is an old person shouting at a cloud. But I do have some sense of being lucky to get to explore the web in that era!