Aside from the Giants maybe some consultancies or hire-firms have that many? But they use whatever the client uses. If you're not in the business of selling frontend development services then a big part of your competitive advantage is _being able_ to make technology choices that are more-optimal than the labor market's lowest-common-denominator slurry.
Between JS/ECMAscript being abandonware for a decade and CSS' historical immaturity (cross-browser layout, custom properties, more pseudoclasses, etc) the Web was more of a wild west "whatever you we can cobble together" place. So of course we built an entire toolchain ecosystem for all the cool new tools we would reinvent from scratch.
but Things Are Pretty Good these days. We even have the world's only fully system portable assembly language: WASM! And the browser's Web APIs are becoming something like the missing Standard Library (shoutout to Deno).
The author's point seems to be that we are past a tipping point where we need all that additional complexity. You don't _need_ a separate system of reactivity these days, you can write a (closer to pre-hooks React, even!) React-style component library with Web Components now.
Personally I would need for Type Annotations to be a fully supported part of the spec before I made the point to "use the platform" professionally. Until some market force causes the core web technologies to truly fork my skills are useful for life. It's like a pale shadow of how UNIX users must feel :')
My point was your needs and problems are not everyone's needs and problems.
I don't want to think of memory management in most projects, I want to focus on business logic, so I use Node.js instead of Rust, even if the latter gives me more control.
Similarly, I don't want to think of DOM management in most projects, I want to focus on data dependencies, so I use React instead of Web Components, even if the latter gives me more control.
> Well, nothing is easier then adding constraints.
Which is why dieting and quitting smoking are famously easy things to do! ;)
There's something to be said for the "scrappyness" of resource limitations inflicted upon you when solving some problem. A sense of Triumph against the Universe itself is a nice pay-off
and in today's world of constant supply-chain attacks, you do probably _do_ need it!
We've adapted:
- our CI and git hooks so that our dependency or .lock files are visible when they change, and error if they change inconsistently
- and our team procedures to confine dependency updates to dedicated commits
The idea being that when you see one of those "messy" .lock file changes...you were expecting it. If you see one and are annoyed by it (like OP) that's actually a waving red flag that a dependency changed.
> Tabs vs spaces don't matter they are equivalent.
Just to nitpick (because what else is this thread about? :))
They aren't equivalent! Tabs carry more semantic information than spaces. 1 Tab character == 1 Level of nesting
Space-based systems _can_ provide the equivalent semantic information if they are 100% consistent.
...but part of the argument in favor of spaces is that they allow an escape hatch of the strict indentation in order to allow pleasing visual alignments.
Literally implemented PR guards today to prevent the team merging any dependencies that didn’t have explicit versions pinned (and that matched the resolution in the lock file).
People lamented semver not being trustable but that ship sailed a long time ago, and supply chain attacks are going to get worse before they get better.
Our team is pretty minimal when it comes to enforced hooks (everyone has their own workflow) but no one could come up with an objection to this one.
> In theory this should be nirvana. No more vibe coding! Everyone is a power user. Zero dependencies. But there will be much weeping.
If I had to sum up the zeitgeist of the '90s techno-optimism it would be this persistent, confident prediction that once people just learned _how_ to use computers, and everyone is a power user everything will be fine! Despite the mounting evidence that actually, no, like everything else in reality the distribution of skill is a bell-curve with the median sitting uncomfortably low for those who, to quote OP, "lived on IRC or in the bash terminal".
Free universal education didn't fix this problem, LLMs won't fix this problem. Man's natural paucity is no longer in the availability or accessibility of knowledge. The liberal ideal that all we must do is empower the individual turns out to not have been the solution to everything forever.
But hey, being self-aware enough to make productive use of this new technology is probably _some_ kind of edge.
Yep: It's a cheap tiny factory you control that's big enough for your unique priorities! Every person would own the means of production!
I don't think the assumption was that everyone would write software, but that they'd at least they'd choose in a way that favored future independence of choice. It's depressing to see the arc from "tool that grants autonomy" to "tool for delivery of product from megacorp."
> Gridland is the successor to Ink Web (ink-web.dev) which is the same concept, but using Ink + xterm.js. After building Ink Web, we continued experimenting and found that using OpenTUI and a canvas renderer performed better with less flickering and nearly instant load times.
Ah, I was wondering how this was different to xterm.js embedded in a page. It's just the performance angle? I've been teaching the kids programming from the terminal and I've been planning to make the jump from the terminal to a terminal in the browser as we hit graphical limitations (and as they want to be able to share their games). I'll take it for a spin.
(and if nothing else, I'm going to steal that ripple effect for them ;) )*
Yep, mainly performance - specifically page load time (near instant for Gridland vs ~2-3s for Ink Web). The other issue was flickering. Tbh rendering directly into a canvas is just a better approach and OpenTUI's architect is more modern.
I love that xkcd, I never know what to do, so I'll just ：）)
Can confirm good canvas renderer performance. Just tested it with a real-time smart meter dashboard — 62 meters streaming over MQTT via JustinX.ai (our data ingestion platform), 60 msg/s (peak), 500ms refresh. Almost no flicker, smooth updates across all meter cards. Much nicer way to handle high-frequency streaming data than xterm.js.
Reading this thread I'm reassured that despite everything AI may disrupt, humans arguing past each other about philosophy of knowledge and epistemology on internet forums is safe :')
Do they need 1000 frontend developers?
Aside from the Giants maybe some consultancies or hire-firms have that many? But they use whatever the client uses. If you're not in the business of selling frontend development services then a big part of your competitive advantage is _being able_ to make technology choices that are more-optimal than the labor market's lowest-common-denominator slurry.
Between JS/ECMAscript being abandonware for a decade and CSS' historical immaturity (cross-browser layout, custom properties, more pseudoclasses, etc) the Web was more of a wild west "whatever you we can cobble together" place. So of course we built an entire toolchain ecosystem for all the cool new tools we would reinvent from scratch.
but Things Are Pretty Good these days. We even have the world's only fully system portable assembly language: WASM! And the browser's Web APIs are becoming something like the missing Standard Library (shoutout to Deno).
The author's point seems to be that we are past a tipping point where we need all that additional complexity. You don't _need_ a separate system of reactivity these days, you can write a (closer to pre-hooks React, even!) React-style component library with Web Components now.
Personally I would need for Type Annotations to be a fully supported part of the spec before I made the point to "use the platform" professionally. Until some market force causes the core web technologies to truly fork my skills are useful for life. It's like a pale shadow of how UNIX users must feel :')