Hacker News new | past | comments | ask | show | jobs | submit login
The JavaScript era happened because we were fed a line (spicyweb.dev)
122 points by tambourine_man 23 days ago | hide | past | favorite | 129 comments



Please...

"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.


To add, these kind of tantrums are really irritating. I get people are passionate about what they do, but ultimately we're all just picking technologies based on what we think is best. Just like any other industry.

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.


The author called out a person of authority (many read their blog posts, and value that persons opinion) that is using the same rhetoric a decade apart for different platforms. Making promises about what the tech can provide, even though the first technology failed to provide it.

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?


> This is exactly what gaslighting is, a trusted person changing your perception

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.


For sure, I guess I was not attempting to define the bounds of gaslighting (I should have just said I disagreed that it was not gaslighting), and your cases are quite valid examples to call out.

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.


When did Laurie Voss advocate for Angular? I checked his blog and his Twitter and there is nothing pushing Angular in either.


Oh yeah, like you said I don't see that individual being called out as having an article for angularJS stating the same things. So that part of what I was saying is not accurate/the specific author did not try to pin that on Laurie as I said.

Thanks for setting me straight on that!


An industry expert telling you that X is the solution to everything, and then years later saying that Y is the solution to everything, without any acknowledgement whatsoever of their previous statement on the subject, is messing with perception on par with adjusting gas lamps and then denying it. The relationship exists, whether you recognize it or not.

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.


“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…”

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.


I don’t agree to your exclusive use of gaslighting for personal relationships, I think it’s fine to use it in any context that makes sense.

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?


Don't you see how it is important to differentiate between these two things? Do you have a suggestion on how to make it clear what you mean if you mix two very different meanings into one?

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.


It’s pretty clear in this context what the author meant. My suggestion would then be not to pretend otherwise. And, in general, pay attention to the context to understand what meaning of a word is being used.

“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.


"it means someone who wants to be able to clearly communicate loses their ability to do so" is a result of "watering down important terms". Where is the inconsistency?


I think it's being used in the sense of 'the industry' discouraging dissent about the universal applicability of JS application frameworks and SPAs, by trying to convince developers that their experiences with SSR and MPAs are not real, or not relevant. That yes, plain old html and css and vanilla javascript feel like they USED to be good enough, but they're not good enough anymore - for anything. That's the gaslighting bit - when you're instructed to doubt or de-value your own experiences and feelings. It's done on purpose, with intent to control.

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.


And what’s a Stan? Why does everybody sound like an Incel all of a sudden? Why does the most prescient part of Orwell’s 1984 be the part about about the impoverishment of language for political ends.


You're about 20 years too late regarding Stans. Also, where and how do they sound like incels?


Incels might be the most prominent example of a group with a large hermetic vocabulary that floats independently of the rules that govern neologisms.

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.


> On the other hand you could never figure out “chad”, and “stacey” without explanation.

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?


You are trying to lock down language with your own restrictive unstated rules, while also complaining about 1984 locking down language with rules?!

Shaka, when the walls fell.


stan is a reference to the eminem song of the same name, referring either to just being a big fan, or being unhealthily obsessed with something, depending on context.


"Stan" has been fairly mainstream slang for about twenty years [1]. Being out of touch with popular culture is not a sign of Orwellian thought control.

[1]: https://en.wikipedia.org/wiki/Stan_(song)


Looks like Stan is the archetype for an obsessive fan.

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.


Enriching language by creating new words for new ideas is the opposite of 1984.


"I spoke to everyone and they all think you are wrong" is a form of gaslighting.

And that is the force behind many of the cargo cults.


No. A single statement can never be gaslighting. Gaslighting is a process. Being told to be wrong (even if you may be correct) is not gaslighting either. The important element is to plant doubts about your _perception_.


I spoke to others and everyone is very disappointed of your comment. They do not want to say it, but I had to.

I am your friend, trust me.


> A single statement can never be gaslighting.

