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.
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.
You can make an example that will invalidate any technology choice. Design for the requirements you have.
"That's a very nice car you've made. Unfortunately, if the designer later decides that it needs to survive artillery rounds, you'll wish you had built it out of armor steel as I recommended in the first place."
On the outside of their eyelids it would do nothing for self-awareness, so I'm assuming written on the inside... which they won't be able to see unless they look at something super bright, like the sun, with their eyes closed.
... I guess this season some of us have more time to overthink things.
Still, YAGNI needs careful consideration. What looks like YAGNI right now might be reasonable flexibility that will be needed as the project matures. YAGNI makes perfect sense when delivering a proof of concept, but it's not that straightforward when designing for long-term use.
You can develop that element and then just drop that onto your static page via /assets/ and you're golden. Easy to develop, simple to deploy and tiny file size.
There are plenty of things you can do with static websites, especially given you can have site generators and/or can write javascript by hand too (shock!).
For example if the requirement is to have website editable by non-programmers, that's where static site generators shine. Sure, one has to press "deploy" button and wait a minute before changes are visible... but you get to keep all the features of static pages, like trivial scalability and very high security and availability.
Even if you have to have dynamic functionality (like a shopping cart), there is no need to do the whole website dynamically. Sure, have an API server which may even render the cart page, but the rest of the website can be fully static, maybe with a tiny bit of javascript to render the "number of items in the cart" icon.
You absolutely can, but it's way more common to only know how to create a blank site with a framework than to migrate an existing site. React used to have a section in its documentation for how to add it to your site without adding a build system (not common knowledge, unless it's setting up a blank site through a script) and they've since replaced it with a brief tutorial telling you to migrate your website to a JS module with a link to a suggested build system.
All of this matters because the person that has to do this setup might not be you. It's certainly a problem with the frameworks themselves that porting a website (even just to add a little functionality) isn't as easy as setting one up initially but there's not really much an individual can do here. It's one reason I like frameworks like Preact so much, they're actually trying to fix this.
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.
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.
I'm in the fortunate position of not needing to care much what people are hiring for. Instead I'm more interested in what can I create, and to a lesser extent what sort of team could be scaled on the technology. One of the projects I'm currently contributing to is a massive web app that's nearing 30 years old, all written with a C core and served over CGI in Apache, from an age when C was necessary to process the amount of data that was getting processed per request...
I do think there are somewhat perverse incentives in the job market to up to date on the latest trend in order to maximize the ability to hop onto the most in demand platform. Which makes sense from the developer perspective! But then it also means that devs and even management feel pressure to churn the tech stack continuously, to keep abreast of the changes. There's a lot of devs that don't want to be considered stuck on an "old", e.g. PHP, stack, and sometimes management wants to be hiring the devs that are trying the hardest.
So to me it feels like a lot of change for changes sake, all the design space of web languages are fully explored. I don't think it's technically incorrect or wrong, but it is probably just a "not for me" part of the ever expanding tech world.
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.
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 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.
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.
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.
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.
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?
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.
> 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.
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...
Not a fan of these "old man screams at cloud" posts, but I had a similar experience.
Suddenly, everyone was talking about HTTP APIs, when they said API.
With the rise of IOS and Android, I expected the mobile devs would build something better than HTTP, without all the cruft from the past. But somehow that didn't happen.
> Suddenly, everyone was talking about HTTP APIs, when they said API.
I had a junior dev try to correct me when I used "framework" and "API" outside of a web context.
It caught me off guard at first, but the more I've thought about it, it seems inevitable as time goes on. The more abstractions we build, the more unreasonable it becomes to expect every developer to start with "bare metal" and work their way up. Schools are forced to teach with "the other side" (i.e. the highest-level abstractions) as the benchmark for graduating, because that's what employers need. So at some point they have to cut some of the more esoteric CS fundamentals and concepts to make room.
They did that before, it all depends on your definition of bare metal. They probably don't teach assembly, or circuit design even though that used to be bare metal
Because HTTP is ubiquitous and now performant enough. It has a whole ecosystem of battle tested tools that can handle any usecase you throw at it. So, unless you are writing an app used by billions of users or some game hyper-sensitive of latency or backend service for similar size platform, you'll do better with HTTP.
I had the same awakening a while back when changing industry. I was proud of my "API Design" that included header files, perhaps a python wrapper etc - whereas everyone else was talking about HTTP verbs, which luckily I was fairly well versed in.
Had a similar moment at one job. We were discussing possible API design choices for an integration project, and more than an hour into the meeting we realized half of the room was assuming HTTP. This rendered the majority of arguments spoken so far irrelevant.
> Suddenly, everyone was talking about HTTP APIs, when they said API.
I always try my best to delineate for people asking, but often I find they only care about the web API case, so me harping on about how an API can be used to control a robot OR a web server often just confuses them more.
> With the rise of IOS and Android, I expected the mobile devs would build something better than HTTP, without all the cruft from the past. But somehow that didn't happen.
Google, in particular, early on went for the php developer audience. Frankly this destroyed the technical credibility of people in the mobile space and we have been living with it ever since.
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.
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".
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".
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?
> Which method removes and returns the last element of an array?
The answer is “pop”, right? I think that’s a fairly generic data structures question (if you treat the word array as a standin for any modern iterable collection type.)
The blame falls on us olds for not communicating the benefits of the hypermedia approach to the younger generation, and allowing flashy front end boosters to bully us into silence on the topic.
The tide is turning to an extent though. Here is my contribution:
Given that every inch of that YouTube gameshow is "Sponsored by Jetbrains" (their logo even shows up multiple times on the spinny wheel thing) I'm not surprised they feature screenshots of Jetbrains IDEs showing off their type-related features.
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?
People talk about software "technologies" and it is true, there is some technology underlying them, but its mostly economics.
The nature of software with its multiple abstraction layers means that when the economics is "right" you can pretty much transmogrify anything into anything. E.g., you can setup a JS-based web server as a classic web framework serving good old html and thats not a joke, its reality.
Is web software economics today any different than it was in the past? You bet it is.
I’ve been feeling this same way but didn’t want to articulate it, possibly out of fear. I also wrote a little book based on “old school” or “pure JavaScript”. I’m sure you could make some of the same criticisms of that, but I tried to make it pure and down to the basics.
It’s on Amazon at the URL below but if you’re willing to give feedback, reach out and I’ll send a free copy.
As a fellow 37 year old, I had a realization yesterday after a prolonged debate about HTMX vs React. For context: I’m a long time React fan, think htmx is neat, and remember all the reasons why HTML-over-Ajax didn’t catch on in the 2007 web development era. Been a primarily web guy since 2003 or so.
The problem with React (and friends) isn’t React (and friends), it’s react developers. People who aren’t web developers first and react users second.
I have interviewed (and worked with) so many frontend engineers with years of experience whose minds were completely blown by the idea of using a form submit event to handle form submission. Or my biggest pet peeve – button + onclick to change location.href instead of just making a link. Argh.
So yeah I think we’re lucky to have grown up with this stuff and seen it evolve over time. Many folks these days come to the field backwards and miss a lot of the good stuff that’s available to them.
> There's gotta be a better way than just blaming noobs.
Here’s an alternative read of what I said: It is amazing that these frameworks empower so many people to build working software that solves users’ problems and creates value. This is awesome!
Sure the code sucks and we gripe about how many of the people don’t even care to learn the depths of the tech they use and clearly they don’t need to. This is a win. We can teach the ones who want to learn more and constrain those who don’t to where they can be effective without causing too much damage.
The level to which "kids these days" don't have to consider memory usage, cache locality, and clock cycles, is frustrating. But it is cool to realize how good our technology is now that most things aren't unbearably unusable, despite being designed horribly.
My desktop today has 64 gigs memory, 12 cores.
10 years ago, it was 16 gigs, 4 cores.
20 years ago, it was 1 gigs, 1 core.
30 years ago, it was 16 megabytes, 1 core.
It doesn't matter if you're a kid, if you're not considering memory usage you were either trained by Google, became a developer through nepotism, or both.
It’s also possible to work on projects, or in languages, or on systems where resource consumption isn’t a high concern. I wrote cobol for sun and hpux and these big old systems had plenty to go around. Important software comes in all shapes and sizes, as do their developers.
It's not so much a disconnect as more of a reluctance to specialize in what is an increasingly legacy/archaic way to build applications. I studied in the nineties and I've seen it all. Server side model view controller style UIs where each click results in a completely new page being fetched that is completely static slowly died over the last two decades plus (ever since MS pioneered XmlHttpRequest and AJAX became a thing in 2001).
Not doing requests via javascript still works. And for quick and dirty stuff where you don't care about how things look and feel it's a perfectly valid way of doing things. A lot of developer tools fall in that bucket. And a lot of developers are in any case a bit challenged on the UX front anyway so there's a good argument for not using too many ways to shoot at your feet. But having every request wiping the current page, scrolling to the top, etc. can be a bit jarring as a UX as well. And there's the whole round trip latency for fetching pages too, which can be noticeable.
In other words, if paying customers are involved you probably should not go there. Mostly people expect things to look and feel nice and have some designers involved with the whole thing.
End users don't care about any of this of course. They also don't care if the app is native, a webapp, or something you could have hosted on geocities 25 years ago. But they do notice if things look dated, crap, or otherwise a bit meh.
They especially don't care how things look under the hood. The whole notion of semantically pure HTML, vue vs. react, and all the other nonsense web developers obsess about. It does not matter to them at all. You could use divs for every freaking HTML element and they couldn't care less. Or render the whole thing with some native UI toolkit to a canvas (which is an option these days). As long as it does the job.
You don't have to do a SPA. But you kind of do have to deliver something that works and looks and feels nice. With WASM, we are kind of getting a lot more ways to do things. The whole game of working around browser quirks and limitations with dom trees, CSS, and what not is not necessarily the way of the future.
because I felt this strong disconnection between our class, I was and still am working on https://chat-to.dev which, despite being only a year old and a fairly small community, I feel that in some way I'm contributing to a healthy environment among developers.
Is it really a disconnect? Or just a single poorly made game show?
The article doesnt really get into this. It just describes the mistakes in a show, and hints at a few other anecdotes to then conclude there's a disconnect.
I believe there may be such a disconnect (34 years of programming under the belt, here) but it's hardly more than a feeling, or belief. This article doesn't substantiate this.
> My growing feeling of disconnect gets fueled mostly by seemingly shifting notions. Some examples I've heard are people saying "vanilla JS" when talking about Node, or saying "JS without frameworks" when talking about React. The "woah" moment from the first paragraph is another example.
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.
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.
You can make an example that will invalidate any technology choice. Design for the requirements you have.
"That's a very nice car you've made. Unfortunately, if the designer later decides that it needs to survive artillery rounds, you'll wish you had built it out of armor steel as I recommended in the first place."
YAGNI should be tattooed on some people's eyelids.
On the outside of their eyelids it would do nothing for self-awareness, so I'm assuming written on the inside... which they won't be able to see unless they look at something super bright, like the sun, with their eyes closed.
... I guess this season some of us have more time to overthink things.
Still, YAGNI needs careful consideration. What looks like YAGNI right now might be reasonable flexibility that will be needed as the project matures. YAGNI makes perfect sense when delivering a proof of concept, but it's not that straightforward when designing for long-term use.
It's not anymore!
Multiple options around, I personally love this
https://lit.dev/
You can develop that element and then just drop that onto your static page via /assets/ and you're golden. Easy to develop, simple to deploy and tiny file size.
Yes, but remember the much more important rules of programming:
You aren't gonna to need it[1]
Do the simplest thing that can possibly work[2]
1. https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it 2. https://www.ronjeffries.com/xprog/articles/practices/pracsim...
Not at all.
There are plenty of things you can do with static websites, especially given you can have site generators and/or can write javascript by hand too (shock!).
For example if the requirement is to have website editable by non-programmers, that's where static site generators shine. Sure, one has to press "deploy" button and wait a minute before changes are visible... but you get to keep all the features of static pages, like trivial scalability and very high security and availability.
Even if you have to have dynamic functionality (like a shopping cart), there is no need to do the whole website dynamically. Sure, have an API server which may even render the cart page, but the rest of the website can be fully static, maybe with a tiny bit of javascript to render the "number of items in the cart" icon.
You can't add interactivity to a static HTML site? Or shift the static pages into modern frameworks?
You absolutely can, but it's way more common to only know how to create a blank site with a framework than to migrate an existing site. React used to have a section in its documentation for how to add it to your site without adding a build system (not common knowledge, unless it's setting up a blank site through a script) and they've since replaced it with a brief tutorial telling you to migrate your website to a JS module with a link to a suggested build system.
All of this matters because the person that has to do this setup might not be you. It's certainly a problem with the frameworks themselves that porting a website (even just to add a little functionality) isn't as easy as setting one up initially but there's not really much an individual can do here. It's one reason I like frameworks like Preact so much, they're actually trying to fix this.
No because a page-load e.g. breaks the animations.
I mean let's not go too far and pretend there is 0 advantage to JS
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.
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.
I'm in the fortunate position of not needing to care much what people are hiring for. Instead I'm more interested in what can I create, and to a lesser extent what sort of team could be scaled on the technology. One of the projects I'm currently contributing to is a massive web app that's nearing 30 years old, all written with a C core and served over CGI in Apache, from an age when C was necessary to process the amount of data that was getting processed per request...
I do think there are somewhat perverse incentives in the job market to up to date on the latest trend in order to maximize the ability to hop onto the most in demand platform. Which makes sense from the developer perspective! But then it also means that devs and even management feel pressure to churn the tech stack continuously, to keep abreast of the changes. There's a lot of devs that don't want to be considered stuck on an "old", e.g. PHP, stack, and sometimes management wants to be hiring the devs that are trying the hardest.
So to me it feels like a lot of change for changes sake, all the design space of web languages are fully explored. I don't think it's technically incorrect or wrong, but it is probably just a "not for me" part of the ever expanding tech world.
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.
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 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.
Now we've done that again with HTML and React.
Flash is dead, long live Flash.
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 love old school HTML, need a autoscaling page, lets break out some FRAMESETs and some tables/iframes
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.
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.
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.
Nobody complaining isn't necessarily a "good thing". Absence of evidence and all that.
I've found that it's only like 1/1000 that will.
And this thread (few days ago) about why it's hard to buy nice things touches it https://news.ycombinator.com/item?id=42430450
Many (most?) don't raise issues because they've been conditioned that things won't get fixed.
I'm with you that overdone JS isn't necessary; and we should also consider user-silence to issues to bloat, slowness and jank.
I agree with all of that. Perhaps what I meant to say was that these weren't the things users were complaining about.
I love a beautiful UI and experience. Listen to users and prioritize what helps them.
HTMX.
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.
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.
> I don't think there is really anything in your "etc. etc."
"etc. etc." = anything with state, so this can be quite a lot actually ...
Forms are the real problem, not the tons of ads, auto playing videos, notification pop-ups, etc :-p
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?
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.
> 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.
No, I've seen them do the work. Refactoring those React components genuinely takes ages.
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...
A growing disconnect begins to grow when coders learn from bootcamp/courses that web development is an ocean, and this ocean is as big as the well.
Strong fundamentals are essential in every field, otherwise the disconnect will continue to grow and no one can do a thing about it.
Not a fan of these "old man screams at cloud" posts, but I had a similar experience.
Suddenly, everyone was talking about HTTP APIs, when they said API.
With the rise of IOS and Android, I expected the mobile devs would build something better than HTTP, without all the cruft from the past. But somehow that didn't happen.
Now API is synonymous with HTTP.
Strange how things turn out in the end.
> Suddenly, everyone was talking about HTTP APIs, when they said API.
I had a junior dev try to correct me when I used "framework" and "API" outside of a web context.
It caught me off guard at first, but the more I've thought about it, it seems inevitable as time goes on. The more abstractions we build, the more unreasonable it becomes to expect every developer to start with "bare metal" and work their way up. Schools are forced to teach with "the other side" (i.e. the highest-level abstractions) as the benchmark for graduating, because that's what employers need. So at some point they have to cut some of the more esoteric CS fundamentals and concepts to make room.
They did that before, it all depends on your definition of bare metal. They probably don't teach assembly, or circuit design even though that used to be bare metal
Because HTTP is ubiquitous and now performant enough. It has a whole ecosystem of battle tested tools that can handle any usecase you throw at it. So, unless you are writing an app used by billions of users or some game hyper-sensitive of latency or backend service for similar size platform, you'll do better with HTTP.
I had the same awakening a while back when changing industry. I was proud of my "API Design" that included header files, perhaps a python wrapper etc - whereas everyone else was talking about HTTP verbs, which luckily I was fairly well versed in.
Had a similar moment at one job. We were discussing possible API design choices for an integration project, and more than an hour into the meeting we realized half of the room was assuming HTTP. This rendered the majority of arguments spoken so far irrelevant.
> Suddenly, everyone was talking about HTTP APIs, when they said API.
I always try my best to delineate for people asking, but often I find they only care about the web API case, so me harping on about how an API can be used to control a robot OR a web server often just confuses them more.
I ... I may have made a web API that can control a robot?
Err.... I realize I'm not helping. I'll see myself out.
> With the rise of IOS and Android, I expected the mobile devs would build something better than HTTP, without all the cruft from the past. But somehow that didn't happen.
Google, in particular, early on went for the php developer audience. Frankly this destroyed the technical credibility of people in the mobile space and we have been living with it ever since.
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.
You've noticed two things:
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".
Nah, I entered the industry in 2008, and I know enough FORTRAN to know I never want to use it.
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.
https://www.perseus.tufts.edu/hopper/text?doc=Perseus%3Atext....
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".
To be fair, it's not fair that printer manufacturers do this to us for decades.
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.
Times haven't really changed.
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?
https://www.youtube.com/watch?v=GE-_U8qOp3g
> Which method removes and returns the last element of an array?
The answer is “pop”, right? I think that’s a fairly generic data structures question (if you treat the word array as a standin for any modern iterable collection type.)
The blame falls on us olds for not communicating the benefits of the hypermedia approach to the younger generation, and allowing flashy front end boosters to bully us into silence on the topic.
The tide is turning to an extent though. Here is my contribution:
https://hypermedia.systems
Given that every inch of that YouTube gameshow is "Sponsored by Jetbrains" (their logo even shows up multiple times on the spinny wheel thing) I'm not surprised they feature screenshots of Jetbrains IDEs showing off their type-related features.
Also, it makes sense to target this show at complete beginners, because experienced programmers rarely change their tools.
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?
People talk about software "technologies" and it is true, there is some technology underlying them, but its mostly economics.
The nature of software with its multiple abstraction layers means that when the economics is "right" you can pretty much transmogrify anything into anything. E.g., you can setup a JS-based web server as a classic web framework serving good old html and thats not a joke, its reality.
Is web software economics today any different than it was in the past? You bet it is.
I’ve been feeling this same way but didn’t want to articulate it, possibly out of fear. I also wrote a little book based on “old school” or “pure JavaScript”. I’m sure you could make some of the same criticisms of that, but I tried to make it pure and down to the basics.
It’s on Amazon at the URL below but if you’re willing to give feedback, reach out and I’ll send a free copy.
https://a.co/d/bwF4YF5
Thanks for posting. Earlier I submitted the original video which motivated me to write this blog post: https://news.ycombinator.com/item?id=42461182
As a fellow 37 year old, I had a realization yesterday after a prolonged debate about HTMX vs React. For context: I’m a long time React fan, think htmx is neat, and remember all the reasons why HTML-over-Ajax didn’t catch on in the 2007 web development era. Been a primarily web guy since 2003 or so.
The problem with React (and friends) isn’t React (and friends), it’s react developers. People who aren’t web developers first and react users second.
I have interviewed (and worked with) so many frontend engineers with years of experience whose minds were completely blown by the idea of using a form submit event to handle form submission. Or my biggest pet peeve – button + onclick to change location.href instead of just making a link. Argh.
So yeah I think we’re lucky to have grown up with this stuff and seen it evolve over time. Many folks these days come to the field backwards and miss a lot of the good stuff that’s available to them.
The problem with X isn't X, it's the devs.
I've heard that about PHP, JS, shell, .Net, VB6 and damn near every framework ever.
But aren't we the devs? We're just in their code saying their baby ugly?
There's gotta be a better way than just blaming noobs.
> There's gotta be a better way than just blaming noobs.
Here’s an alternative read of what I said: It is amazing that these frameworks empower so many people to build working software that solves users’ problems and creates value. This is awesome!
Sure the code sucks and we gripe about how many of the people don’t even care to learn the depths of the tech they use and clearly they don’t need to. This is a win. We can teach the ones who want to learn more and constrain those who don’t to where they can be effective without causing too much damage.
And most babies are ugly. It’s fine.
The level to which "kids these days" don't have to consider memory usage, cache locality, and clock cycles, is frustrating. But it is cool to realize how good our technology is now that most things aren't unbearably unusable, despite being designed horribly.
Hardware giveth and software taketh away.
My desktop today has 64 gigs memory, 12 cores. 10 years ago, it was 16 gigs, 4 cores. 20 years ago, it was 1 gigs, 1 core. 30 years ago, it was 16 megabytes, 1 core.
It doesn't matter if you're a kid, if you're not considering memory usage you were either trained by Google, became a developer through nepotism, or both.
It’s also possible to work on projects, or in languages, or on systems where resource consumption isn’t a high concern. I wrote cobol for sun and hpux and these big old systems had plenty to go around. Important software comes in all shapes and sizes, as do their developers.
It's not so much a disconnect as more of a reluctance to specialize in what is an increasingly legacy/archaic way to build applications. I studied in the nineties and I've seen it all. Server side model view controller style UIs where each click results in a completely new page being fetched that is completely static slowly died over the last two decades plus (ever since MS pioneered XmlHttpRequest and AJAX became a thing in 2001).
Not doing requests via javascript still works. And for quick and dirty stuff where you don't care about how things look and feel it's a perfectly valid way of doing things. A lot of developer tools fall in that bucket. And a lot of developers are in any case a bit challenged on the UX front anyway so there's a good argument for not using too many ways to shoot at your feet. But having every request wiping the current page, scrolling to the top, etc. can be a bit jarring as a UX as well. And there's the whole round trip latency for fetching pages too, which can be noticeable.
In other words, if paying customers are involved you probably should not go there. Mostly people expect things to look and feel nice and have some designers involved with the whole thing.
End users don't care about any of this of course. They also don't care if the app is native, a webapp, or something you could have hosted on geocities 25 years ago. But they do notice if things look dated, crap, or otherwise a bit meh.
They especially don't care how things look under the hood. The whole notion of semantically pure HTML, vue vs. react, and all the other nonsense web developers obsess about. It does not matter to them at all. You could use divs for every freaking HTML element and they couldn't care less. Or render the whole thing with some native UI toolkit to a canvas (which is an option these days). As long as it does the job.
You don't have to do a SPA. But you kind of do have to deliver something that works and looks and feels nice. With WASM, we are kind of getting a lot more ways to do things. The whole game of working around browser quirks and limitations with dom trees, CSS, and what not is not necessarily the way of the future.
because I felt this strong disconnection between our class, I was and still am working on https://chat-to.dev which, despite being only a year old and a fairly small community, I feel that in some way I'm contributing to a healthy environment among developers.
So the programmer mentioned in the first sentence didn't know about 'preserve log' checkbox?
I’m guessing not which seems about right for someone that also doesn’t know about non-SPA web sites. Sad.
Preserve log is still helpful for SPAs when you want to compare requests across full app loads.
Did you read more than the first sentence? The answer is there.
Is it really a disconnect? Or just a single poorly made game show?
The article doesnt really get into this. It just describes the mistakes in a show, and hints at a few other anecdotes to then conclude there's a disconnect.
I believe there may be such a disconnect (34 years of programming under the belt, here) but it's hardly more than a feeling, or belief. This article doesn't substantiate this.
> My growing feeling of disconnect gets fueled mostly by seemingly shifting notions. Some examples I've heard are people saying "vanilla JS" when talking about Node, or saying "JS without frameworks" when talking about React. The "woah" moment from the first paragraph is another example.
I really liked the font and found it, it's "IowanOldStyle": https://font.download/font/iowanoldst-bt
[dead]
[dead]