How do you do, fellow web developers? A growing disconnect
rakhim.exotext.com
rakhim.exotext.com
Being able to do things like this is really useful:
<form action="https://simonwillison.net/search/" method="get">
<input type="text" name="q">
<input type="submit" value="Search">
</form>
<a href="/contact">Contact us</a>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.
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.
How you bundle react is left as an exercise to the reader but the data is still there?
The Francis Scott Key of web development
"...and the data was still there!"
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.
I re-used it later on in university to hand it in as a project (easiest course ever) and got commended for not putting load on the servers and making the site slow for users by using something like PHP to re-generate the same stuff over and over as users browsed the site. A+
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...
"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."
... 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.
The parent comment is a bit exaggerated but it still has a point. One needs to be able to predict things and make sure whatever you do today isn't so rigid that it can't adapt to other things in the future without a major overhaul. Typically this means being cognizant of the assumptions made along the way, and making the minimal set of them. This kind of insight requires experience. People preaching YAGNI just don't seem to have much of it. They just read "YAGNI" in a blog post and then yell it at other people.
When it comes time to make a change, it's often not as big a deal as it was made out to be, and you have the benefit of everything that has been learned along the way. No one gets it right the first time anyway, so don't overthink it.
Multiple options around, I personally love this
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.
That's one of the selling points of react that was initially important that you can use it in limited fashion.
This would maybe be a few hours of work if going from a static site to a SPA was actually in scope. Strip headers from the current pages and now serve the body as content from an API.
You don't need your entire site to be built with react to use react within your site and building a JS based router is not very difficult and will get even easier if the Navigation API[1] becomes better supported.
This would actually be harder if you now still need a static site with an across page assistant. I would probably push back on some requirements and store state locally in the browser. Effectively hot reload the assistant on each navigation but even then it's doable, even using react.
1. https://html.spec.whatwg.org/multipage/nav-history-apis.html...
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.
I'm not saying that situation is ideal. Most of the web should be less JavaScripty.
(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.)
These laptops had <1gb RAM. You should be amazed if you could open multiple website.
Each website is essentially a full program with sandboxing etc - and surely you'd be aware that opening I.e. Photoshop 4 times on such a resource restricted system would be just as impossible.
And it wasn't any different back then. At last not on Mac, as I had an iMac and vividly remember the same issue.
The last devices before they switched to Intel had pretty bad performance, that was the reason why they switched soon after.
Times have changed, Dropbox removed that feature - and no one uses Dropbox even anymore.
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.
"etc. etc." = anything with state, so this can be quite a lot actually ...
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'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.
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 love a beautiful UI and experience. Listen to users and prioritize what helps them.
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.
well it used to be and still is till interest rates went up.
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 do think there are somewhat perverse incentives in the job market to be 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 on existing working code 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, or in other words the design space of web languages are being fully explored at a great pace, using real world projects. 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.
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.
"""
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.
That's not the fault of the library. It's the fault of the people using the libraries.
I'm not a big fan of web dev at large but there's nothing inherent to React's architecture that makes editing a single component to add a static link difficult (that I'm aware of).
What you're describing is typical average dev that creates impossible spaghetti code and then with an honest heart tells project managers how hard it is to change the color of a button because of incomprehensible tech jargon until the clueless PM goes 'okay okay, will two days be enough?' and the dev goes 'yes, I think so'.
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...
Can be. And still work better than a lot of JS-heavy monstrosities.
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.
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.
For web apps it breaks especially for SPAs really quickly.
So I believe it went out of the norm like 10 years
The htmx guy has a small post on this. https://htmx.org/essays/locality-of-behaviour/
So the jquery version could be the same as the htmx one, but you do `$('[hx-get]').on("click"){...}` or whatever (I don't know jQuery/do javascript).
the htmx version is symmetric with the href attribute in that it completely specifies what is going to happen directly on the element itself
of course you could do something in jquery like using a data attribute to store the url and HTTP method, etc, but at that point you'd be building https://intercoolerjs.org, the predecessor to htmx that was built on top of jquery
that doesn't look like a complete subroutine to me.
htmx generalizes this notion of hypermedia controls in a syntactically symmetric manner, preserving the locality of behavior inherent in those controls.
It is also inferior in Separation of Concerns(SoC) terms.
These two design principles are in conflict and the reason I invented the term LoB was to help people, like myself, who prefer locality to argue for it effectively in software design discussions.
That factoring has been the recommended way to separate concerns since before jQuery existed (e.g. with xhtml). Selecting specific IDs was always bad practice. Same with CSS. You were meant to use properties.
Tellingly, this is how html itself is designed. It's had ways to add your own tags since nearly the beginning, and the built-in ones stand as examples of how to design your custom tags' apis.
the htmx version is symmetric with the href attribute in that it completely specifies what is going to happen directly on the element itself
of course you could do something in jquery like using a data attribute to store the url and HTTP method, etc, but at that point you'd be building https://intercoolerjs.org, the predecessor to htmx that was built on top of jquery
That said, your markup can get unwieldy fairly quick, and you end up with a lot of similar and duplicated code/style blocks. My solution on a personal site, was to also use a backend-style templating library with partials[3], a file watcher[4] to build them automatically etc to kind of SSG a static site while maintaining reusable components. You can see where this is going, at what point does it make sense to just "reach for xyz framework" out of the gate? For as often as people (especially here) cry "ya aint gonna need it", there are at least as many times where people (less vocally) cry silently to themself, "I wish I'd just used a framework instead of unintentionally building a franken-framework".
This from a minimalist developer who has been doing it for a long time, with STRONG opinions about the modern state of the art. Honestly, it's very common for me to feel torn about ideals vs actual pragmatism.
[1]: https://github.com/gnat/surreal [2]: https://github.com/gnat/css-scope-inline [3]: https://github.com/leafo/lapis [4]: https://gittup.org/tup
Doesn't matter if it's a one line code change (some of my bug fixes have been exactly that).
And often it takes longer because it can take some departments a while to get around to their part of it as they have other things they're working on for other features and tasks as well.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
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".
Okay, you might argue that in earlier decades programmers also tended to have an understanding of hardware circuit design and how a CPU and memory etc. works in terms of logical gates and clocks. But arguably there is a harder abstraction boundary between hardware and software than at any given software-software abstraction boundary.
It's still this way in embedded development to some large degree.
That was more true 30 years ago, in the age of relatively simple micro-architectures in the (relatively short) era of the disconnected personal computer. But there are several directions to "bottom out". For example going in the direction of the network, you might dig into the details of ethernet, wifi, and UDP/TCP/IP. You can even go in the direction of electronics, and understand how to de/solder components, design and fabricate PCB's, or in the direction of enclosures and mechanisms. You can go in the direction of understanding the market itself, and all the CPU/GPU/motherboard/PCI/m2/SATA/chipset combinations and how they work together. You might go in the direction of understanding systems programming and the kernel, ttys, and file descriptors, or in the direction of cryptography, etc.
Complexity is a sign of a healthy ecosystem, and we see this repeated again and again in every area of human endeavor that continues unabated for any length of time. A field starts small and understandable by one person, but quickly continues to grow until it cannot reasonably be understood by any one person. Chemistry, math, engineering, physics are like this. Is it reasonable to lament this fact and consider modern practitioners any less than earlier ones for their lack of total knowledge of it?
My degree included this and I'm very glad it did.
Hiring manager's looking for React in next role. Would you prefer to someone with lots of experience (old ways) or someone expert in React with few years.
Looking for context.
I heard about this, and avoided pointers for a long time because of a fear that comments like yours gave me.
I then ended up realizing Java objects that I had been dealing with were just memory references, and that led me to learning about pointers in C.
Once I realized that I basically already knew what pointers were, I was pretty confused about why it created so much difficulty. Like it was an actual barrier for me to really understand how simple they are, so few moving parts.
It seems to me that everyone intuitively understands the difference between a home address, and the home itself.
Not to say that I'm an expert in pointer arithmetic or anything, I still prefer symbolic programming to dealing with pointers directly, for the same reason I prefer spoken English to Morse code.
I definitely agree that stuff is pretty annoying.
I guess I've gotten used to it to the casting behavior. Though these days I program mostly in dynamically typed languages.
https://www.perseus.tufts.edu/hopper/text?doc=Perseus%3Atext....
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?
Times haven't really changed.
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!
The tide is turning to an extent though. Here is my contribution:
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.
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.
Err.... I realize I'm not helping. I'll see myself out.
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 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.
In my case, the company I worked at shipped a product that came with a set of header files and dynamically linked libraries that exposed some of the core functionality to the customers for use in their own software, and designing this API was a specific task in itself.
Of the whole web stack, HTML is the only part I've consistently hated since the big web revolution that started around 2007. It's just such a piece of shit. JS got faster and TS redeemed it substantially. HTML still sucks.
I don't think I've ever seen anyone who describes their HTTP API as "REST" ever implement the HATEOAS part of the REST definition. And calling it REST without HATEOAS, is like calling a database ACID without Atomicity (for example).
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.
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.
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.
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.
It is an ubiquitous legacy, a critical infrastructure of our societies and a spaghetti that cost everybody a lot.
In the end it is controlled by the biggest corporations and various interests. Very hard to disrupt and replace.
* I type, then press enter, but a suggestion appeared in between so my enter got turned into "accept suggestion" instead. Or same with pressing an arrow and instead of moving my cursor it now selects a different suggestion because I pressed the arrow 10ms too late.
* I type a character like `"` or `<` or `[` or `(` or stuff like that, and it gets paired automatically. Or I type `]` or `)` and it does nothing because it's the same as the character under my cursor and it "helpfully" moves the cursor to the right instead of inserting the character (e.g. I want `]]` or `))` but it just ignores me and it leaves `]` or `)`). Worse is when this happens inconsistently, like pressing a `"` character being a 1d3 roll on the result (if my cursor is currently on `"`, then will I get `""` or `"` or `"""`?).
* I'm going to move the mouse to select some specific part of the code, but when I'm going to click it inserts some garbage right where I was going to click (e.g. type hints, some information about how many references are there, stuff like that). I never want anything to move my code around.
* (Other similar stuff I'm sure I'm forgetting.)
I'm not saying things like those aren't useful, but those defaults are so different from what I want that they're more of an inconvenience for me and I have to spend the first hour changing them (but I can't do this when physically pair programming). Otherwise it's basically impossible for me to develop muscle memory at all, because I have to constantly guess what's going to happen and what's going to move or appear or disappear.
TL;DR: Mainstream IDEs defaults are frustrating for me when I try to go keyboard-only, and also when I use mouse for some actions.
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 was quite a lot of fun in my university final project to be developing on a 6502 (NES) in Assembly and find myself working in a very restrictive environment. Likewise, when I was working with a powerful microcontroller, but still only 2k of memory and 16k of flash and not being able to use some libraries I typically do. I was left having to reimplement stuff on my own for my own purposes.
It's absolutely the case that some developer still need to care about those things, but by the time I started my career 20+ years ago, it was possible to make a good career as a dev who didn't know how to work with computers at an extremely low level.
Run it under dtrace, probably others as well.
This passage resonated with me. At a recent contract I saw some PRs from my team mates that I found baffling. But rather than comment on it or intervene for once I told myself to just ignore it. It's Chinatown, or something like that
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.
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.
Personally, unless the interactivity is needed (i.e. web apps, not web pages), I prefer a more basic site where I can be reasonably sure that UI will work the same way as everywhere else, even if it's not as fluid.
My observation is that people vote with their feet. Including developers. The developers who complain the most about this stuff aren't actually building a whole lot worth talking about.
Anyway, it's hard to break conventions when the convention has actually been SPAs for quite some time now. Most major websites are simply not very old school at this point, to put it mildly. That stopped being good enough a long time ago.
Only if your definition of “does the job” does not include “is accessible to every potential user” or you put in much more effort than you would otherwise have to if you used the web standards as intended.
Strong fundamentals are essential in every field, otherwise the disconnect will continue to grow and no one can do a thing about it.
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.)
See also https://en.wikiversity.org/wiki/Data_Structures_and_Algorith...
Or see the use of arrays in "Introduction to Algorithms", one of the standard textbooks about algorithms and data structures, the current edition being from 2022. There is no notion of arrays being resizable there.
Java, of course, calls its standard general-purpose list implementation both "array" and "list."
On that note, Swift is in the process of introducing a fixed-size array type which they intend to call “Vector”.
https://www.destroyallsoftware.com/talks/the-birth-and-death...
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.