"I spoke to everyone" is, by definition, not a single statement.

Everyone telling you you're wrong definitely can instill doubts about your perception.


""I spoke to everyone and they all think I am wrong" is a different statement than "I spoke to everyone and they all think you are wrong".

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 talked to everyone that uses the term gas lighting and they all think your definition is too narrow.


> 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.

Toxic means poisonous.

I think you're talking about addiction.


> 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.

That's precisely how forums full of Nazis get recruits; by being attractive to folks trending in that direction.


I need to attract you, continuously, and then, in the same fashion, _hurt you_. Both elements need to be present for something to be toxic. If someone is "just" attracted, that's simply recruitment, and not toxic in itself.


If you don't think being recruited into neo-Nazism isn't a harmful thing, I'm not sure what to say.


That's not what I said, at all.


> I need to attract you, continuously, and then, in the same fashion, _hurt you_.

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).


I never said otherwise. I said a forum full of hatespeech/nazis is not _automatically_ a "toxic" place. It may be "violent", or "dangerous", and other things. If you can outright see what they are up to, and they are open about it, it is not toxic. Membership may indeed become toxic for particular individuals later on. I didn't say it won't.


Quit gaslighting your definition of toxic, Stan.


> I said a forum full of hatespeech/nazis is not _automatically_ a "toxic" place.

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.


I did not say or imply anything in that direction.


> …it fills me with dread.

> 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.


> I genuinely don't understand the angry and bullying tone coming across in these type of articles lately.

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.


So what? You got preached to. "Bullied" seems to strong. Now it's time to shout your displeasure to the world of it's unfairness?

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".


You may have a different experience than me. At my work place, if you mention experiences with "old" technology you are looked down upon and spoken to in a condescending attitude. I'm talking about common sense things like gzip compression and etags for huge downloads. This "magic" is relevant even though they haven't heard about it before as someone fresh out of college.

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...


Sounds like toxic workplace problems to me. Those are very not fun.


I just started a career in web development and do 95% of my work in React and I love it. I'm able to ship features for customers to use insanely quickly. When it falls out of favor and I need to learn Svelte (or whatever) my plan is to just... do that? It took me a week to start being productive in React.

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...


Exactly. Continuous learning is the job.


> I don't see why it's so offensive to you that others are making different choices.

Because those choices have had a major negative impact on everyone, especially and most importantly and significantly on the people who visit those websites.


As a 'somewhat' outsider (having found interest in the web mainly via asm.js and WASM) my take on the framework mess is this:

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


Yes, the browser is like a cool operating system you only can access from VBA in a Word Document. :-)


This seems like a really important fundamental observation. I hope other folks with different perspectives see this and weigh in.


At the risk of being a tad snarky...

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.


Yeah that's really it. The browser is essentially a cross-platform VM, not entirely unlike the JVM or BEAM.

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).


I agree with almost all of your post, but some nitpicks:

> 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.


Fair point on the windows forms analogy going back farther, and overlapping with the web by the 2000s. I was ~5 in 95, so it gets a bit hazy farther back.

> 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.


> 1. The browser is handling all of the platform differences for you.

...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)


> Such wrapper APIs are not exactly rocket science, they can be both efficient and safe, yet still abstract over platform differences.

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


> Platforms that they actually released on? Xbox Series X|S, Xbox One, Windows 10/11, PS4/5.

> 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).


So you're basically conceding that the abstraction for those game engines is leaky... and it's not sufficient to make the program work without considerable technical work specific to the platform?

Guess we're agreeing?


Over the past year or two I've been working on a (currently theoretical) design for a kind of pseudo-competitor to the web that's based on that observation.

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.


> to abstract and sandbox the platform's native accessibility APIs

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.

[1]: https://github.com/AccessKit/accesskit


