The JavaScript era happened because we were fed a line
spicyweb.dev
spicyweb.dev
"Gaslighting" is an important term for someone messing with your perception, so you begin to fundamentally doubt your own feelings and experiences. It only works in contexts where there is an important relationship, e.g. a boss, or a partner, and over time. Not every simple lie is "gaslighting".
Same for "toxicity". An asshole is not toxic. A forum full of nazis is not toxic. An important element for real "toxicity" is something _attractive_, something that pulls you in, and keeps pulling you back in even when you are hurt.
If people continue to abuse these terms, they are watering down important terms for something that is really, really harmful. I'm not saying being lied to is not violence, or that an asshole is not an asshole. But there is no comparison to REAL gaslighting and REAL toxicity.
For instance you could almost figure out what ‘anti-racism’ is based on the composition rules of language. (But you might think “anti-“ means “opposed to” whereas “anti-“ as in anti-matter is more like it according to Coates.)
Someone who went to the movies might dimly understand the “pills” (or do some people just take a lot of drugs?). On the other hand you could never figure out “chad”, and “stacey” without explanation.
Shaka, when the walls fell.
Or, you know, context.
I don’t know what a Stan is but could easily understand what they were referring to by the way they used the word.
Incels? What’s that? Pots that call the kettles black?
https://www.urbandictionary.com/define.php?term=Stan
I had to look it up; I was under the mistaken impression that Stan was the male equivalent of Karen, but I guess there are some similarities between them.
And that is the force behind many of the cargo cults.
"I spoke to everyone" is, by definition, not a single statement.
Everyone telling you you're wrong definitely can instill doubts about your perception.
Continously being told to "be wrong" can instill such doubts, but more precisely it would be me worrying about you "seeing it wrong", not accusing you of _being_ wrong about something. Your quote does not necessarily carry that meaning.
I am your friend, trust me.
That's precisely how forums full of Nazis get recruits; by being attractive to folks trending in that direction.
This is precisely the case with cultish groups like neo-Nazis.
They draw vulnerable/disaffected people in, they have attractive elements (sense of community, us-versus-the-world, positive feedback on traits others see as negative) that make it hard to leave, and they hurt you (job loss, friends and family disown you, reinforcement of those negative traits).
The key thing is, sooner or later just like a pond full of toxic mining waste, the toxic waste seeps through and eventually the dams fully break.
We've seen exactly this in politics - it began with Trump and others spreading "birther" conspiracy myths in the Obama time, progressed with the Tea Party and culminated in a full-blown coup attempt where mass casualties were only barely averted.
If you just let a pond of toxic waste accumulate and don't do anything to clean it up, you will inevitably head towards disaster.
People will have their opinions, they might be wrong, and things evolve over time.
No one is trying to work against you and sabotage your projects. It's up to you to use your expertise to figure out what's actually the best way to do something, even if it's not the popular opinion.
And, this might be a bit of a cheap shot, but people that write rage blog posts with bolded words are generally a pain to work with professionally.
Same for toxicity, where I actually do not even agree to your definition: toxicity refers to something toxic, you are the one adding the “codependency” aspect but it works well without it. There’s no such thing as “real toxicity” btw. Or should a biologist forbid you to use the term because it originally refers to poisonous creatures and not relationships?
Anyway, would you please consider not trying to gate-keep the use of words?
I did not say it can only be used for personal relationships. I said it only _works_ in such relationships. Because that is a fact, once we narrow it down to its original definition.
Of course you are free to use whatever words for whatever you want. But it means someone who wants to be able to clearly communicate loses their ability to do so. I am asking people to reconsider, and be precise. If you call that "gate-keeping", we can start a whole new conversation about what "gate-keeping" actually _means_. Because if we do not agree on definitions of words, we simply can not communicate with each other.
“I did not say it can only be used for personal relationships. I said it only _works_ in such relationships.”
I didn’t say I was right, I said you were wrong, and this is a fact. …
IMO this use is not unclear or imprecise. And you were previously arguing that it was important because “they are watering down important terms“, but now you say it’s about communicating more efficiently. You are inconsistent.
This is exactly what gaslighting is, a trusted person changing your perception.
I'm not sure if you already read all the above in the article, and know it/are willfully setting it aside to create a fake argument against their statements, or you just disagree with their statements, or you don't think the author is genuine.
Did you just want to have a discussion about those terms and made the conversational leap?
Thanks for setting me straight on that!
Well, not always. A gaslighting, especially when you are the target of it, will look as something completely inexplicable and without a central point.
Do you remember who you first heard about the wonderful AngularJS from? Personally, I don't. But information about it was pouring in everywhere. At some point, several companies where I worked started massively adopting Angular. In the end it was a complete disaster. A huge amount of code was written, all that code went to the trash because it was unmaintainable and unextensible (although the advertising posters promised otherwise).
Do you remember who you first heard about the wonderful React from? Did somebody told you that there is some magic thing called ShadowDOM and it solves all the problems, even better then Blockchain and ChatGPT does? But many years later it was revealed that actually it does not. Now we all are just slaves of old myths massively produced by Google/Microsoft/Facebook back in the days. That's what gaslighting is all about.
Re AngularJS: Nope, I don't remember who. I feel that the reason I heard about AngularJS so much was because Google saturated the market with meetups, events and funding. It was an intentional choice to brute force market/mindshare.
Even if it weren't in many cases the exact same pundits offering the nearly-identical praise while disappearing their previous plaudits down a memory hole, it would still qualify as gaslighting because collectively, an entire industry of experts has decided to act as if history began the moment they started to type, and that the collective previous claims of the group don't exist any more.
If you watched the movie and didn't see how the situation could possibly apply beyond a husband/wife relationship, then I suppose you watch movies differently than I do. If you instead picked up on popular usage of the term without watching the movie, then I suppose might not understand the actual meaning of the term. But if you're defending terms you clearly don't fully understand yourself, please, leave the terms to defend themselves.
Laurie Voss, one of the focusses of the article, is not one of these people.
So can you give an example of one of the “many people” who did this?
If not then your post reduces to a claim that two people who have never met and may disagree in good faith are gaslighting a third person if they work in the same industry. Which seems like a stretch.
Toxic means poisonous.
I think you're talking about addiction.
Which, along with the author's "you were sold something" angle - seems perfectly appropriate. He's saying you were lied to on purpose, you were told to doubt your own experience. That's gaslighting in this context.
> Because maybe I’ll still be fine and alive and kicking by then—but all those bright-eyed eager newcomers getting churned out of code schools knowing only React?
> Those jobs will be gone.
I find this faux concern tacked on at the end unconvincing. Everyone who's been in tech a while has learned some things that proved to have a short half-life. It doesn't mean they are doomed, they just learn the next thing and keep on going as progress marches on. For example, the poor ROI of my investment in learning jQuery in 2013 has not stopped me from having a very enjoyable career these last 10 years.
I'm no React zealot and will tell you I intentionally avoid trying to build frontend expertise because these things tend to fall away so quickly. But despite my healthy skepticism, I genuinely don't understand the angry and bullying tone coming across in these type of articles lately. If you don't want to use React, don't use it. It's very simple. I don't see why it's so offensive to you that others are making different choices.
When you say "I don’t think most React developers have evaluated shit!" and call their decisions/preferences "ludicrous", the only thing that comes across is that you apply "I don't agree, therefore others are stupid" as your primary lens. Which, fine, if that's how you want to conduct yourself. But it's not the sort of approach I look for in my leadership.
Uh, it's literally in the second paragraph:
'I’m mad because I’ve been hearing this line of thinking for years from many different sources, and—just like Alex—I feel in the strongest possible terms that it’s “astonishingly, gobsmackingly effective bullshit.”'
This is a theme that's threaded throughout the piece. For example:
'I kid you not, I was emphatically informed that my skills as a Ruby on Rails web developer were no longer relevant to “modern” developer practice.'
The point is: The author feels like they are the ones that have been bullied, for years, by folks pushing the SPA hype cycle, and 'ridiculed ... for [their] choice of technology stack/language/etc'.
And I can't really blame them.
Every round of tech hype sounds about the same. Object Oriented programming. The network is the computer. SCRUM. Mobile apps. SPA. Micro-services. Cloud. Serverless. They make it sound like the savior of all that ails you, but the reality is always more nuanced. It's like this in more than just tech.
There are interesting ideas in all of them, places they could be used and places they shouldn't. The reality never matches the hype train. The more experienced I get the more I generally want tried, true, and longevity to be attributes of the stack I pick. This seldom intersects with hype.
Unplug a bit from the online echo chambers preaching this stuff and you won't feel so "bullied".
That spreads to other areas as well and you are not included in technical discussions that are not frontend related. I guess the rationale is that someone who is not up to date in React, are probably not up to date in databases or architecture either. So you get junior developers not really listening to advice from seniors because they are not in the right group...
It isn't like this isn't a problem outside of web development, either. Imagine getting hired to maintain some legacy engineering software with a GUI built in Delphi and a backend written in Fortran...
Because those choices have had a major negative impact on everyone, especially and most importantly and significantly on the people who visit those websites.
It's all about problems with the DOM, specifically about three problems: it's too opinionated, too inflexible and on top baked into browsers.
Javascript frameworks try to provide solutions to those problems, but they can only hide them, not fundamentally fix them. Because they can only implement their idea of how a 'perfect DOM' would look like by adding more code layers on top of it, but not replace it.
The alternative is to do everything yourself in a canvas, but now 90% of the browser's features are useless, because they are all integrated with the DOM.
And that is the root of all problems: the browser lacks a proper API layer model where the low level layers (2D canvas, WebGL, WebGPU) sit at the bottom, medium level layers (e.g. for text, image and vector rendering, a layout engine and an accessability API) sits in the middle, and on top of everything the DOM. Instead all we have is either too inflexible and too high level (the DOM) or too low level for many tasks (WebGL or WebGPU).
Same for audio btw, there should be a low level streaming API at the bottom, a medium level 'mixer API', and WebAudio should only come in on top of those (or even kicked out of the browser and implemented in a JS or WASM library).
...of course this all means: lets get even more Javascript and WASM into web pages, which will anger the 'web boomers' greatly I guess :D
What does OP think is underpinning the browser's implementation of the DOM? Or Audio, for that matter?
Those low level apis exist, and they could be exposed, but there's a whole lot of reasons they aren't. To list a few...
1. The browser is handling all of the platform differences for you. The issue with low level control is... you have to understand the low level details, and those tend to be architecture & platform specific. Blink in chrome is just neatly hiding the fact that under the hood it's got considerable differences for each platform. It's having to deal with OpenGL, Vulkan, DirectX, etc. And they are ALL different. So if I use the intermediate DOM layer Chromium provides, I get immediate support for 6 platforms (Windows, Linux, Mac, ChromeOS, Fuchsia, Android) plus unofficial support on BSD (at least OpenBSD and FreeBSD). Using the low level api... I don't have time to write a website, I'm too busy trying to read graphics api docs.
2. There is huge value in having a selection of premade utilities to work with - The honest answer is that most websites are just forms. Microsoft knew that most apps are forms way before the web (WinForms). So if you really just need to have the user enter some data, and then see a new page a framework that provides you with those tools is a huge win. This is why things like QT, WinForms, and the DOM exist - they give you an easy way to quickly make forms. Of the three - the DOM is by far my preferred. It's actually an insanely capable engine for forms.
3. The last (and arguably most important) point is that the browser is enabling you to run untrusted 3rd party software. It's not giving that software low level access because it's sandboxing your system from it to give you at least a modicum of trust that you can open a webpage and not have your whole machine compromised. Low level access is powerful, flexible, and complex. I don't want a site to be able to access my microphone or files or usb devices without control over it... because I click random links on sites like HN all day long.
In the end, you get somewhat a least-common denominator since it's abstracting so much. It's both constraining (you don't get the full power of the platform(s) you're building for), and enabling (you get to build once, run everywhere).
...these "low level browser APIs" would still be regular Javascript web APIs which hide the differences between operating systems (that's the whole point of the browser after all!). E.g. WebGPU can still be considered a low-level API (when compared to other web APIs, but of course slightly higher level when compared to native APIs it sits on: D3D, Vk and Metal). Such wrapper APIs are not exactly rocket science, they can be both efficient and safe, yet still abstract over platform differences.
> 2. ...most websites are just forms
...this is a fundamental difference in opinion I guess. I see the web mainly as an open app distribution platform, not as a library for documents.
> 3. ...about trust...
See point 1 about WebGPU.
Safety aspects aside, you can look at game engines on how to build cross-platform APIs without giving up performance. In the end, most operating systems offer the same services in slightly different flavours, and it's possible to wrap those OS services in cross-platform APIs without too many compromises (after all, Windows, Linux, macOS, iOS and Android are all sitting on top of the same hardware anyway)
I would suggest this is not nearly as easy as you claim.
Game engines are actually fine example of exactly what I'm talking about - Unreal might have an abstraction that wraps over system differences, but to access low level apis devs bail on it.
Take a recent game: Atomic Heart. Built with Unreal Engine 4, which claims to support: Windows, macOS, and Linux PCs; PlayStation 4, PlayStation 5, Xbox One, Xbox Series X, and Nintendo Switch; and iOS and Android mobile devices.
Platforms that they actually released on? Xbox Series X|S, Xbox One, Windows 10/11, PS4/5.
Why? Because the abstraction turned out to not abstract so well, and they didn't bother to do the platform work required for the others.
Does it run on Linux? Sort of... it runs on linux presenting the same abi as Windows through proton/wine.
And even then, they have a ton of reported issues with performance (stuttering, frame drops, screens failing to load, unable to pause) on xbox consoles.
Which they've explicitly spent time and effort on making sure the game at least sort of works.
---
Basically - No, this sort of abstraction is hardly easy. Realistically, it's right on up there with rocket science.
Last note: What hardware do you think an M1/2 mac is running on? Or an iphone? Or an old BSD machine? Or a Windows machine? Because I've spotted about three different entire ARCHITECTUREs there (x86, x64, ARM64). Not even accounting for differences based with the GPU (or lack thereof). The OS is already trying pretty hard to paper over those differences for you as a application developer...
So I'm excited to see where we get with webGPU, but if you think it's equivalent to a low level api... I'm not really sure I agree. Plus it's explicitly not functional on... basically anything right now. Take a peak: https://caniuse.com/webgpu
> Why? ...
...not really, these are business reasons, plain and simple.
The problem with games on Linux is that the market is too small, the technical problems could be overcome if there would be a will and enough money thrown at it (see Steam Deck and Proton where this approach works pretty well) - for instance the technical problems for games on Android are arguably worse, yet the market is big enough that game developers have enough incentives to deal with those problems.
Also WebGPU is not released yet, so looking at caniuse is not really useful.
As for the last point: the CPU's ISA is the least of the problems. Most applications are no longer coded by hand in assembly.
Apart from being slightly faster, I see no difference between coding on an M1 Mac versus an Intel Mac or even a Windows or Linux machine (exactly because I hardly code in assembly these days).
My (same) code runs on all of those, plus the web, iOS and Android (granted I wrote my own set of wrapper libs to make this easy: https://github.com/floooh/sokol - but it's not like that's the only slim solution for cross-platform code).
Guess we're agreeing?
> Microsoft knew that most apps are forms way before the web (WinForms)
Windows Forms was initially released in early 2002 with .NET Framework 1.0, which _also_ shipped ASP.NET Web Forms (which was a crime against HTTP) - but the forms analogy for Windows apps goes back much further - at least to Visual Basic in the early 90s.
> So if I use the intermediate DOM layer Chromium provides, I get immediate support for 6 platforms
You get the ability to display things to users of those and interact with those users, not support for them as platforms.
> You get the ability to display things to users of those and interact with those users, not support for them as platforms.
I'm not clear on the distinction you're trying to make here. The browser functions as expected on those platforms (with the usual caveats around hardware capabilities limiting some use-cases). I'm targeting the browser to get wide support.
The fact that the web ignores most rules of platform design (because it was never meant to be one) isn't really a new observation. Most platforms build their higher level APIs on top of their lower level ones, so you can always drop down a level if the higher levels aren't working for you. You've got a widget toolkit but you can render your own and if you do you aren't losing anything else because you're using the same lower levels as the OS widgets.
So why doesn't HTML work that way? Partly path dependency, partly philosophy and partly the difficulty of sandboxing low level code, as the sibling comment observes. However, the latter has been getting easier with time as operating system kernels improve their sandboxing abilities. It's also not always necessary. Do I care if Slack or Hacker News is sandboxed? Not really. Some sandboxing is nice just for peace of mind against security exploits but I do actually trust these brands and don't think they're going to exploit me. A more aggressive sandbox is useful when following links to random unknowns like people's blogs, but the web's design doesn't recognize that such a thing as gradients of trust exist.
An alternative approach would be to reject the attempt to write a giant spec for all of computing, and instead embrace competition, diversity and layering. Start with a small core that knows how to download files and compose them together. It can fetch native apps into an HTTP cache, update them efficiently, execute them and delete them when the cache gets full. At that bottom layer the core enforces the platform's native security mechanisms (code signing, GateKeeper, SmartScreen etc). Then allow people to create native sandboxing apps that can be composed with other code to run that other code inside kernel level sandboxes. Responsibility flows downwards, so it's the sandboxing app that takes the risk of being blocked as malware if it fails in its core duty. Then you can compose VMs with the kernel sandboxing apps, and at each layer of the cake you're exposing IPC APIs that allow apps to e.g. allow their GUI to be embedded in a browser-style tabbed WM, to abstract and sandbox the platform's native accessibility APIs, to support form auto-fill and all the other features you might want.
Such a thing would be quite different to the web, for example it would naturally support command line apps and servers. It would also be less centrally planned, as the core would mostly be a kind of dependency resolver that ensures components can be connected together across sandboxed IPC boundaries and provides some level of UI sharing beyond the native window manager. The spec would be minimal - the downside is the user-agent would be less generically powerful because you aren't forcing everything into a single model, the upside is the spec would actually be implementable because it's not trying to do anything.
The design I've got also allows for document formats, crawling/indexing, authentication and other things that are useful to have in a web competitor, but there's no space to go into all that right now.
The biggest problem is one of incentives. Google's bottomless pockets makes browsers fat but also kills any incentive to compete, as there's no obvious way to pay for the maintenance of any alternative. Having a small and tight core spec helps, but someone still has to do some work. Apple solve it by selling hardware but nobody else has a workable economic model.
I wonder if it's important to expose something close to each platform's accessibility API to sandboxed applications, or only the cross-platform abstraction over those APIs. For the latter, my AccessKit [1] project might be worth looking at.
AccessKit certainly looks highly competent - putting an Mojo RPC interface over it would be a good way to expose an abstraction over platform specific a11y interfaces. And of course there's no rule that says an abstraction must always provide just the lowest common denominator. Abstractions can also expose platform specific features for the unique stuff that can't be properly abstracted.
I suspect a11y APIs will gain significant importance this decade, once people realize they can hook AI up to accessibility trees more easily than working with pixels and the like.
> I suspect a11y APIs will gain significant importance this decade, once people realize they can hook AI up to accessibility trees more easily than working with pixels and the like.
I hadn't considered that programmatic accessibility might be helpful for AI applications. Within the accessibility community, AI is more often seen as a provider, i.e. filling in accessibility gaps, through OCR and now more advanced applications of machine learning such as iOS's Screen Recognition. But I hope you're right.
I think accessibility becomes a lot more exciting to developers once they re-envision it as a general purpose API to expose application interfaces without being drowned in markup or other incidental complexity. The 90s concept was that apps should expose a GUI widget tree to end users and an OOP RPC API to other applications, with MS Office being the cheerleader for this approach. But it never caught on because exposing an API feels too much like a tax for most apps - it's hard to know what other devs might want, making it hard to design an API for them, API design is itself quite taxing and then finally what is the stability level like? You also have the question of what RPC system to use, what type system ... it's complex. Exporting a generic RPC API in the form of a11y trees is an interesting middle ground. It's clear that it's not a stability commitment, but at the same time it's more stable and easier to work with than raw screen scraping.
Note his comments on the HN thread in particular where he talks about how the web essentially "failed" as an application platform and is only held up by modern frameworks which essentially have to work around its limitations with virtual DOMs and polyfills. As we go towards more and and more languages supporting WASM and wanting UI, such as Rust with iced, we should have a common set of components and APIs so that each language is not building their own custom components in WASM, which would defeat the point of interoperability, at least at the UI layer.
And you're right about the web boomers, the HN thread shows them very angry indeed ;)
What makes you disappointed by Ian, just curious?
There's a long, long line of flash-in-the-pan frameworks that never really gained traction -- and then there's React (which _isn't_ a framework, but fine, let's roll with it). AngularJS, Angular, Vue, Svelte, Preact, Ember, etc all contributed to the ecosystem and then more-or-less faded into relative obscurity. But for all that time -- since 2014! -- React has done nothing but grow _even more popular_. It's not like React is an equal choice among others; if you're building a non-trivial web application in 2023, it's the default choice and the only one you _don't_ have to justify.
We let a million flowers bloom, it was chaotic and confusing, and now that time is...mostly past. I'd have more sympathy with TFA if it had been written in, say, 2017 -- but to assert that "React could just fade away like AngularJS!" in 2023 is just willfully blind to reality.
The US scene seems to favour React though. Even though React is there from 2014, the way we code React now is much different that how it was done 5 years ago. Also in React fads keep coming and going in the library ecosystem. In contrast Angular hasn't changed much from the developer's perspective.
Over here it might seem like these frameworks are the one and only way forward, but in the real world, where things need to work for many years, they are just someone else's way of reinventing the wheel so they can iconoclast the living shit out of a job title.
It took me about 6 years of working at the same organization as a senior swe and de-facto engineering manager to really understand this. Nobody wants cool cutting edge software except artists; businesses want durable products and services. Only on the edge of creativity apps do you need _very_ reactive UX.
In the early half of those 4 years, we built a RoR app. React landed in the middle of that. I'm proficient in JS, and we are moving around a lot of data on the client, and `props` and reusable components felt right. Then we built our next app front end all React+Redux w/ Rails API. Then the next app was Nuxt2 + Rails API (I gave my team time to play with Vue and Svelte after a year with React — everyone preferred the Vue DX).
Now we have a Nuxt2 app that is stuck in the past unless we spend some real fun times reading docs and doing `npm audit`. Meanwhile the OG app still works fine, but the front-end is 6yo React garbage. I think we'll probably wind up transitioning a lot of it back to ERB templates and using Stimulus when needed.
But components, man. Componetizing chunks of html+css+js as single file components is incredibly useful, so much so that folks are experimenting with how they may work in an environment like Rails in a durable, rails-y way.
I didn't like using the statically-served web and I especially didn't enjoy developing with the HTML-via-AJAX approach back in the day.
Like it or not there's a lot of additional interactivity which JS affords us that is nowadays taken for granted by users - advanced validation in real time being just one of them.
That being said:
> There has been a small but mighty ecosystem of “influencers” peddling a sort of “pop culture developer abstractions” ethos on the web whether it’s about React, or CSS-in-JS, or Tailwind CSS, or “serverless”, or “microservices”, or (fill in the blank really)—and they’re continuing to gaslight and obfuscate the actual debates that matter.
100% this. I've met people who were high on this sort of koolaid and there was really no reasoning with them.
Interestingly, it's mostly the React community. They seem to bravely solve problems unknown in other frameworks - CSS especially was largely solved everywhere else.
I'm happy that next-generation frameworks like Svelte or Solid picked up on mistakes made in the previous decade and largely don't repeat them. You have progressive enchantment and predictable abstractions.
But chiefly they have something I never thought I would see again on the front-end: a meaningful, readable stack trace.
The main reason the JavaScript era happened is because HTML ceased to move forward as a hypermedia. This pushed people into more and more scripting to achieve user experiences, which eventually required the use of frameworks to manage the complexity. If HTML had continued to increase in its hypermedia expressiveness, a lot of pain and anger could have been avoided.
(full disclosure, I have a dog in this fight: https://htmx.org)
The fact HTML stalled as a hypermedia was then coupled with the fact that first-wave web thought leaders got interested in "web services" (aka APIs) and ended up going down the JSON-APIs-are-RESTful[1] rabbit hole meant that hypermedia, the only real alternative to JavaScript-maximalism for more elaborate user experiences, floundered as a concept.
Meanwhile, say what one will, but the JavaScript-maximalist community was making progress and talking about it loudly.
[1]- https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...
I think you have cause and effect reversed; Java, JS, Flash, and other non-HTML technologies appeared on the web very early on, and are the reason the evolution of HTML as hypermedia stalled; when it resumed, JS was so well established as a complement that even what evolution of HTML as hypermedia occurred was generally JS dependent.
The JavaScript maximalist era didn't really come into existence until post 2010 with the release of Angular, which was two years after the release of HTML5. HTML5 included canvas as a reaction to flash (and the long-since-effectively-dead java applets.)
So HTML was making progress, but that progress was mainly in terms of front-end, thick-client style features, driven by, yes, the JavaScript (and flash) technologies. But what it wasn't doing was making progress as a hypermedia (e.g. adding new hypermedia controls or, as with htmx, making all elements hypermedia controls.)
As to the cause of this lack of progress as a hypermedia, I agree with you that it was due, at least in part, to the other front-end technologies, as well as a lack of appreciation for the hypermedia model (which is why I mention the thought leaders going down the webservices/JSON API rabbit hole.)
How many loading spinners do they have to see just to get to what they're looking for? Between frontend frameworks, marketing analytics scripts (aka tracking) and crap UXs* we're moving sideways not forward. On a typical mobile device with a typical connection the internet has often become a health hazard (i.e., increase in stress and blood pressure).
* True story: Last month I went to pay a bill online for a major health insurance provider. After 3 or 4 tries with my Amex I concluded they don't accept Amex. But there was no icons to communicate what they did accept. No validation to say "we don't take that card", and no error msg either. But I bet it was built with Angular or React. I understand. That's not the engineeers' role. Perhaps. But if we're freeing up resources why are experiences like this happening? Why are sites like adidas and Home Depot so marginal on my mobile device?
I wish I could be angry. But I'm too beaten down to fight back at this point.
Great selling point ;)
Sadly, somewhere there's a VP of Marketing losing sleep over the color of their spinner and how fast it spins. "What if we didn't have need for a spinner?" never crosses their mind.
A long loading spinner is a sign of a server-side problem in speed, not in the client.
and old-school MVC page-flipping code can be just as bad in error and validation reporting. Sometimes worse because maybe the form data was lost so you can't fix it.
You're talking about design problems that exist regardless of the layer that is involved in showing it. Nothing you've said here is a problem of the UX framework. I use react and we have very extensive error and validation reporting, because we made that a design requirement.
Anyway, the Current State of the Web happen because the world was desperate for a cross platform UI framework, the Web had it and everyone tried to make it universal UI framework and then NodeJS happened and the universal UI framework has become universal computing framework.
That's all it was.
All these JS frameworks are about trying to make the Web Browsers do something they are not designed for through the only programming languages they support.
Layers and layers and layers of it made it possible to code JS in ways it wasn't made for an all of it barely stays together.
You have a customer. You do a GET request to see if the custom exists, they don't. You whip open your HTML form to do a POST to input their details. So far so good. You realise you made a mistake, a simple typo, now you need to do a PUT request to update the details.
Oh wait, you can't. Doesn't make sense that you would want to do this, apparantly.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=10671#c16
Sure, you can add hidden _method inputs and so on on the form, but such hacks and workarounds shouldn't be necessary.
In modern webdev, HTML is just the payload carrier for the real website, which is the JS app. So long as HTML is intentionally crippled its folly to suggest otherwise.
Making highly interactive web apps in 2013 was painful and it is revisionist history to claim otherwise. Keyword being “highly interactive”. If you’ve been mostly building traditional sites then it’s a different situation.
The author says he likes Knockout… well, I respect Knockout too, but having spent many years maintaining a decade-old enterprise Knockout app, it is painfully clear that React was actually real progress.
These frameworks - warts and all - do solve real problems. Just as you shouldn’t trust someone who tells you they’re perfect, nor should you trust someone who dismisses them as a con.
It's on a domain called "spicyweb.dev".
What were you expecting by clicking on that link?
I mean, it is true that the SPA community has basically taken control of the frontend narrative. No beginner dipping their toes into webdev today can escape the gravity pull of React et al.
From the article:
> I’m angry because for the past decade of web development, I and so many others like me feel like we’ve been repeatedly gaslit, and that so many of the “merchants of complexity” refuse to acknowledge the harm that’s been done.
This I agree with. Beginners should start with generating HTML from their programming language of choice. Experts know better, but a complete beginner has no idea that this is the truth. Everywhere they're bombarded with frontend == React (or some other up and coming framework). Look at the amount of discussion generated by "Do I need to learn JavaScript before React?". This shouldn't even be a question, but you have people passionately arguing for the other side because "frameworks make your productive immediately, you can learn the basics later". The basics are HTML and CSS.
That said, this whole JS SPA stuff in general and React in particular was not propelled solely by these gaslighting influencers. There was at least one other thing that helped them to their current dominance: it turns out to be a really good idea to represent an app (i.e. business logic + UI) as a just-in-time data structure that is incrementally recomputed in response to changes in state and is shaped like a tree so as to track state dependencies via parent-child relationships. This kind of “reactive state tree” approach is genuinely powerful and brings significant and real advantages over model-view-controller approaches. It’s like a web-flavored microcosm of object-oriented vs functional programming. JS SPA (e.g. React) had this and server-side (e.g. Rails) did not. That difference, _alongside a tsunami of bullshit_, drove React’s supremacy over Rails.
If you’re defining your route handlers in an HTML templating language it is probably a sign that you took a wrong turn somewhere!
People have been arguing about languages, OS’, platforms, architecture for decades. I bet you can even find a grumpy engineer who thinks our tech should all be TTL instead of CMOS.
It sucks when your investment doesn’t pay off, but there’s not some grand conspiracy to deny your preference. People just like what they like.
You... really didn't read the article, did you?
In the opening they state: "My skills as a Ruby on Rails developer today are by far more valuable than any skills I would have gained pivoting to full-time AngularJS development in ~2014".
Doesn't sound like someone who's worried that their "investment [didn't] pay off".
Hell, they even close it with: "In the year 2033, I am 100% convinced my skills as a Ruby web developer will be by far more valuable than any skills gained learning React…"
Seriously, I get it. You don't agree with the author. Cool.
But why make up some fictional motivation like this?
> We were told writing apps... using our preferred language/tech stack of choice, was outdated and bad for users.
> how do you trust developer communities which have been overrun by people who are giving you false and misleading information on a regular basis
> No, YOU—the JS-framework-stans—intentionally created a world that excluded those of us
I guess we took different things away from the article.
Punchy sentences masquerading as paragraphs
*But*
What's the point? I don't know. I gave up. I'm not wasting time on someone who can't cut to the chase.
I'm one of these "backend" developers, and let me tell you the reason why: it's ridiculous that you can't grab a project that hasn't been touched for two years and not waste at least half a day getting it to build again. In contrast, environments like PHP or hell even Python and Java (that are complexity nightmares on their own) have a vastly different experience. Or your plain old jQuery project from 2010-ish - it will still run just as it did back then.
Backwards compatibility, "think and design properly before you code", "don't reinvent the wheel" are all things that the JS community at large is lacking for decades, and keeping up with the insane amount of churn is the most ridiculous expectation that it has.
Side note: The fad of nosql databases is similarly bad - they've been re-learning all the lessons of 40-ish years of people running databases at scale from scratch. Yes, their projects initially seemed easier to use and more resource-efficient to run - but inevitably grew to the same level of complexity as conventional databases do, because people were expecting the same guarantees (i.e. ACID). In the end, a ton of development work was lost unnecessarily.
Even then I'd think I'd fixed it to the right version on my home server, copy the code to the prod host, supposedly on the same php version, and yet I still had issues (specifically with the MySQL layer).
Then there's the matter that having gotten stuff to work with a particular library, the library is deprecated for security risks, isn't going to get fixed and I have to rip it out and replace it with something else (if that something else even exists).
So yeah, back-end has just much versioning crap and loss of backwards compatibility that the front-end does. The engine may be fine, but the libraries are a moving target just as much as any other language. You may have somehow avoided it with the libraries you've used. I've yet to be so lucky, and pretty much gave up on any future PHP 'cause I just don't care to keep up with it.
You can see it in DevOps (we apparently accepted paying a ~100x markups on servers, so now we have to add complexity such as autoscaling to try and pay less), microservices (why use a simple local function call when you can have network/serialization overhead and unreliability instead?), etc.
Making Laurie’s post all about React, is taking it out of context, on the verge of gaslighting that author is accusing others of
Don't measure your worth as a developer by counting the years you know some framework. Measure your worth in your ability to adapt to trends and learn new things. I'm not saying don't be an expert -- there's plenty of time for that. And then that technology you're an expert in will die and you can do it all over again in another one.
If you want a long career, consider this strategy over one where you gatekeep or clutch pearls.
My next project will use https://github.com/leptos-rs/start-axum , because it's superior technology in terms of speed when you compare it to VDOM frontend frameworks.
Thank you for this!
I don't think they articulate the problem particularly well, or the solution for that matter, but the sentiment is spot on.
The second problem is that rather then writing fast software, you are incentivized to write the software as fast as possible.
The third problem is that the ones buying/paying the software are not the ones using the software.
The fourth problem is that software engineering is highly fashion driven.
The software layers though, they are there for a reason. Although I'm not a fan of stacking frameworks. I think the optimal is 2-3 layers between the hardware and the developer. The problem is leaking abstraction layers.
The situation reminds me of desktop GUIs for example. While everyone was busy jumping from VB to .NET to Electron I used Delphi for desktop. The resulting apps are single exe with 0 dependencies, deployable by copy and the one I made 20 years ago still works like a charm. Instead I could concentrate on domain and save tons of time and money.
I guess this is directed at people who take cargo cult blog spam seriously? or people who are debating what to learn? If its the latter, the entire post could be rewritten in a positive way that explains the value of learning the fundamentals. That would've been more productive than whatever this is.
I think the author has some valid points. I agree vanilla JS and SSR is a better fit for a lot of situations.
(I will admit some bias as someone who's mainly worked in Angular-Typescript)
AngularJs started gaining traction around the rise of "apps" and the iPhone.
SPA was a way to have an "app" in the browser with all the complexity that went with it. It also was a way to share an aritecture with mobile apps -- the browser is a client which calls the same public API as mobile devices.
Obviously you can call the same public API with SSR, (though it might have been more tricky before the rise of microservices), and not all webpages need to be "apps", but I think this was the argument at the time.
I think a lot has changed in 10+ years and those architectural decisions make less sense.
With static data and a form or two, SSR and vanilla JS is perfect. Resume-padding engineers might try to make it more complicated than it needs to be, but they're wrong.
I would not like to work on a complex web app with 10 other engineers that does not have some kind of component architecture.
AngularJS 1.0 was the first time I felt I could try to build a real quality app with web tech without going crazy.
Then I hit the wall with its crusty 2-way binding system, learned react, and never looked back.
Now I can do state manipulation tricks that would make past me's eyes pop out. Like wiring up undo/redo to a complex tree manipulation app by replacing a useState call with a useUndoableState, and describing every mutation in my app as a mix of data and lambdas, which can be reversed automatically without any custom code.
The building blocks are here: https://usegpu.live/docs/reference-live-@use-gpu-state
React has done so much for the web, people don't even know how shitty it used to be.
If all you're doing is building the same old websites, with the same old form-based interactions, instead of trying to put desktop-quality software on the web, then yeah it's overkill.
But don't tell me you're upset because you don't understand what this stuff is for and you've just been cargoculting for years. That's a you problem.
I've recently showed a Javascript React dev what can be achieved with Jupyter/Voilà/Streamlit/Dash and he was totally oblivious to the toolset's existence. Also I think he gulped. Only in the Javascript world do I see such insularity, and also maybe in some Java leftover shops.
Is it because learning it all is such a huge investment that you're in full-on Stockholm syndrome?
sadly at the moment these things are not yet that great, either because of things that are missing in the wasm spec or because of limitations or because there is simple no compilation to wasm (from the compiler itself)
what I'm angry about that, we have these browsers that can do a shit ton of stuff, but nobody ever tought about adding a more integrated and better language than javascript. all we've come up with was wasm, way to late and still misses a ton of important stuff for our compiled languages.
I did eventually get myself fired, but that's a different story ;)
Just like with covid[1].
On a serious note, the author mentions that his Rails skills are now even more valuable, so… still a win I guess?
1: https://www.theatlantic.com/ideas/archive/2022/10/covid-resp...
> The Web Was, Is, and Always Shall Be Polyglot
[1] https://github.com/cheatcode/joystick
[2] Please give it an honest a look and save the XKCD "muh standards" comic and accompanying snark for after you've taken it for a spin.