11 ms·

The JavaScript era happened because we were fed a line

122 points by tambourine_man 4y ago

chiefalchemist 4y ago
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.
- robin_reala 4y ago
  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
  - chiefalchemist 4y ago
    "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.
  - spicybright 4y ago
    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.
- acroyear70 4y ago
  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.
idiomaticrust 4y ago
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 https://github.com/leptos-rs/start-axum , because it's superior technology in terms of speed when you compare it to VDOM frontend frameworks.
dkiok21k 4y ago
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.
- PaulHoule 4y ago
  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.
  - satvikpendem 4y ago
    You're about 20 years too late regarding Stans. Also, where and how do they sound like incels?
    - PaulHoule 4y ago
      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.
      - hgsgm 4y ago
williamcotton 4y ago
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!
- satvikpendem 4y ago
  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.
pelagicAustral 4y ago
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.
- efields 4y ago
  > 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.
flohofwoe 4y ago
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
- civilized 4y ago
  This seems like a really important fundamental observation. I hope other folks with different perspectives see this and weigh in.
  - horsawlarway 4y ago
    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.
zubairq 4y ago
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
noelwelsh 4y ago
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.
- czx4f4bd 4y ago
  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.
mrtksn 4y ago
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.
mavu 4y ago
This article puts into words my feelings on JS better than I ever could have. Thank you for this!
Doches 4y ago
> 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.
- satvikpendem 4y ago
  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.
- rk06 4y ago
  Angular and Vue are still Alive
  - pritambarhate 4y ago
    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.
jurassic 4y ago
> …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.
- BaseballPhysics 4y ago
  > 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.
  - BackBlast 4y ago
    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".
sircastor 4y ago
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.
- BaseballPhysics 4y ago
  > 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?
  - sircastor 4y ago
    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.
j_crick 4y ago
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-response-forgiveness/671879/ https://www.theatlantic.com/ideas/archive/2022/10/covid-resp...
rk06 4y ago
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
Tade0 4y ago
> 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.
vijucat 4y ago
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.
- bccdee 4y ago
  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.
rexreed 4y ago
I'm waiting for the enraged article that talks about how bad a language Python really is.
deleted 4y ago
[deleted]
mschuster91 4y ago
> 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.
- acroyear70 4y ago
  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.
deleted 4y ago
[deleted]
deleted 4y ago
[deleted]
polotics 4y ago
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?
andrew-dc 4y ago
Clearly, the author hasn't tried Svelte... ;P
poisonborz 4y ago
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*"
grimpy 4y ago
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.
FpUser 4y ago
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.
Nextgrid 4y ago
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.
a13o 4y ago
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.
- neon_electro 4y ago
  I’m totally comfortable with what you prescribe here; I wish my employer counter parties felt differently.
tambourine_man 4y ago
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.
vichle 4y ago
Seriously... Just use what you want and don't get angry that some people disagree? What a waste of time and energy...
ZvG_Bonjwa 4y ago
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.
- BaseballPhysics 4y ago
  > 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?
- SPBS 4y ago
  > 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.
unconed 4y ago
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 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.
z3t4 4y ago
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.
deleted 4y ago
[deleted]
britch 4y ago
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.
recursivedoubts 4y ago
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 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-opposite-of-rest/ https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...
- dragonwriter 4y ago
  > 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.
  - recursivedoubts 4y ago
    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.)
merb 4y ago
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.
foobazzy 4y ago
As a rails developer, I miss haml and coffeescript.
masswerk 4y ago
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.
shove 4y ago
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 ;)
darepublic 4y ago
Fwiw AI is gonna automate this frontend slop we're serving out soon enough.
deleted 4y ago
[deleted]
fwlr 4y ago
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.
Devasta 4y ago
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 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.
rglover 4y ago
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 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.
ravagat 4y ago
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

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.

robin_reala 4y ago
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
- chiefalchemist 4y ago
  "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.
- spicybright 4y ago
  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.
acroyear70 4y ago
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.

idiomaticrust 4y ago

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 https://github.com/leptos-rs/start-axum , because it's superior technology in terms of speed when you compare it to VDOM frontend frameworks.

dkiok21k 4y ago

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.

PaulHoule 4y ago
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.
- satvikpendem 4y ago
  You're about 20 years too late regarding Stans. Also, where and how do they sound like incels?
  - PaulHoule 4y ago
    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.
    - hgsgm 4y ago

williamcotton 4y ago

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!

satvikpendem 4y ago
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.

pelagicAustral 4y ago

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.

efields 4y ago
> 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.

flohofwoe 4y ago

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

civilized 4y ago
This seems like a really important fundamental observation. I hope other folks with different perspectives see this and weigh in.
- horsawlarway 4y ago
  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.

zubairq 4y ago

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

noelwelsh 4y ago

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.

czx4f4bd 4y ago
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.

mrtksn 4y ago

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.

mavu 4y ago

This article puts into words my feelings on JS better than I ever could have. Thank you for this!

Doches 4y ago

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

satvikpendem 4y ago
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.
rk06 4y ago
Angular and Vue are still Alive
- pritambarhate 4y ago
  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.

jurassic 4y ago

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

BaseballPhysics 4y ago
> 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.
- BackBlast 4y ago
  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".

sircastor 4y ago

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.

BaseballPhysics 4y ago
> 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?
- sircastor 4y ago
  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.

j_crick 4y ago

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-response-forgiveness/671879/ https://www.theatlantic.com/ideas/archive/2022/10/covid-resp...

rk06 4y ago

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

Tade0 4y ago

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

vijucat 4y ago

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.

bccdee 4y ago
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.

rexreed 4y ago

I'm waiting for the enraged article that talks about how bad a language Python really is.

deleted 4y ago

[deleted]

mschuster91 4y ago

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

acroyear70 4y ago
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.

deleted 4y ago

[deleted]

deleted 4y ago

[deleted]

polotics 4y ago

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?

andrew-dc 4y ago

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

poisonborz 4y ago

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

grimpy 4y ago

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.

FpUser 4y ago

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.

Nextgrid 4y ago

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.

a13o 4y ago

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.

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

tambourine_man 4y ago

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.

vichle 4y ago

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

ZvG_Bonjwa 4y ago

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.

BaseballPhysics 4y ago
> 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?
SPBS 4y ago
> 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.

unconed 4y ago

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

z3t4 4y ago

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.

deleted 4y ago

[deleted]

britch 4y ago

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.

recursivedoubts 4y ago

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 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-opposite-of-rest/ https://htmx.org/essays/how-did-rest-come-to-mean-the-opposi...

dragonwriter 4y ago
> 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.
- recursivedoubts 4y ago
  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.)

merb 4y ago

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.

foobazzy 4y ago

As a rails developer, I miss haml and coffeescript.

masswerk 4y ago

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.

shove 4y ago

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

darepublic 4y ago

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

deleted 4y ago

[deleted]

fwlr 4y ago

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.

Devasta 4y ago

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

rglover 4y ago

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

ravagat 4y ago

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