Why not both? The idea behind allowing the sandbox to be pluggable is the sandbox authors can decide how and what to expose. If the sandbox author thinks it's safe to expose the native accessibility APIs directly it can, if they don't then they may wish to expose a platform-specific proxy emulation with extra validation (in the way that Chrome exports OpenGL into the sandbox), or they may wish to expose only a platform abstraction, and that platform abstraction could also be used outside of any sandboxes as well if the app is code signed.

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.


IMO, now that I think about this some more, letting a sandboxed app directly implement native accessibility APIs is risky. First, there's the fact that on Windows, macOS, and Linux (or more accurately, Unix desktop environments that use AT-SPI), the native accessibility API uses screen coordinates. So a provider exposing screen coordinates outside of its window seems like a vulnerability. AT-SPI is very trusting of the toolkit/application in general, with no verifiable link between the accessibility tree and the X11/Wayland windows/surfaces. And while I'm not aware of other specific vulnerabilities in UI Automation on Windows, I wouldn't be surprised to find that they exist. I'm the least familiar with the macOS accessibility API.

> 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.


Insightful, thanks. Yes - native operating system APIs are often not designed with sandboxing in mind, unlike on mobile. A big part of why people rely on the web so heavily can be summed up as the Chrome guys methodically working through native APIs and writing lots of code to make them sandbox-safe. I guess in this case it'd be the same thing. Someone would need to write a validation layer. Chrome's Mojo IPC is really nice, I've been playing with it lately. It's not available outside their source tree but isn't too hard to extract. Their sandbox API is ... less nice, barely an API at all actually, but nonetheless the two integrate with each other well.

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.


It might interest you to know that Windows screen reader developers used Office's COM object models to make the Office apps (especially the primary document views) accessible for a long time, going back to the early 2000s or late 90s. The third-party Windows screen readers (i.e. everyone but Narrator) are just now transitioning to using UI Automation for Office documents. Microsoft's original accessibility API, Active Accessibility, was way too simplistic, and even UIA only recently became rich and extensible enough to expose everything that screen readers got out of the Office object models.


You're exactly right. Ian Hickson, who wrote the HTML5 spec and is now the team lead on Flutter, notes this exact sentiment as well in the below piece, where like you said, we should have the different rendering layers you're talking about, with low level layers in WASM and canvas at the bottom and high level APIs at the top. Flutter actually works the same way, so I can see where he got this influence.

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 ;)

https://news.ycombinator.com/item?id=34612696


That's an interesting discussion, thanks for linking, but I was very disappointed by Ian. I guess that makes me a web boomer, regardless of my age.


Hah, looks like you're not alone based on what others have said on that thread about Ian not wanting to support features like navbars and instead wanted to support things like asides that really most people don't use.

What makes you disappointed by Ian, just curious?


Disregard for the web, its accessibility, openness. The guy was there at the sausage factory.


Well, like the root commenter said, the web is doing things now suboptimially because it was never designed to run apps, merely to display content.


Plus, you have to fight a lot with canvas and resource usage, compared to spitting markup with events around in the DOM


> How do you know your ability to write React apps today isn’t as much of an industry dead-end over the long arc of technological web history as was writing AngularJS apps 10 years ago? Seriously, how do you?

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.


As well, I don't expect recent frameworks like Svelte and Solid to stick around as well in large prominence, simply due to how they handle two way mutable state which is precisely the reason why React eschews that philosophy and takes the functional approach of immutable trees of nodes being updated somewhat efficiently. The OCaml inspiration is real.


Angular and Vue are still Alive


Angular is actually thriving in enterprise. There are many Angular projects in software houses which do backend in Java and Dot Net. There is a lot of demand for Angular developers in India at least.

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.


I never fell for the js meme. Not even now. As a software architect (meme enough of a job title) I have never pushed for js frameworks and reactivity. I work in an environment where decision actually matter, for 10 years they do... We need software that is going to work and is going to be maintainable and stable for that long. I have no time for cool kids and js frameworks that are going to change every year and deprecate functions on each pull request.

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.


> I work in an environment where decision actually matter, for 10 years they do... We need software that is going to work and is going to be maintainable and stable for that long.

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.


