It's genuinely fascinating to me how many professional web developers these days - smart people who produce good work - don't know how to build interactive features using HTML on its own (and maybe don't even know it's possible).
Being able to do things like this is really useful:
I've seen teams estimate a full day to add a link to a contact form because they need to refactor a bunch of React components to achieve that. I like being able to do this:
I worked with a team of developers tasked with creating a few 100% static websites. Single page, no interactivity, nothing dynamic. They were talking about which React components to use, server APIs to build, etc when I asked why they didn't just write HTML or use a static site generator and host the page in S3. They didn't know how to write vanilla HTML, they had never used it for more than bootstrapping a React app.
I'm still fascinated by a website linked on HN some time ago that was written in MarkDown, but then not translated to HTML and served, but sent as MarkDown along with a JavaScript renderer that would then translate and render it on the client. Sure, it works, but why?
(As a marginally related aside, I've recently spun up my mother's old 12" Powerbook G4 from 2005 or so. It worked fine and was reasonably fast and snappy (for a HD based machine), except when I opened the browser. A few tabs brought the machine to a standstill. Goes to show how much crap is on the modern web.)
mdwiki.info? I wrote it because back in 2012 you had a "Public" folder in Dropbox that also was a public static web space. So a way to create a homepage without installing any software and without need to learn html.
Times have changed, Dropbox removed that feature - and no one uses Dropbox even anymore.
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.
Writing good HTML is not what employers, hiring managers, HR, and resume algorithms consider to be a skill worth paying for. You gotta know React or GTFO. From the perspective of a newbie developer, why waste time learning the grandpa way of making webpages when React can do all the things?
I'm not saying that situation is ideal. Most of the web should be less JavaScripty.
Yes, but remember: static HTML is a one-way street. Better tell your manager otherwise they will one day come up with functionality that can't be done in your website and it's your fault.
EDIT: For example: manager/designer wants to add an assistant to the website; it should be draggable; it should also animate and keep animating smoothly no matter where the user navigates on the website. If your website is a SPA, this is conceptually easy. If your website is static this is going to be a nightmare and suddenly a simple change requires lots of work.
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.
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.
I agree no one should follow recommendations blindy, but I have seen WAY more instances (firsthand and second-hand) of people mis-architecting for circumstances that never come.
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.
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.
Absolutely. I built something like that during high school for a local artist. Had and interactive backend that allowed him to upload his creations and it would regenerate static HTML when he was done with that. That was my first paid developer job basically.
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+
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.
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.
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.
Are these frameworks incapable of having the static content as something that can be served? Are the links in the existing content unable to be updated to whatever need to happen for the page transitions?
I was going to say the same, I have a webxr (virtual reality) site that has a few react components on it, plus a few vanilla javascript libraries in the main page template.
Umm, how is it a one way street? Just add a <script> tag and implement what you need... I'm not 100% convinced that using react from jump street "Just in case we need something in the future" is a great idea. That having been said, I'm not sure I've built a completely static html page in the last decade.... So I often start with react/angular.
It's frustrating the lack of simple tooling out there for static site generation. I have had to write bespoke static site generator build scripts just to get things working.
Everything is React and SSR these days - like people please - it's not that complicated. TypeScript is an acceptable amount of overhead. Use React only if you absolutely need it and even then, use it super carefully because it has no seatbelts.
Petite-vue is a nice middle ground for 99% of websites and I am sad that this approach (templating) to build dynamic content doesn't have more investment.
As the old man screaming at the cloud, about the insane complexity of modern JavaScript frameworks, who hasn't done much with them and kind hates the experience of dealing with them at all, I hope you are right.
Can I still use my basic HTML knowledge and be productive? I've instead just given up doing any frontend work because I don't want to spend my time in React. Give me something simple, concrete, and understandable like an advanced algorithms textbook, and I'll go to town. Reading user guides or documentation of Typescript/Javascript frameworks feels impossibly hard in comparison.
Core Front-end Team (we are currently full, check back later)
- Passion for creating delightful and swift user interfaces.
- Proficiency in HTML, CSS, and an understanding that JavaScript can be used sparingly to enhance, not create, product experiences.
- You are comfortable not using any FE frameworks, and rather like to be in full control of the DOM and as close to browser as possible.
Fun fact: At Kagi, we prioritize speed, to the point where all functionalities of Kagi Search (except Stripe checkout and Maps) work perfectly without JavaScript. We see JavaScript as a tool to enhance the UX, not create it.
I can't think of any job postings I've seen recently that only wanted straight-forward web development. Everything was asking for a major framework + other supporting libraries for the front end. I'm only 40 and also screaming at the clouds, but I simply don't have the luxury of ignoring some of the larger things like React that gave me a job today.
This is the market pressure which is driving things towards more abstraction. Another iteration will add more abstraction on top of that. I'm fairly certain it can't be stopped now. Doing so would mean convincing tech leadership to start actively managing what technologies go into their products and striving for a "less is more" or minimalism approach.
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 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.
PHP just released version 8.4.2 today, so if that's your ball of wax, and you're working on your own projects, have at it. I wrote some PHP earlier this year for this one project. React pulls together a bunch of language features so that writing full blown apps in html, css, and JavaScript is less of a multi-level, multi-language templated nightmare for the developer who's writing it. Facebook was built on PHP so it's possible to build a fully featured web app using PHP and JavaScript, but that's also that's where React came from. React isn't just change for changes sake. PHP and hand rolled JavaScript can take you where you want to go, but getting there with React is just a bit more comfortable because it isn't a pile of templates with two languages you have to keep in your head simultaneously, and you can more easily debug it. For the cost of learning new ways of doing things, there's inheritance and composability. it's far from perfect, but, imo, it got popular because of how much easier it is to wrap your head around a pile of react components than it is a pile of php templates and its attached pile of JavaScript.
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.
this is key, working with rails and stimulus - you get to escape the nonsense. but we also have to admit reality - it's easier to pay *rent with react and friends than with other full-stack frameworks.
well it used to be and still is till interest rates went up.
I totally agree. It's like we've forgotten what browsers and HTML are meant to do.
Back in the day we used to rail on Flash websites because while they looked nice, they weren't accessible to screen readers etc, sites weren't consistent, links didn't turn purple, and the back button didn't work.
I don't think that's an exact analogy....maybe if you're using react in some oddball/low skill way. Flash (and ...javafx/applets/whatever the id equivalent was...I can't remember) were 1000x more bumpy than react.
React and similar frameworks are still generally better for accessibility compared to Flash, but at the same time can be worse because pages may behave sporadically and in unexpected ways, whereas Flash would be a blindspot for many screenreaders and related software.
I strongly encourage new junior hires to read MDN, specifications, etc. However, for some, it is like they cannot absorb information if its not in video format.
I'm frustrated at how often a how-to for something that takes three sentences to explain is a video. At the same time, it's amazing for things like simple home and car maintenance.
It doesn’t take a day to do it. It doesn’t even take a day with refactoring. But add in writing the tests, running through QA, code review, getting release approval &c &c and almost anything can take a day.
It would at the client I'm working for. Nothing hits Production without going through code review, getting UX approval, testing by QA, UAT testing and approval by product managers, running the automated test suite for the entire application (which takes several hours by itself) to make sure nothing else is failing for any reason, and running through various pipelines. Except maybe a couple of desperately needed hotfixes that process has never taken less than a full day.
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.
It looks all these rants are from people who need "Hello World" equivalent of web and are angry that there are tools for more complex use cases. I am primarily a backend developer with couple of decades of experience, who is now working on his own startup. I have built a simple HTML/JS site as our launch page. But I would kick out anyone who'll suggest that we should use plain HTML/JS instead of a frontend framework for our main app.
A form submission is not just a post submit. You have to do client+server error handling, dynamically show/hide/add fields, show char count, handle intermittent state and still more. All of these are possible with JS but is faster and more reliable with a purpose-built library. Same goes for a draggable dashboard, filters for search results...
It's because submitting a form interferes with all the other stuff running on the same page. E.g. after submission animations stop or disappear or skip a frame, annoying designers, etc. etc.
It's not always the right tool but in more cases than modern devs believe, it is.
I've built several web applications recently that don't use any modern JavaScript framework. You'd be surprised how quickly a page can fully reload and equally surprised at how okay of a UX it is to not always persist state.
I don't think there is really anything in your "etc. etc." I have never heard from any real user a complaint about animations stopping mid-flow. I think people know how pages work, in that I think they expect clicking things to do something disruptive, altering, changing. It's only been the design astronauts that have argued these discontinuities are "confusing" to users.
If anything, sometimes I think they make the transition too smooth, to the point that it can be possible to miss it. Sharp changes are generally easy to notice.
The sites that genuinely need a react frontend are fewer than the sites that use a react frontend. If you forgo react from the start, you have simplicity. At most, track your "state" in a session cookie + "rendering" on the backend. The good old days. I miss them.
Only one day? They must be juniors, that's at least a month or two - few hundred story points, dozen alignment meetings, QA, stakeholder buy-in, A/B tests, security consult, PM/PO/SM/EM/TL sign off, heck just catching up with the UX team alone would add a day's worth of calls.
> I've seen teams estimate a full day to add a link to a contact form because they need to
Has it ever occurred to you that maybe it only takes them 15-30 minutes (still too much, obviously) but that it is great to be able to only work 15 minutes/day?
Estimates reflect what managers will say ok to, not how much real work it takes.
Does it? I'm all too familiar with bad codebases where yes, trivial changes take days.
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'.
this is why I dislike the modern web so much. I love to find websites that are nice and simple, load fast, and have no JS bullshit to render "modern" UIs. But yeah, old man yelling at cloud and stuff... but you know what, I'm fine with that. And I do have the hopes of building something useful and successful that gives the middle-finger to all these "modern" frameworks.
An underappreciated reason people pad estimates is that it gives them some time to breath and know what business goals they personally need to deliver.
In the case of 1 day to add a button, let the developer have a day of knowing "today, my goal is to add a button". Without the padding the developer would be thinking "I'll add that button, but after that I have no idea what's coming, whatever bullshit comes down the pipe I guess".
It's really hard to shift mental gears. People can do multiple tasks well, but only if there is a coherent thread they can follow through those tasks. Current software management philosophies are very hostile to those coherent threads.
I don't do web stuff for a living, but I've been hacking since the early days of JavaScript - what I don't understand is what happened to separation of content, layout and interactivity - most of these react et al. monstrosities start with a big mess of JavaScript generating the html as lisp-like nested trees of tags. in that case, why not just use lisp?
2 neat libraries I've found to work like this are Surreal[1] and CSS-Scope-Inline[2] to get your Locality of Behavior (and Style) without a huge overhead.
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.
The example there is kind of poor. The problem isn't that the implementation is separated (in fact the implementation of `hx-get` is just ignored, which is cheating). The problem is that the jQuery example is using a button id to specify behavior instead of an attribute like the htmx version. Old CSS wisdom was to give your elements meaningful classes and apply properties to those. Or xpath let you do pattern matching on elements/attributes and apply templates to that.
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).
regardless of what CSS query you use to look the element up, in the jquery example you'd still have your logic (the url, etc) defined elsewhere
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
The htmx behavior is exactly as specified as the jQuery behavior, as what I'm suggesting is the last thing you said: you can literally implement the htmx attributes with jQuery.
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.
regardless of what CSS query you use to look the element up, in the jquery example you'd still have your logic (the url, etc) defined elsewhere
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
If you're being consistent, yes. The DTD specifies that you should refer elsewhere for the semantics, just as <button hx-get="/clicked"> has semantics that depend on whether you say "this is htmx" or "this is X library based on jQuery". Or alternatively those things all exactly specify the behavior, and you can go look at their specification for the details.
To the extent that it depends not on the code or its behavior, but on the interpreter that runs it, I suppose so. If you write the exact same code with the exact same meaning, I'm not sure why it matters.
I have never used a chocolate teapot, but anchor tags (and form tags) have been an important piece of the success of the World Wide Web as a hypermedia system.
htmx generalizes this notion of hypermedia controls in a syntactically symmetric manner, preserving the locality of behavior inherent in those controls.
it's not about the tag, it's about the claim that putting /clicked in the href or equivalent is somehow superior to $("#the-button"). click(function () { do stuff here}).
right exactly, it is superior in Locality of Behavior (LoB) terms because the behavior of the tag is apparent by only looking at it, whereas in the jquery example the behavior is in code that is located elsewhere.
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.
it's not like SPAs are more responsive today - they're horribly sluggish and things break constantly. modern and trendy doesn't mean better in any way.
woah! i couldn't agree more. i built my own router for React because i was exhausted by having every link be some overly heavy abstraction around... a few characters of text. KISS is key for me.
The complexity makes automated testing easier. We arrived here for reasons that may or may not not be critical to you but warranted implementation nonetheless. There is no conspiracy.
I often help younger developers with problems that involve absolute vs. relative paths - their code doesn't work because they're invoking it with the wrong working directory. It's immediately obvious to me because I grew up using the command line, where files and paths are elemental. They're usually _really_ interested in properly understanding what's actually happened here, but they've been so intentionally shielded from the fundamentals of files and directories that they need quite a bit of time to let it all sink in. The solution, of course, is to teach things bottom up, but I have some sympathy for beginners who lose patience with spending so much time dealing with something that doesn't even _look_ like a computer from their perspective.
It has been very eye opening watching young and brilliant programmers who have grown up with mobile devices struggle when it comes to traditional environments. Many struggle with things that seem basic, like file systems, processes, memory management, how to use desktops and even mice, etc. However, once you solve or abstract away those things, many are able to churn out complex software at an impressive rate, particularly when they are able to assemble tool chains and frameworks together like legos. Then they go back to the struggle bus when something in that chain fails or functions unexpectedly.
Differences in the types of environments and how they interact with them between age groups makes sense in a pretty boring sort of way, and at any rate is solvable through simple experience. It’s more interesting to me that this observation is another point of correlation in the notion that the industry has aligned itself with productivity over any other metric. While productivity is important, this unbalanced favor has introduced fragility and unsustainability into the industry and end user market.
So much of the modern computing environment goes incredibly far out of its own way to hide information from the user. It's getting difficult just to see the URL in mobile browsers, and in some fairly general-purpose computing environment (iPads, etc) the concept of a "filesystem" has become very abstract and increasingly difficult to ascertain.
It doesn't surprise me that people half my age have difficulty with some of these - it's much harder for them to play with and explore the concepts.
I see kind of a mix of wonder and frustration - I don't know if I'm projecting, but I kind of suspect they're secretly accusing me of making things seem more difficult than they need to be.
1. Every generation of programmers typically only has a certain window of knowledge, and everything before their time is simply foreign to them. Most developers aren't programming history buffs, they don't read books from the past to learn about technologies or how they work, how we got to now, etc.
2. When you're starting off on your journey as a programmer you're using a lot of things without understanding their implementation, and that understanding for most individuals whom I've worked with comes from having to debug issues.
> Every generation of programmers typically only has a certain window of knowledge
That's true, of course, but I think the disconnect he's pointing out is: a) deeper than that and b) new. I grew up a ways before he did and my first serious computer was a commodore 64. Like his 286, there was nothing you could do with it _except_ program it, and programming was hyper accessible. I immediately understood C's pointer syntax when I first came across it because the only way to show graphics on a C64 is to write to a specific memory address and the only way to intercept keypresses is to read from one.
Fast forward to the 21st century. My son is a smart kid - graduated valedictorian of a competitive high school - but he grew up with "computers" that hid the programming interface down so far that most of his experience with actual programming has been through emulators so the whole thing feels (and is!) artificial. He still struggles differentiating between what's "real" and what's emulated and I can tell from interacting with other programmers his age that he's not alone.
The GP's point is more general and stands. Technologists inevitably start off "in the middle" of a stack of technologies, and then choose to dig down and/or build up from there. It is inevitable that newcomers will not understand the technologies upon which their current work rests. A certain fraction of those will become fascinated and drawn to understand the underpinnings of their work, for an edge, or for the love of it, or both.
This process happens more naturally over time if you grow with the technology. For example, if you started programming with HTML in 1995 you not only have ~30 years of experience, but you've also seen the changes as they occurred, and have a great deal of context about the how and why each of them happened. That kind of experience can only happen in real-time, unless some kind soul is willing to write a manual to help newcomers speed-run it. Such a manual is often called a "textbook".
Until maybe 15-ish years ago, it was common for programmers to “bottom out” on the machine code level. In other words, they came to roughly understand the whole software stack in principle down to the software-hardware interface (the CPU executing machine code). The topic of this thread is that this has (allegedly) changed, developers at large don’t go down in their understanding until they hit hardware anymore.
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.
>Until maybe 15-ish years ago, it was common for programmers to “bottom out” on the machine code level.
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?
>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
For those with past web stack exp 20-30+ yrs) 'without' modern web stack experience. How do you stand out for those job listings requiring modern stack? How do you tie those past experiences to remove such disconnect?
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.
Dude/ette; pointers WRECKED people's minds (myself included) when we learned about them in CS101 (modified for computer engineers) in 2006. I don't know why either; they make so much sense.
I 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.
If I recall correctly, the big gripe about them at the time was understanding all of the situations in which pointers can be used outside of simply accessing data, like setting one pointer to another one and doing pointer math with char-arrays (i.e. setting one variable's memory address to another). Like another poster said, much of this is unique to C and C++ without smart pointers.
Because C syntax makes pointers harder to use and understand than they really are. Also constraints around pointers, casting etc. I still clearly remember figthing the C compiler and getting back "makes integer from pointer without a cast" complilation errors and segfaults. That's the main reason why I don't want to touch C or Rust again. D felt so much easier. I could finally write a program without endlessly fighting the compiler.
I think the one weird trick to understand pointers is to do a tiny amount of assembly programming. Assembly is very simple and pointers are everywhere. Writing useful programs in it is a chore, but you don't need to!
I never understood the struggle people have with pointers, to me they are quite obvious, unless I'm missing some important thing about them.
You have something you need to store; it's stored in memory; so you need to store its address if you intend on accessing it; so you store it in a pointer. From there, the rest comes logically.
I think the problem with C (well my problem) was the *& characters all over the place. I think because I spent too much time with pascal where (in my opinion) the pointer syntax is more symmetric.
I think people just focus on problems entirely within their own domain and rarely branch out to anything else. The amount of times I've had to explain to senior devs of 20+ years how DNS works at a very simple level would astound you, which is something that I would assume should be picked up if not by learning, through sheer osmosis, but you'd be surprised. If you lack a formal education, and maybe went through a bootcamp - which there's nothing wrong with - you may not know a lot of things that would surprise this author.
I wonder if every generation is doomed to feel this way. Socrates was horrified about the corrosive effect of reading upon young people's ability to memorise speeches. Plus ca change etc.
On the other hand, as the guy on twitter recently said, "it's not fair that I spent my childhood teaching my parents to use a printer and as an old man I'm spending my old manhood teaching my adult children to use a printer".
My older relative is complaining that their working life roughly coincided with the time where computers became mainstream but were still hard to use, and now that computers have become easy to use (think smartphones and tablets) their (the relative’s) productive days are more or less over and all their hard-earned difficult computer knowledge is becoming obsolete. So they were the generation that had it hardest, because they had to deal with computers (unlike earlier generations) but had to do so before computers became easy to use (unlike later generations).
To be fair, "reading" in Socrates' time was viewed as social media or Netflix is seen today. Mindless entertainment. There was more of an emphasis back then to focus on a few solid works, memorize and really chew on the content and not consume religiously.
To some extent I'm sure the answer is yes, so I think the operative question is not "Are kids learning what I learned?" Instead it has to be something more subtle.
Perhaps "Is kids' knowledge broadened and deepened by the media they consume?" more generally would do. It allows us to evaluate extent, change, and appropriateness more broadly. Not just the accessibility of a given topic, but how readily one can dive into the details and truly learn something.
The landscape of media then can change, but this question does not react to any and every change in the landscape the way a nostalgic argument does. Socrates would have no reason to worry; a book can broaden and deepen knowledge, too. Are we?
Agree to some context. Maybe every generation we have 'why is this thing so hard', so html/css was hard. I think in early 90's, one might say so hard with styling issue due to lack of standardization (page layouts and hacks needed to ensure working on all major browsers). Then there was Flash, jQuery. Now plethora of modern stack __how__ we do this and with magnitude more features.
If you don't need the features, React isn't an abstraction over HTML, it's a complication. Plus CPUs aren't getting exponentially faster anymore - that is a real game changer.
I’m a new developer (2-4 years experience, all self taught) and I get what they are saying.
I obviously have gaps in my knowledge (started with Python, moved to frontend). Frontend is too abstracted from actual CS.
But I actively take University papers in my spare time on CS, and do C in my spare time to appreciate the lack of abstraction in low level code.
I really enjoy this (learning and C) more than economic programming (frontend, web, career).
I just love learning and realising how little I know. The latest thing I’ve learnt is that structs can have holes, and struct packing for situations where you need specific address offsets. Made my own bitmaps from scratch etc.
The Jblow and Muratori rants are contentious. Try arguing for formal methods some time.
The industry has had enough time to expand to include many different zeitgeists. I find myself smirking when I read old ewd essays decrying how programmers then didn’t understand programming. Seems like we’ve continued down that path.
From my part of the pond you’d expect the Computer Science questions to cover areas of combinatorics, abstract and linear algebra; satisfiability, search, and the like.
But we are talking about a pop culture type of show and what is the most popular form of programming today?
I would really like to try writing something along the lines of “the web from scratch” one day. I wouldn’t want it to be just a retelling of the history of the internet, but rather building up a set of abstractions from some physical example of communication to your own mental model of a hypertext standard on top of a simple transport protocol, sort of like Charles Petzold’s Code.
The web is complex nowadays, but it also actively hides its implementation from you to be a better product. Dialing a phone number with a modem on both ends has a sort of real tactility to it that’s pretty alien to young people that expect it to be “harder”. You can pick up the phone on the line and hear that something is going on. The computers are “talking” on the phone.
A metered Internet connection means I was constantly aware of how much data is going over that phone call. What takes huge chunks of that budget and what barely touches it.
My ISP even gave our family some web space to use. Like just the peek behind the curtain you get from putting a file on an FTP server, then requesting it in telnet and seeing every letter I typed zip in from the other side really illuminates a lot. If I ask the computer I called for a file in a special way, it sort of shouts it back at me over the phone call, and my computer can listen and understand that.
It’s not like it was the best implementation of the “product” that is the Internet. Anyone saying the contrary really is an old person shouting at a cloud. But I do have some sense of being lucky to get to explore the web in that era!
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 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:
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.
I had another dev mix up "object" and "response" and say "JSON response" in reference to a request that sent JSON. I asked 2 or 3 times, "Response to _what_?" before figuring it out. That still lives in my head.
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
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.
There's even "REST API", that now means "RPC over HTTP using JSON".
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).
> 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 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.
Over the years I've come to like HTTP. It's mostly text-based, but you can send arbitrary binary data through it. The request-response pattern is a decent match for a world where most computers have no clue where they are, need help learning their own IP address, and are stuck behind trapdoor firewalls anyway, so the only really usable case is to reach out to a well-known server at a well-known address and ask it to do something.
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.
The "big web revolution" started in the mid-90's.
I think it started going down hill when JS and then CSS were thrown into the mix. That time (late 90's, early 2000's) would've been a good time to reassess if building "applications" on top of a document delivery system was really the right approach. Instead, we got workaround upon workaround, and now we have what we see today...
> 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.
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.
API stands for "application programming interface". E.g. a graphics card driver can provide an API for an application (a web browser, a game, a calculator app) to draw an image on your screen... should it speak HTTP to do that?
I think this comment misses what we're saying here in that there are many people working on things like operating systems, specialist desktop software and libraries, for whom API design has nothing to do with any form of network transport at all.
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.
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.
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.
Am I the only one that gets annoyed by that "enhanced representation"? All I want to see in my editor window is the code itself. Every year, VS Code goes further and further in adding more inline hints, error messages, test results, stacktraces... It starts getting confusing, distinguishing the actual sources from the other stuff.
Ugh. Maybe not exactly what you're talking about, but whenever I have to use a mainstream IDE for one reason or another, or some web REPL (e.g. to share code snippets), I end up frustrated but also really curious about how other people program.
* 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.
I often see engineers from other teams ask for a "non-blocking endpoint" because they don’t want to block while waiting for a response from the server. What is a "non-blocking endpoint"? If you are making the request, just do not block...
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.
You could have said that 20 years ago. I've never needed to worry about clock cycles or cache locality, I don't even know how to measure cache misses in my code (I have a CS degree too). And the most consideration I give to memory consumption is whether to process data in a stream, or in memory.
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.
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.
My professional career has largely been web dev, where I haven’t really had to worry about resource constraints
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 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.
> I've always felt safety in coding. It was a comfortably logical, deterministic, and beautifully consistent refuge from the world of vague and ambagious reality. I also felt certain kinship to other programmers, it was my tribe. So I'm worried about this feeling of disconnect, a little bit.
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
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.
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.
My personal issue with SPAs is that the experience is often not really better than the old school way, it's just the the issues and failure modes are different. SPAs tend to be slower to load, break platform conventions by re-implementing browser behavior and they're are more stateful, making invalid states harder to recover from.
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.
I think that's very subjective. SPAs load pretty quickly on a modern network. It's pretty much a non issue unless you are a bit OCD about such things. And I've seen some nice examples of SPAs that are actually quite nice to use. Mostly we're talking about the content of 2 or 3 floppy disks from way back (I'm old enough to have used those). Even back then that wasn't a lot. Many interesting things required multiple floppy disks.
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.
My issue with SPAs is that I very often end up in an incorrect state. I don't know, maybe I'm using a browser wrong? I'm clicking on things, pressing back and forward, and almost daily in some SPA app I get to either a blank screen or some error. I then refresh, and inevitably lose the state, as the URL would likely not match the latest correct state of the app.
> 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.
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.
> 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.)
Stacks in computer science aren’t random-access data structures, which arrays are. Conversely, arrays in computer science are by default thought of as having a fixed size, and don’t inherently have a dynamic size variable associated with them that would be necessary for a pop operation. You can implement a stack on top of an array, but that doesn’t mean that they are the same data structure. The array would be an implementation detail of the stack. (Alternatively, a stack can be implemented as a linked list.)
That's the usage in JavaScript, but there has been no general shift. What I wrote is true in Java, Go, Rust, and Python, for example. In theoretical computer science, it is certainly the default assumption when the word "array" is used without qualification.
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.
But not PHP (where an array is actually a dictionary, too...), Perl, Swift, or most scientific languages like Matlab and R. C-influenced languages usually differentiate between "arrays" and "lists"/"vectors", but that's just convention.
Java, of course, calls its standard general-purpose list implementation both "array" and "list."
Java doesn’t call any of its List implementations “array”. There’s ArrayList, which just means a list implemented on top of an array (actually multiple arrays in the general case, since it has to switch between arrays when increasing capacity). It doesn’t mean that it is an array, any more than a stack implemented on top of an array is an array (it isn’t).
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.
I'm still fascinated by a website linked on HN some time ago that was written in MarkDown, but then not translated to HTML and served, but sent as MarkDown along with a JavaScript renderer that would then translate and render it on the client. Sure, it works, but why?
(As a marginally related aside, I've recently spun up my mother's old 12" Powerbook G4 from 2005 or so. It worked fine and was reasonably fast and snappy (for a HD based machine), except when I opened the browser. A few tabs brought the machine to a standstill. Goes to show how much crap is on the modern web.)
mdwiki.info? I wrote it because back in 2012 you had a "Public" folder in Dropbox that also was a public static web space. So a way to create a homepage without installing any software and without need to learn html.
Times have changed, Dropbox removed that feature - and no one uses Dropbox even anymore.
That's an unrealistic complaint.
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.
Writing good HTML is not what employers, hiring managers, HR, and resume algorithms consider to be a skill worth paying for. You gotta know React or GTFO. From the perspective of a newbie developer, why waste time learning the grandpa way of making webpages when React can do all the things?
I'm not saying that situation is ideal. Most of the web should be less JavaScripty.
Yes, but remember: static HTML is a one-way street. Better tell your manager otherwise they will one day come up with functionality that can't be done in your website and it's your fault.
EDIT: For example: manager/designer wants to add an assistant to the website; it should be draggable; it should also animate and keep animating smoothly no matter where the user navigates on the website. If your website is a SPA, this is conceptually easy. If your website is static this is going to be a nightmare and suddenly a simple change requires lots of work.
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.
As if requirements are set in stone.
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.
The requirements you have today are a lot more set in stone than the requirements you don't have today, that you imagine you might have tomorrow.
I agree no one should follow recommendations blindy, but I have seen WAY more instances (firsthand and second-hand) of people mis-architecting for circumstances that never come.
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.
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.
Absolutely. I built something like that during high school for a local artist. Had and interactive backend that allowed him to upload his creations and it would regenerate static HTML when he was done with that. That was my first paid developer job basically.
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+
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...
Build a router and set inner HTML.
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...
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.
And it uses html instead of stipid component templating that reinvents html with different semantics.
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.
You mean this: https://react.dev/reference/react-dom/client/createRoot
How you bundle react is left as an exercise to the reader but the data is still there?
>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!"
Understood. Makes me think of YAGNI though.
https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it
No because a page-load e.g. breaks the animations.
CSS does support page change transitions now.
Are these frameworks incapable of having the static content as something that can be served? Are the links in the existing content unable to be updated to whatever need to happen for the page transitions?
I mean let's not go too far and pretend there is 0 advantage to JS
You can easily put React components into static website once you need them wherever you need them.
That's one of the selling points of react that was initially important that you can use it in limited fashion.
I was going to say the same, I have a webxr (virtual reality) site that has a few react components on it, plus a few vanilla javascript libraries in the main page template.
Umm, how is it a one way street? Just add a <script> tag and implement what you need... I'm not 100% convinced that using react from jump street "Just in case we need something in the future" is a great idea. That having been said, I'm not sure I've built a completely static html page in the last decade.... So I often start with react/angular.
It's frustrating the lack of simple tooling out there for static site generation. I have had to write bespoke static site generator build scripts just to get things working.
Everything is React and SSR these days - like people please - it's not that complicated. TypeScript is an acceptable amount of overhead. Use React only if you absolutely need it and even then, use it super carefully because it has no seatbelts.
Petite-vue is a nice middle ground for 99% of websites and I am sad that this approach (templating) to build dynamic content doesn't have more investment.
With Sveltekit it's quite easy to generate a static site, I've had good experiences with it
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.
Yes, if looking at the right places. :)
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.
"""
Damn; another reason Kagi rocks. No JS needed!
Unless you use maps or stripe checkout
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 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.
PHP just released version 8.4.2 today, so if that's your ball of wax, and you're working on your own projects, have at it. I wrote some PHP earlier this year for this one project. React pulls together a bunch of language features so that writing full blown apps in html, css, and JavaScript is less of a multi-level, multi-language templated nightmare for the developer who's writing it. Facebook was built on PHP so it's possible to build a fully featured web app using PHP and JavaScript, but that's also that's where React came from. React isn't just change for changes sake. PHP and hand rolled JavaScript can take you where you want to go, but getting there with React is just a bit more comfortable because it isn't a pile of templates with two languages you have to keep in your head simultaneously, and you can more easily debug it. For the cost of learning new ways of doing things, there's inheritance and composability. it's far from perfect, but, imo, it got popular because of how much easier it is to wrap your head around a pile of react components than it is a pile of php templates and its attached pile of JavaScript.
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.
this is key, working with rails and stimulus - you get to escape the nonsense. but we also have to admit reality - it's easier to pay *rent with react and friends than with other full-stack frameworks.
well it used to be and still is till interest rates went up.
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.
I don't think that's an exact analogy....maybe if you're using react in some oddball/low skill way. Flash (and ...javafx/applets/whatever the id equivalent was...I can't remember) were 1000x more bumpy than react.
React and similar frameworks are still generally better for accessibility compared to Flash, but at the same time can be worse because pages may behave sporadically and in unexpected ways, whereas Flash would be a blindspot for many screenreaders and related software.
I strongly encourage new junior hires to read MDN, specifications, etc. However, for some, it is like they cannot absorb information if its not in video format.
I'm frustrated at how often a how-to for something that takes three sentences to explain is a video. At the same time, it's amazing for things like simple home and car maintenance.
It doesn’t take a day to do it. It doesn’t even take a day with refactoring. But add in writing the tests, running through QA, code review, getting release approval &c &c and almost anything can take a day.
Right. I don't think adding an HTML link has nearly that much organizational overhead either.
It would at the client I'm working for. Nothing hits Production without going through code review, getting UX approval, testing by QA, UAT testing and approval by product managers, running the automated test suite for the entire application (which takes several hours by itself) to make sure nothing else is failing for any reason, and running through various pipelines. Except maybe a couple of desperately needed hotfixes that process has never taken less than a full day.
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.
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...
I agree but it is hard to explain to people what is a difference between a web app and what is 2-3 forms on a website.
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.
> A form submission is not just a post submit.
Can be. And still work better than a lot of JS-heavy monstrosities.
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.
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 ...
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.
HTTPS://gov.uk is amazing.
Forms are the real problem, not the tons of ads, auto playing videos, notification pop-ups, etc :-p
The sites that genuinely need a react frontend are fewer than the sites that use a react frontend. If you forgo react from the start, you have simplicity. At most, track your "state" in a session cookie + "rendering" on the backend. The good old days. I miss them.
Only one day? They must be juniors, that's at least a month or two - few hundred story points, dozen alignment meetings, QA, stakeholder buy-in, A/B tests, security consult, PM/PO/SM/EM/TL sign off, heck just catching up with the UX team alone would add a day's worth of calls.
Input type=“search” has some additional niceties. Html5 is great.
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/in...
I'm love old school HTML, need a autoscaling page, lets break out some FRAMESETs and some tables/iframes
> 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.
Does it? I'm all too familiar with bad codebases where yes, trivial changes take days.
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'.
Says more about the team than React.
To spend the other 400 minutes learning something new, right?
this is why I dislike the modern web so much. I love to find websites that are nice and simple, load fast, and have no JS bullshit to render "modern" UIs. But yeah, old man yelling at cloud and stuff... but you know what, I'm fine with that. And I do have the hopes of building something useful and successful that gives the middle-finger to all these "modern" frameworks.
An underappreciated reason people pad estimates is that it gives them some time to breath and know what business goals they personally need to deliver.
In the case of 1 day to add a button, let the developer have a day of knowing "today, my goal is to add a button". Without the padding the developer would be thinking "I'll add that button, but after that I have no idea what's coming, whatever bullshit comes down the pipe I guess".
It's really hard to shift mental gears. People can do multiple tasks well, but only if there is a coherent thread they can follow through those tasks. Current software management philosophies are very hostile to those coherent threads.
I don't do web stuff for a living, but I've been hacking since the early days of JavaScript - what I don't understand is what happened to separation of content, layout and interactivity - most of these react et al. monstrosities start with a big mess of JavaScript generating the html as lisp-like nested trees of tags. in that case, why not just use lisp?
People realized that slicing it that way wasn't nice to work with.
The htmx guy has a small post on this. https://htmx.org/essays/locality-of-behaviour/
2 neat libraries I've found to work like this are Surreal[1] and CSS-Scope-Inline[2] to get your Locality of Behavior (and Style) without a huge overhead.
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
The example there is kind of poor. The problem isn't that the implementation is separated (in fact the implementation of `hx-get` is just ignored, which is cheating). The problem is that the jQuery example is using a button id to specify behavior instead of an attribute like the htmx version. Old CSS wisdom was to give your elements meaningful classes and apply properties to those. Or xpath let you do pattern matching on elements/attributes and apply templates to that.
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).
regardless of what CSS query you use to look the element up, in the jquery example you'd still have your logic (the url, etc) defined elsewhere
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
The htmx behavior is exactly as specified as the jQuery behavior, as what I'm suggesting is the last thing you said: you can literally implement the htmx attributes with jQuery.
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.
regardless of what CSS query you use to look the element up, in the jquery example you'd still have your logic (the url, etc) defined elsewhere
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
The htmx also has the logic defined elsewhere. It's literally exactly the same html.
with an anchor tag's href attribute, is the logic defined elsewhere?
If you're being consistent, yes. The DTD specifies that you should refer elsewhere for the semantics, just as <button hx-get="/clicked"> has semantics that depend on whether you say "this is htmx" or "this is X library based on jQuery". Or alternatively those things all exactly specify the behavior, and you can go look at their specification for the details.
fantastic I think the idea of locality of behavior is one that will not make sense to you
To the extent that it depends not on the code or its behavior, but on the interpreter that runs it, I suppose so. If you write the exact same code with the exact same meaning, I'm not sure why it matters.
exactly
> button hx-get="/clicked"
that doesn't look like a complete subroutine to me.
it’s not, but it is a complete specification of behavior, just as <a href=“/clicked”> is
that sounds about as helpful as a chocolate teapot.
I have never used a chocolate teapot, but anchor tags (and form tags) have been an important piece of the success of the World Wide Web as a hypermedia system.
htmx generalizes this notion of hypermedia controls in a syntactically symmetric manner, preserving the locality of behavior inherent in those controls.
https://dl.acm.org/doi/pdf/10.1145/3648188.3675127
it's not about the tag, it's about the claim that putting /clicked in the href or equivalent is somehow superior to $("#the-button"). click(function () { do stuff here}).
right exactly, it is superior in Locality of Behavior (LoB) terms because the behavior of the tag is apparent by only looking at it, whereas in the jquery example the behavior is in code that is located elsewhere.
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.
so a comment would have done the same job? you don't need htmx to add a comment.
man, that's a really good point
It worked for documents and maybe sprinkling jQuery here and there.
For web apps it breaks especially for SPAs really quickly.
So I believe it went out of the norm like 10 years
it's not like SPAs are more responsive today - they're horribly sluggish and things break constantly. modern and trendy doesn't mean better in any way.
Because not everyone likes writing lisp?
writing lisp in JavaScript is so much worse!
woah! i couldn't agree more. i built my own router for React because i was exhausted by having every link be some overly heavy abstraction around... a few characters of text. KISS is key for me.
The complexity makes automated testing easier. We arrived here for reasons that may or may not not be critical to you but warranted implementation nonetheless. There is no conspiracy.
Unfortunately, many of us are choosing to forgo the productivity gains you and DHH provided via Django and Rails.
Forever grateful to you folks.
I often help younger developers with problems that involve absolute vs. relative paths - their code doesn't work because they're invoking it with the wrong working directory. It's immediately obvious to me because I grew up using the command line, where files and paths are elemental. They're usually _really_ interested in properly understanding what's actually happened here, but they've been so intentionally shielded from the fundamentals of files and directories that they need quite a bit of time to let it all sink in. The solution, of course, is to teach things bottom up, but I have some sympathy for beginners who lose patience with spending so much time dealing with something that doesn't even _look_ like a computer from their perspective.
It has been very eye opening watching young and brilliant programmers who have grown up with mobile devices struggle when it comes to traditional environments. Many struggle with things that seem basic, like file systems, processes, memory management, how to use desktops and even mice, etc. However, once you solve or abstract away those things, many are able to churn out complex software at an impressive rate, particularly when they are able to assemble tool chains and frameworks together like legos. Then they go back to the struggle bus when something in that chain fails or functions unexpectedly.
Differences in the types of environments and how they interact with them between age groups makes sense in a pretty boring sort of way, and at any rate is solvable through simple experience. It’s more interesting to me that this observation is another point of correlation in the notion that the industry has aligned itself with productivity over any other metric. While productivity is important, this unbalanced favor has introduced fragility and unsustainability into the industry and end user market.
So much of the modern computing environment goes incredibly far out of its own way to hide information from the user. It's getting difficult just to see the URL in mobile browsers, and in some fairly general-purpose computing environment (iPads, etc) the concept of a "filesystem" has become very abstract and increasingly difficult to ascertain.
It doesn't surprise me that people half my age have difficulty with some of these - it's much harder for them to play with and explore the concepts.
> They're usually _really_ interested in properly understanding what's actually happened here
Most jr devs these days aren't like this.
I see kind of a mix of wonder and frustration - I don't know if I'm projecting, but I kind of suspect they're secretly accusing me of making things seem more difficult than they need to be.
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".
Until maybe 15-ish years ago, it was common for programmers to “bottom out” on the machine code level. In other words, they came to roughly understand the whole software stack in principle down to the software-hardware interface (the CPU executing machine code). The topic of this thread is that this has (allegedly) changed, developers at large don’t go down in their understanding until they hit hardware anymore.
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.
>Until maybe 15-ish years ago, it was common for programmers to “bottom out” on the machine code level.
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?
>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
My degree included this and I'm very glad it did.
> it was common for programmers to “bottom out” on the machine code level.
It's still this way in embedded development to some large degree.
For those with past web stack exp 20-30+ yrs) 'without' modern web stack experience. How do you stand out for those job listings requiring modern stack? How do you tie those past experiences to remove such disconnect?
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.
Dude/ette; pointers WRECKED people's minds (myself included) when we learned about them in CS101 (modified for computer engineers) in 2006. I don't know why either; they make so much sense.
Can you explain why?
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.
If I recall correctly, the big gripe about them at the time was understanding all of the situations in which pointers can be used outside of simply accessing data, like setting one pointer to another one and doing pointer math with char-arrays (i.e. setting one variable's memory address to another). Like another poster said, much of this is unique to C and C++ without smart pointers.
Because C syntax makes pointers harder to use and understand than they really are. Also constraints around pointers, casting etc. I still clearly remember figthing the C compiler and getting back "makes integer from pointer without a cast" complilation errors and segfaults. That's the main reason why I don't want to touch C or Rust again. D felt so much easier. I could finally write a program without endlessly fighting the compiler.
I've never programmed in D. I only here good things
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.
I think the one weird trick to understand pointers is to do a tiny amount of assembly programming. Assembly is very simple and pointers are everywhere. Writing useful programs in it is a chore, but you don't need to!
I never understood the struggle people have with pointers, to me they are quite obvious, unless I'm missing some important thing about them. You have something you need to store; it's stored in memory; so you need to store its address if you intend on accessing it; so you store it in a pointer. From there, the rest comes logically.
I think the problem with C (well my problem) was the *& characters all over the place. I think because I spent too much time with pascal where (in my opinion) the pointer syntax is more symmetric.
Nah, I entered the industry in 2008, and I know enough FORTRAN to know I never want to use it.
I think people just focus on problems entirely within their own domain and rarely branch out to anything else. The amount of times I've had to explain to senior devs of 20+ years how DNS works at a very simple level would astound you, which is something that I would assume should be picked up if not by learning, through sheer osmosis, but you'd be surprised. If you lack a formal education, and maybe went through a bootcamp - which there's nothing wrong with - you may not know a lot of things that would surprise this author.
I wonder if every generation is doomed to feel this way. Socrates was horrified about the corrosive effect of reading upon young people's ability to memorise speeches. Plus ca change etc.
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".
My older relative is complaining that their working life roughly coincided with the time where computers became mainstream but were still hard to use, and now that computers have become easy to use (think smartphones and tablets) their (the relative’s) productive days are more or less over and all their hard-earned difficult computer knowledge is becoming obsolete. So they were the generation that had it hardest, because they had to deal with computers (unlike earlier generations) but had to do so before computers became easy to use (unlike later generations).
To be fair, 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?
Agree to some context. Maybe every generation we have 'why is this thing so hard', so html/css was hard. I think in early 90's, one might say so hard with styling issue due to lack of standardization (page layouts and hacks needed to ensure working on all major browsers). Then there was Flash, jQuery. Now plethora of modern stack __how__ we do this and with magnitude more features.
https://www.youtube.com/watch?v=GE-_U8qOp3g
i wonder when people realize that this pattern of hating abstraction has always been wrong and foolish in retrospect
If you don't need the features, React isn't an abstraction over HTML, it's a complication. Plus CPUs aren't getting exponentially faster anymore - that is a real game changer.
I’m a new developer (2-4 years experience, all self taught) and I get what they are saying.
I obviously have gaps in my knowledge (started with Python, moved to frontend). Frontend is too abstracted from actual CS.
But I actively take University papers in my spare time on CS, and do C in my spare time to appreciate the lack of abstraction in low level code.
I really enjoy this (learning and C) more than economic programming (frontend, web, career).
I just love learning and realising how little I know. The latest thing I’ve learnt is that structs can have holes, and struct packing for situations where you need specific address offsets. Made my own bitmaps from scratch etc.
Next I’m thinking of picking up a Lisp.
The Jblow and Muratori rants are contentious. Try arguing for formal methods some time.
The industry has had enough time to expand to include many different zeitgeists. I find myself smirking when I read old ewd essays decrying how programmers then didn’t understand programming. Seems like we’ve continued down that path.
From my part of the pond you’d expect the Computer Science questions to cover areas of combinatorics, abstract and linear algebra; satisfiability, search, and the like.
But we are talking about a pop culture type of show and what is the most popular form of programming today?
I would really like to try writing something along the lines of “the web from scratch” one day. I wouldn’t want it to be just a retelling of the history of the internet, but rather building up a set of abstractions from some physical example of communication to your own mental model of a hypertext standard on top of a simple transport protocol, sort of like Charles Petzold’s Code.
The web is complex nowadays, but it also actively hides its implementation from you to be a better product. Dialing a phone number with a modem on both ends has a sort of real tactility to it that’s pretty alien to young people that expect it to be “harder”. You can pick up the phone on the line and hear that something is going on. The computers are “talking” on the phone.
A metered Internet connection means I was constantly aware of how much data is going over that phone call. What takes huge chunks of that budget and what barely touches it.
My ISP even gave our family some web space to use. Like just the peek behind the curtain you get from putting a file on an FTP server, then requesting it in telnet and seeing every letter I typed zip in from the other side really illuminates a lot. If I ask the computer I called for a file in a special way, it sort of shouts it back at me over the phone call, and my computer can listen and understand that.
It’s not like it was the best implementation of the “product” that is the Internet. Anyone saying the contrary really is an old person shouting at a cloud. But I do have some sense of being lucky to get to explore the web in that era!
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 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
Love this book!
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.
I had another dev mix up "object" and "response" and say "JSON response" in reference to a request that sent JSON. I asked 2 or 3 times, "Response to _what_?" before figuring it out. That still lives in my head.
From the point of view of the server, the request might be a response. ;)
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
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.
There's even "REST API", that now means "RPC over HTTP using JSON".
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).
> 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.
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.
Over the years I've come to like HTTP. It's mostly text-based, but you can send arbitrary binary data through it. The request-response pattern is a decent match for a world where most computers have no clue where they are, need help learning their own IP address, and are stuck behind trapdoor firewalls anyway, so the only really usable case is to reach out to a well-known server at a well-known address and ask it to do something.
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.
The "big web revolution" started in the mid-90's. I think it started going down hill when JS and then CSS were thrown into the mix. That time (late 90's, early 2000's) would've been a good time to reassess if building "applications" on top of a document delivery system was really the right approach. Instead, we got workaround upon workaround, and now we have what we see today...
> 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.
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.
API stands for "application programming interface". E.g. a graphics card driver can provide an API for an application (a web browser, a game, a calculator app) to draw an image on your screen... should it speak HTTP to do that?
I think this comment misses what we're saying here in that there are many people working on things like operating systems, specialist desktop software and libraries, for whom API design has nothing to do with any form of network transport at all.
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.
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.
Liked reading this, could you share a few examples. What you saw, what you wanted.
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
Hey great work!
It is funny that "the Web" as a platform has become like the mainframe for banks and some big companies.
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 really liked the font and found it, it's "IowanOldStyle": https://font.download/font/iowanoldst-bt
Am I the only one that gets annoyed by that "enhanced representation"? All I want to see in my editor window is the code itself. Every year, VS Code goes further and further in adding more inline hints, error messages, test results, stacktraces... It starts getting confusing, distinguishing the actual sources from the other stuff.
Ugh. Maybe not exactly what you're talking about, but whenever I have to use a mainstream IDE for one reason or another, or some web REPL (e.g. to share code snippets), I end up frustrated but also really curious about how other people program.
* 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.
I often see engineers from other teams ask for a "non-blocking endpoint" because they don’t want to block while waiting for a response from the server. What is a "non-blocking endpoint"? If you are making the request, just do not block...
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.
You could have said that 20 years ago. I've never needed to worry about clock cycles or cache locality, I don't even know how to measure cache misses in my code (I have a CS degree too). And the most consideration I give to memory consumption is whether to process data in a stream, or in memory.
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.
> how to measure cache misses
Run it under dtrace, probably others as well.
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 cost me over $500 to upgrade my 4mb RAM to 16.
My professional career has largely been web dev, where I haven’t really had to worry about resource constraints
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 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.
Thanks for posting. Earlier I submitted the original video which motivated me to write this blog post: https://news.ycombinator.com/item?id=42461182
> I've always felt safety in coding. It was a comfortably logical, deterministic, and beautifully consistent refuge from the world of vague and ambagious reality. I also felt certain kinship to other programmers, it was my tribe. So I'm worried about this feeling of disconnect, a little bit.
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
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.
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.
My personal issue with SPAs is that the experience is often not really better than the old school way, it's just the the issues and failure modes are different. SPAs tend to be slower to load, break platform conventions by re-implementing browser behavior and they're are more stateful, making invalid states harder to recover from.
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.
I think that's very subjective. SPAs load pretty quickly on a modern network. It's pretty much a non issue unless you are a bit OCD about such things. And I've seen some nice examples of SPAs that are actually quite nice to use. Mostly we're talking about the content of 2 or 3 floppy disks from way back (I'm old enough to have used those). Even back then that wasn't a lot. Many interesting things required multiple floppy disks.
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.
My issue with SPAs is that I very often end up in an incorrect state. I don't know, maybe I'm using a browser wrong? I'm clicking on things, pressing back and forward, and almost daily in some SPA app I get to either a blank screen or some error. I then refresh, and inevitably lose the state, as the URL would likely not match the latest correct state of the app.
> 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.
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.
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.
> 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.)
Stacks in computer science aren’t random-access data structures, which arrays are. Conversely, arrays in computer science are by default thought of as having a fixed size, and don’t inherently have a dynamic size variable associated with them that would be necessary for a pop operation. You can implement a stack on top of an array, but that doesn’t mean that they are the same data structure. The array would be an implementation detail of the stack. (Alternatively, a stack can be implemented as a linked list.)
40 years ago that would have been true, but meaning has since shifted. Hence the last statement in my response, which you ignored.
That's the usage in JavaScript, but there has been no general shift. What I wrote is true in Java, Go, Rust, and Python, for example. In theoretical computer science, it is certainly the default assumption when the word "array" is used without qualification.
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.
But not PHP (where an array is actually a dictionary, too...), Perl, Swift, or most scientific languages like Matlab and R. C-influenced languages usually differentiate between "arrays" and "lists"/"vectors", but that's just convention.
Java, of course, calls its standard general-purpose list implementation both "array" and "list."
Java doesn’t call any of its List implementations “array”. There’s ArrayList, which just means a list implemented on top of an array (actually multiple arrays in the general case, since it has to switch between arrays when increasing capacity). It doesn’t mean that it is an array, any more than a stack implemented on top of an array is an array (it isn’t).
> C-influenced languages usually differentiate between “arrays” and “lists”/“vectors”
On that note, Swift is in the process of introducing a fixed-size array type which they intend to call “Vector”.
Somebody at some point was predicting that JS is going to eat software world. Even made a funny talk about it. It's gradually happening.
Are you thinking of this?
https://www.destroyallsoftware.com/talks/the-birth-and-death...
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.
[dead]
[dead]
[flagged]