> We were told writing apps with an HTML-first, SSR-first, progressively enhanced mindset, using our preferred language/tech stack of choice, was outdated and bad for users. That was a lie.

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 reality is a bit more complex than this, although it is certainly the case that the Front End world has a lot of hype and, in my impression, some snobbery derived from the second-wave web-design world when the broader design community started taking an interest in the web (which was net a good thing.)

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...


> The main reason the JavaScript era happened is because HTML ceased to move forward as a hypermedia

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.


I don't really disagree with you regarding the cause of the HTML stall as hypermedia, although I still claim that it was the stall that directly pushed people into JavaScript maximalism.

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.)


Angry engineers? How about taking to typical internet users?

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.


I called out a design agency for putting a loading spinner in a concept video a few months ago. They at least had the decency to look a bit ashamed, but claimed it made the concept feel more “real” facepalmemoji


"We promise to craft an experience that forces your users / customers to wait..."

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.


That's pretty hilarious. But honestly I respect keeping expectations as realistic as possible. It's very likely the execution of it will have a loading graphic somewhere.


Well, pick your loading spinner. Either the screen has it for the fetch call, or the whole browser has it for the page-flip (sometimes with you just having a blank page while you wait).

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.


That's not gaslighting.

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.


Scenario:

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.


This is a disappointing and highly inflammatory article. There’s a nuanced and interesting discussion to be had here but the author chooses to demonise and insult entire communities. Does this rhetoric help anyone?

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.


> There’s a nuanced and interesting discussion to be had here but the author chooses to demonise and insult entire communities. Does this rhetoric help anyone?

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.


> This is a disappointing and highly inflammatory article.

It's on a domain called "spicyweb.dev".

What were you expecting by clicking on that link?


I believe the author when he says he feels gaslit into accepting JS SPA as the Only Way to Make Web Apps These Days. I have noticed a similar trend (though my particular neurodivergences have likely shielded me from most of the impact those pressures might have had on me).

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.


React isn’t the problem. Using React for everything is the problem.

If you’re defining your route handlers in an HTML templating language it is probably a sign that you took a wrong turn somewhere!


JSX is not a templating language. TypeScript is also great for route handlers since unlike most languages it has pseudo-dependent types so if your route is misspelled you are immediately notified.


This comes across as an angry rant that the author chose the less popular toolset. We’ve all done that. We all learn some toolset that seems great and then it gets plowed over by something else. As I recall, Angular was plowing over itself for a few years.

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.


> It sucks when your investment doesn’t pay off, but there’s not some grand conspiracy to deny your preference.

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?


I did really did read the article. And I stand by my statement. Even though they're comfortable with their Rails skills, the whole article reads to me like someone who didn't pick the winning horse.

> 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.


I'm amused the article starts with "I’ll cut to the chase." and ... doesn't. So much *bold text* and

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.


Yeah, I'm generally not a fan of React, I prefer the larger backend frameworks like Django that the author mentions, and I think SPAs are way overused, so I feel like the author might even have a point that I'd agree with, but I just can't make myself wade through all the self-righteous, weirdly inflammatory rhetoric to find it.


> And that goes for frontend development in general…a lot of “backend” developers hate frontend development, but when I scratch the surface, I find out they don’t necessarily hate frontend development per se, they hate all the ridiculous complexity.

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.


Glad you're fine with PHP. I find every single version upgrade, even a minor one, and I end up with library code calls that stopped working. From 3 to 4 to 5, to 7 (yeah, i skipped 6 and just let my crap rot for a time), every tiny upgrade and some library changed significantly enough that I had to spend hours fixing it.

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.


It's not just limited to JavaScript. The tech industry has (had?) too much money and not enough real problems to solve, so it expanded to take advantage of the free money by making up complexity just for the sake of it, and somehow the market actually bought into and embraced the BS.

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.


When I read Laurie’s initial post,I took it in the context of Alex’s post. And Laurie’s point was that developers will be betting off using a framework. 10 years ago, it was angular js, ember etc, Now it is Angular2+, React, Vue etc. in future, it maybe something new, but it will be a framework.

Making Laurie’s post all about React, is taking it out of context, on the verge of gaslighting that author is accusing others of


I just can't bring myself to care this much about technology trends. Why spend your day being angry at frameworks? They're all going to die, who cares when?

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.


I’m totally comfortable with what you prescribe here; I wish my employer counter parties felt differently.


I've extensively used just HTML, VanillaJS, React, Vue, Ruby on Rails and other web frameworks. Different horses for different courses, but I chose what I was most productive in, and that was VueJS and NodeJS. I recommend everyone does the same and explores and settles with what they like the most


I used AngularJS before TS based Angular showed up. I like Angular as a frontend framework. I mostly ignored other JS related trends, because I develop mostly API and I use Angular for admin panels.

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.


Let me save you those few minutes: "I'm a Ruby dev, but the industry thinks JS ecosystem is cooler, even though classic langs were doing SSR in 2014, we were right all along, JS frameworks will fall! *bold text* *dragon tears*"


It's funny how this article could be rewritten by every developer about their own silo: "NoSQL is the future!", "XML is the future!", "git is the future", "Kubernetes is the future", etc. Tech is a continuous hamster wheel of whatever-is-in-fashion.


Git was the future, though. Git is the present. It's dominated for the past decade, and it's only grown more dominant during that time.


This article puts into words my feelings on JS better than I ever could have.

Thank you for this!


I'm so glad these articles are popping up. I've never seen the appeal of any of these web frameworks and felt from another planet.

I don't think they articulate the problem particularly well, or the solution for that matter, but the sentiment is spot on.


The fundamental problem is that it's not the engineers making the technology decisions, at least not in software development, how is it like in other industries!?

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.


I use some JS libs, no frameworks to code JS frontends. No real problems. I do not let myself get sucked in all those holy wars about frameworks and frankly do not give a shit about what tech is used by FAANG. I do not have their problems.

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.


The tone of this article is asinine considering that no one forces anyone to specialize in a particular framework, specializing/investing in any technology is always a risk, and the point that fundamentals are good is non-controversial.

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'm waiting for the enraged article that talks about how bad a language Python really is.


I find it funny that article argues SPA frameworks were pushed with cargo-cultism without evidence, while making proclamations of doom and being fairly light on substance.

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.


Pfft.

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.


This article is pretty spot-on.

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?


Speaking as one of the apparently few people out there who really love JavaScript (as in ES3, it was fine), yes, this framework hype has gone much too far and has favoured a rather single-minded monoculture in web development. Having said that, well, the Web is slower now, which may be an accomplishment.


I'm still hoping that wasm catches on more and more and that people who don't like JavaScript at all, can use wasm and use their language of choice like C# (Blazor or normal WASM), Rust (yew), etc...

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.


Remembering how I nearly got myself fired from a Fortune 50 gig as a Principal Frontend Engineer because I dared question the VP/Architect who decided everything would move to Angular.

I did eventually get myself fired, but that's a different story ;)


Now that server-side rendering seems to creep back into vogue, let’s concentrate back on feeling good while being productive with the tools we love and declare some great frontend framework amnesty.

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...


Seriously... Just use what you want and don't get angry that some people disagree? What a waste of time and energy...


I think the author could disregard all the fluff and simply have this title and accompanying section. Amusing read tho

> The Web Was, Is, and Always Shall Be Polyglot


Fwiw AI is gonna automate this frontend slop we're serving out soon enough.


As a rails developer, I miss haml and coffeescript.


Clearly, the author hasn't tried Svelte... ;P


If you share the sentiment of the author and want to get on the road to recovery, I submit Joystick [1]. I had similar frustrations to this and decided to do something about it [2].

[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.




Applications are open for YC Summer 2023

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: