12 ms·

The Market for Lemons

228 points by tambourine_man 4y ago

CuriouslyC 4y ago
This is a pompously written puff piece. Moving logic to the client is the right choice for an application, and the wrong choice for mostly non-interactive content. Know what you're building and choose the right tools/use the right techniques. Javascript has been (and kind of continues to be) a mess, but thankfully you can compile almost anything to WebASM these days, and 95% of people have browsers that support WebASM, so if you want to build your app in Rust with QT have at it.
- Waterluvian 4y ago
  Is there an example of QT via WASM? That would be quite the sight.
  - CuriouslyC 4y ago
    https://www.qt.io/qt-examples-for-webassembly https://www.qt.io/qt-examples-for-webassembly
    - slightlyoff 4y ago
      Hard pass: https://www.webpagetest.org/video/compare.php?tests=230205_BiDcRF_2WD-r%3A1-c%3A0&thumbSize=200&ival=100&end=full https://www.webpagetest.org/video/compare.php?tests=230205_B...
    - BuckyBeaver 4y ago
      Holy crap is that a broken mess. They should take that down.
- CharlieDigital 4y ago
  > Know what you're building and choose the right tools/use the right techniques. I feel that this is the author's point: in the modern era, the "right tool" is React (in the worst possible way and often because of ignorance). As the saying goes: when all you have is a hammer, every problem looks like a nail.
- jimbob45 4y ago
  JavaScript is a mess but HTML is a catastrophe. I don’t understand how JS gets so much flak when most of its shortcomings are actually shortcomings of HTML interaction.
- deleted 4y ago
  [deleted]
- mixedCase 4y ago
  > Moving logic to the client is the right choice for an application, and the wrong choice for mostly non-interactive content Well then we're fucked. Juniors and a good chunk of intermediate level devs do not understand where one solution ends and another begins, let alone how they work or their trade-offs, so if we want things to not suck ass in the real world (where there aren't enough senior devs who actually know and care) we'll have to figure this one out. My gut says that it starts with a solution similar to Qwik, but I haven't thought about the DX implications deeply enough.
- BuckyBeaver 4y ago
  Is Rust with Qt a thing?
travisgriggs 4y ago
> "why is this market so inefficient?" I don’t know, but I too have felt this for the last many (10 or so) years. And not necessarily just web. I think the answer lies in part in this line: “The complexity merchants…” With so much free money floating around, software development has grown more bureaucratic than ever. I’m not sure how effective emphasis on IDEs, processes, or languages really was 10+ years ago. But the fact that “being more efficient, higher productivity for lower inputs” was something people paid money for indicates (to me) that it was a priority more than it is now. When the economic model becomes “throw money at moonshots looking for the next 1000x thing” then inefficiency is going to take a back seat. One of the truly amazing things to me is the increase in specialties that must exist and cooperate to deliver/maintain products of any size.
- drewda 4y ago
  A recent blog post making similar points: https://laughingmeme.org/2023/01/23/software-and-its-discontents-part-2-complexity.html https://laughingmeme.org/2023/01/23/software-and-its-discont...
  - travisgriggs 4y ago
    Good read there. I think there’s a missing complexity from his list. The complexity of abstractions. Working in software often feels like advanced philosophy now days.
- mathgladiator 4y ago
  I think part of the problem is the nature of ownership versus a salary. Would you rather have equity within a company and partake of the profits, or would you like a nice salary? I'm writing a longer post on how I think about hiring for my company, but the gist is that I want 100% equity players with the thesis that work will get done without the excess headcount.
  - bruce511 4y ago
    As someone with equity I always assumed everyone wants equity. I've come to discover that most people just want a nice stable salary. The incidence of "owners" is higher in tech, in part because its an easy way to start a business. Low capital needs, cheap equipment, no formal qualification required, and lots of examples of success to emulate. In other words equity in computer startup is highly attractive to those who have that bent in the first place. >> I'm writing a longer post on how I think about hiring for my company, but the gist is that I want 100% equity players with the thesis that work will get done without the excess headcount. In my experience this hasn't always worked well for me. Those that favour equity often end up going off to start their own business, where they get more equity, and don't have to deal with pesky folk like me. It's certainly worth a try, but I think you'll discover that most people just want a salary. Equally, my advice to workers is to get a good salary first, and consider options et al to be likely worth nothing. For equity to be meaningful it has to be substantial, and you just don't get infinite substantial slices out of 100%. Of course if your company is google successful, then great, even tiny slices make millionaires. But its vanishingly unlikely that your company turns out like that. I'll end with this - you have a thesis and it's certainly worth a punt. If nothing else it's valuable data for your next business. It'd be great if your thesis works out (for your sake I hope it does) but be prepared for unexpected outcomes, and try and recognize those outcomes early. Perhaps, just perhaps, there's a reason most companies don't work like this.
mattgreenrocks 4y ago
> Those who dared speak up were branded "negative" and "haters", no matter how much data they lugged in tow. I'd argue the rot goes beyond JS frontends and into a lot of webdev infrastructure, including libraries and full-stack frameworks. And that lemons tend to cluster with other lemons.
- deleted 4y ago
  [deleted]
- mathgladiator 4y ago
  I've made a peace with this, but I'm building what I would consider a modern stack. The central component is a reactive back-end much like Excel, and the UI is then a minimal HTML shim on top of a server. I believe tailwind is a great way to represent styles and CSS without a bunch of fuss, and this combo is working well with me. The key challenge I have is that I need to switch gears from platform building and building products. https://www.adama-platform.com/ https://www.adama-platform.com/
  - mattgreenrocks 4y ago
    I really love what you’re building here. If you ever get to a point where you’d want outside help from a PL wonk, let me know. Email is my HN username at Google’s ubiquitous email service.
cagenut 4y ago
Its interesting as a theme to spot check things these days with: "is what I think is normal really a zirp/vc-bubble anomaly?"
postalrat 4y ago
People tried different things for many years and web apps won simply because they did what people want without the trouble of native apps. Installing, maintaining, and securing native apps is too much trouble.
- effie 4y ago
  Web apps can't work without at least one native app. If that native app can be installed, maintained and secured, so can the others. The real reason is HTML/JS/CSS is universal platform to code against, unlike myriad of OS-specific toolkits.
- cxr 4y ago
  The author is not advocating for native apps over Web apps. That's not the pretext for this post, and if you're reading it (and the author's motives) through that lens, then you're reading it wrong. (In fact, they lament the domination of native mobile apps over Web apps—blaming "complexity merchants" for that outcome.)
ng12 4y ago
At this point articles like this exhaust me beyond the point of caring. The popular tools are all reasonably good and in my experience the people complaining about the JavaScript ecosystem do so at the expense of getting stuff done.
- deleted 4y ago
  [deleted]
- ramones13 4y ago
  I’m guessing you’ve got a nice $1k+ dev box and high-speed internet?
  - taurath 4y ago
    The landscape for non SPAs don’t look great either - Amazon and other e-commerce sites come to mind. It’d be nice to show some examples of who’s doing things well while also being complex, and having a nice UI.
  - ng12 4y ago
    Yep, and my users do too. Most of these blog posts can be distilled down to "pick the right tools for the job".
- DangitBobby 4y ago
  Absolutely. Always eye-roll inducing, particularly the ones with bitter, angry, or in this case accusatory tones. JS solves problems people have, and it's not goin away anytime soon. I would love to be something other than a frontend code monkey, but I don't see that happening anytime soon. I just wish people here could shut the fuck up about it.
friedman23 4y ago
People that complain about SPAs are the modern knights tilting at windmills. What are the primary ways people today consume content? Youtube, tiktok, whatsapp, facebook messenger, instagram, discord, etc, etc. Before someone qualifies my post with "ackshually I do this thing", yes I read blogs too. That being said, NOBODY READS BLOGS. People don't want static html and css. They want real time updates, they want notifications, they want gamification. They want to play the slot machine. So while you want to shit on javascript (it's fun to bundle in the shit language javascript when going on these tirades because everyone fucking hates javascript). The problem is not javascript. The problem is, we want real fucking apps, with interactivity, and we want them instantly, over an internet connection. I want to play chess in my browser over an internet connection. And when chess 2.0. comes out I better have that shit in my browser in under 100ms. Oh, and sure JS is shit. But if we were using Rust for our UIs we'd have the same problem. The most prominent Rust web UI frameworks are literal React and SolidJs clones. And JS will be replaced, but we don't have a good enough garbage collected language for it yet. edit: Can you even think of a modern business that could be just served by just html and css. Like what? A restaurant? Is that what we really think the average software engineer is working on? Restaurant websites?
- bfgoodrich 4y ago
  [dead]
- the__alchemist 4y ago
  Perhaps I interpreted the article differently, but I don't think it's about Javascript - it's about complex Javascript frameworks. Ie, ones that cause bloat via large dependency trees, and unnecessary computations. These aren't required for the interactivity you described. I've written one of those React clones in Rust you mention. It was as you say - as much of a mess in practice as a JS framework.
  - friedman23 4y ago
    > but I don't think it's about Javascript I get that and that's part of the point of my comment. That these screeds always make sure to mention javascript because by bundling javascript in the screed you get default acceptance from the JS haters. But the fundamental essence of the article is about complaining about SPAs. Which betrays a striking ignorance of what most frontend web software engineers are working on. They are not working on websites for businesses that only need a single form and an email to get the form responses. That usecase is solved and does not require a software engineer. It can be built on wordpress or squarespace. SPAs are the answer to the question of how do we build an app that is delivered in real time over an internet connection. The reason these apps are built with JS is because until relatively recently it was the only option. Why is it still used while there are other options? Because WASM is not mature and JS is still faster and there is no killer reason to switch off it.
projektfu 4y ago
I can't look at an app and tell you that it's written in framework A or B, but so many websites are becoming dogs these days, and not just because they have to run Javascript. I think the scripts actually spend a lot of time blocking on the I/O that would have originally been delivered with the initial page. Server side rendering may be a solution but it seems lots of sites have a rather modular approach to putting components on a page that then load lazily over ridiculous amounts of time. As an example, the American Express account management website. Lots of banking websites are going this way, where it's taking long enough to finish a request that you worry the logout timer will fire before it's done. They have also lost niceties like the ability to take you back to the same page with the items in the same order, that I had on the Dollar Bank website circa 1998. (Seriously, that bank was ahead of the curve and the website was fast, on 33kbps dial-up and a Pentium MMX 200.) Other websites are the same. Kaiser. State taxes. Delta airlines. Formerly fast things replaced by janky lazy loads that reflow the page and cause you to click the wrong thing. And so much telemetry! Can you actually process all that data? Because if it's working it must be screaming that people are constantly clicking the wrong thing.
- MBCook 4y ago
  I remember when Reddit (old.reddit.com, the good one) loaded ultra fast and didn’t move around. I could use the back button without noticeable waiting. And it didn’t freeze up network requests on other tabs on my phone. I STILL don’t know how it does that. I would love a fix. At least at some point I discovered opening a new tab with HN “unblocked” it somehow. SPAs have their place. It’s not everywhere. Just like microservices. And ORMs. And all the other “magic” that will solve all my problems.
  - slightlyoff 4y ago
    You might try https://sh.reddit.com https://sh.reddit.com
    - consumer451 4y ago
      Thanks, I knew about www.reddit, old.reddit, i.reddit, m.reddit, but I didn't know about this one. I can't find any info on it, what is the goal of sh.reddit UI exactly? On another note, all kinds of interesting subdomains[0]. I wonder why a few subs get a subdomain? [0] https://domain.glass/reddit.com https://domain.glass/reddit.com
zeroonetwothree 4y ago
Similar article: https://biggestfish.substack.com/p/information-asymmetry-part-1 https://biggestfish.substack.com/p/information-asymmetry-par...
phendrenad2 4y ago
I disagree that JS frameworks are in any way a problem. React is not substantially different from developing a Rails frontend using um... what do the kids use these days? HAML? Hamlet! No, that's not right. Anyway... The real trouble comes when you think that "switching to <hot new framework>" will solve all of your problems. This is equivalent to thinking that giving your troops Scottish-made swords (when they've been using German-made swords) will somehow make them fight better. Armed with this disinformation, teams march blindly into the meat grinder of reality. "We need to do auth... again? Didn't we just do that in Django? And then Angular? Arghhhh". If your auth implementation in django was bad, and you rewrote it in angular and introduced problems, rewriting it in react is not going to magically make your developers do it right this time.
- robin_reala 4y ago
  React is not substantially different from developing a Rails frontend I think you misinterpreted the article. The developer experience isn’t what’s at stake here, it’s what the user experiences. And for 95% of systems (99%?) as simple Rails app will be faster than a React app.
  - DangitBobby 4y ago
    I'm curious to see actual performance comparison metrics for a site written on rails versus one written on, e.g., Next.js.
    - robin_reala 4y ago
      Really the specific framework isn’t an issue: it’s down to minimising as much as possible the amount of JS you ship to the client.
  - phendrenad2 4y ago
    User experience is affected directly by developer experience. If it's tedious, or complex, or error-prone, to develop using a framework, then the user experience will likely suffer.
stevebmark 4y ago
Does anyone else find this writing style hard to follow and alienating? The clever section titles, verbose passages, inflated vocabulary, and indirect descriptions, make it frustrating to read. Just say things directly.
- slightlyoff 4y ago
  Author of the article here. TL;DR: your JS is probably worse than you think. Write HTML and CSS instead. It will go better for everyone. And feel free to ignore the most popular JS framework vendors; they have not known what they are talking about for at least a decade.
  - taurath 4y ago
    Do you have any examples of well trafficked sites with good UIs doing things well? It would seem that there might be outliers you might be able to point to
    - slightlyoff 4y ago
      Most are from a world that is better, but which the complexity merchants have convinced (thanks to asymmetric information) all but their closest competitors to replace with unwieldy tech. E.g.: https://app.speedcurve.com/benchmarks/usa/retail/fast/fully-loaded/ https://app.speedcurve.com/benchmarks/usa/retail/fast/fully-... The fast sites on "legacy" stacks have 1/10th the COGS for the same performance versus the absolutely stupid costs invoked for React/NG/Ember/etc. SSR + hydration. Which brings up the real issue: when the framework is both baseline-costly and runtime nasty, metrics like INP will suffer without extraordinary controls. When you see a React site in the list above, it's a fair guess that I've talked with their tech teams and they have felt trapped between unsubstantiated narratives and the reality that shipping React-based sites is losing them tons of money. The antidote is a frank discussion of up-front cost vs. per-interaction latency. And we aren't having that debate right now. Presumptively the careers of the last decade's charlatans depends on us not levelling up. It's the only reason I can peep for why we haven't evolved past new ways to spell old ideas.
locallost 4y ago
I agree with the article, but think it's poorly written. In a way, it's a bit like the developer work that its criticizing -- overly complex. One of the linked articles is much better and to the point: https://ericwbailey.website/published/modern-health-frameworks-performance-and-harm/ https://ericwbailey.website/published/modern-health-framewor... My 2c: I've seen good experiences, but a lot more poor ones. I've worked on them and they were n times more expensive for very little benefit. I don't think it's by design, but more cynical people might. I think it's just a dogma among developers and management too afraid to step in because developers hold too much power. They want to work on this because everyone else is, and if they can't they will go somewhere else and then you need to find new developers and everyone knows there aren't any available. We switched to a server side rendered spa stack because the developers said "don't want to be stuck on old fashioned stacks, want to work on cool things". We then needed twice the time and twice the developers to get things done. So basically the way out of this is for someone to hype up a server side solution and sell it as a shiny new thing. It needs to be logical in a way that makes lights in heads go on, but also somewhat mysterious and new. Deno Islands fit that mold, we'll see if it pans out.
- cxr 4y ago
  > if they can't they will go somewhere else and then you need to find new developers and everyone knows there aren't any available The recurring resume-requires-React pattern sure isn't helping.
- Existenceblinks 4y ago
  No "isomorphic" please. Please don't moving forward with js-everything, that's actually moving backward.
quxbar 4y ago
Has this author been on the other side of the fence? I have encountered, for every bloated javascript problem child, an equally burdensome python monolith, or sprawling maze of go microservices. I suspect the root cause is something to do with human error, but I digress. The benefit of much-derided React code when I can onboard new developers from 3 different countries and backgrounds and have them all writing DRY, tested, idiomatic code within a few days. They can then ship a feature that then provides more values to the end user, who probably doesn't care a fig what HTML is. Or, like a patient senior developer, they understand that shipping is preferable to not shipping, and that perfect performance, accessibility, and usability are all asymptotic to us mere mortals.
- DangitBobby 4y ago
  We are replacing truly the most disgusting codebase I've ever seen right now, a WP instance (alright) highly customized (worrisome) written by pre-for-loop contractors (uh-oh) which has over 10k lines of jQuery (uh-oh) for a relatively small site, but all of the jQuery lives in one main.js (UH-OH) and executes on every page whether or not it does anything to that page. It's also written in such a way that it crawls the DOM so many times on huge HTML payloads that the entire page slows to a crawl as your computer fan winds up. You'll often get 10 seconds of non-responsive page after the first paint. There's barely any interactivity here as well, just a couple of modals and buttons. As the client scaled up, they started having serious performance problems that rendered the site completely unusable for some users, and some pages were so bad on the backend that simply visiting a page could cause an outage. Refactorings were considered (minor ones attempted), but the code is so poorly written and brittle that it's actually easier to just fucking rewrite it, so they/we just do targeted performance enhancements, bugfixes, and minor updates while rewriting. All that to say, the worst codebases I've ever seen are PHP monoliths, (though I've seen some rough Django/flask as well) shitted out by contracting firms which bill high rates for code written by juniors. People (particularly those who frequent this site) are way too focused on the choice of framework when trying to assess these outcomes.
quickthrower2 4y ago
Despite all this NextJS has brought me a lot of joy using it. Probably the most joy of all front end experiences web or even desktop (and I quite liked WPF!) That said I get it: it can be annoying for the user when the site does unpredictable shit which it can sometimes do with a SPA. For example shit appearing just before you click an area of the screen so you end up clicking the wrong thing. The complexity is a problem too, there is a lot of shit to learn these days to get the app working. NextJS is like autopilot most of the time but you still gonna drop down and troubleshoot NPM dependencies etc. sometimes so there is a lot to know.
seanhunter 4y ago
Setting aside the FA for a second and considering just the market for lemons itself. Imagine being George Akerlof. You coined one of the most famous things in economics (the market for lemons), for which you won the Nobel Frikkin' Prize[1] and your spouse[2] is still a more famous economist than you. [1] Nobel Memorial Prize if you're a Taleb-inspired pointless hair splitter [2] Janet Yellen
- profstasiak 4y ago
  I studied economics. Akerlof is more famous economist. Yellen is famous political economist
  - seanhunter 4y ago
    To be clear, I meant "famous person who is an economist" rather than "economist who is famous among economists" but I take your point.
oli5679 4y ago
For me the biggest source of unnecessary complexity is Kubernetes. If you use envelope math, you rarely need more than one reasonably sized instance, and your key performance bottleneck is database and external apis. Lots of people can get away with single machine running on Heroku/ec2, until their product logic becomes too complicated for a single dev team to maintain.
BuckyBeaver 4y ago
Did I miss it, or did the author not state what the better solution is?
- BuckyBeaver 4y ago
  [flagged]
- BuckyBeaver 4y ago
  [flagged]
  - dang 4y ago
    Breaking the site guidelines like this will get you banned here, even if you're right or feel you are. Would you mind reviewing https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and using the site as intended? You may not owe jagoffs better but you owe this community better as long as you're participating in it.
    - BuckyBeaver 4y ago
      [flagged]
- deleted 4y ago
  [deleted]
- erik_seaberg 4y ago
  > No, we need to move our attention back to the folks that have been right all along. The people who never gave up on semantic markup, CSS, and progressive enhancement for most sites. The people who, when slinging JS, have treated it as special occasion food.
- BuckyBeaver 4y ago
  [flagged]
  - 4y ago
ebiester 4y ago
Is the author talking about information websites, websites with limited interactivity, or web applications that would feel more at home as desktop applications? I honestly believe that many of the complaints about SPAs as a bad paradigm don't solve themselves with progressive enhancement; they solve themselves with a better cross-OS development environment and safe, sandboxed modern applets. (Alternatively, your company needs to be homogeneous, and third-party vendors need to develop for both Mac and Windows, and hope Wine is good enough for any other option.) That leaves websites with limited interactivity. If the author is speaking about these, I can understand the frustration. I'd love to see solutions like liveview or htmx take over. Maybe other solutions will be good enough. However, for us to get beyond talking past each other on these conversations I think we need to always be considering the context and detail the use cases.
naet 4y ago
The author spends the bulk of the post (as far as I could tell from the opaque writing style) criticizing React and the React ecosystem. But when you see the first footnote for their recommended alternatives, many are very similar to React in practice. Notably: Preact (basically just another implementation of React) Vue (very similar ecosystem to React in terms of the mentioned SPA SSR etc) SolidJS Svelte Etc. Then some of the recommended alternatives to the SPA are just as complex or more complex than the things the author had just criticized, including Astro (SSR with islands), Fresh (denos edge based "just in time" SSR), Sveltekit (the same SPA SSR SSG etc complained about for React above). Not sure how these don't fall under the same opaque criticisms of the JS "lemon market".
- CharlieDigital 4y ago
  I think author's point is that React is the absolute worst of the evils and it's proprietors shout its false virtues so loudly that it drowns out all discourse and rational thought. It performs the worst (by a large margin) of the major JS frameworks https://krausest.github.io/js-framework-benchmark/2023/table_chrome_109.0.5414.87.html#eyJmcmFtZXdvcmtzIjpbImtleWVkL2FuZ3VsYXIiLCJrZXllZC9yZWFjdCIsImtleWVkL3JlYWN0LWhvb2tzIiwia2V5ZWQvc29saWQiLCJrZXllZC9zdmVsdGUiLCJrZXllZC92YW5pbGxhanMiLCJrZXllZC92dWUiLCJub24ta2V5ZWQvcmVhY3QiLCJub24ta2V5ZWQvc3ZlbHRlIiwibm9uLWtleWVkL3ZhbmlsbGFqcyIsIm5vbi1rZXllZC92dWUiXSwiYmVuY2htYXJrcyI6WyIwMV9ydW4xayIsIjAyX3JlcGxhY2UxayIsIjAzX3VwZGF0ZTEwdGgxa194MTYiLCIwNF9zZWxlY3QxayIsIjA1X3N3YXAxayIsIjA2X3JlbW92ZS1vbmUtMWsiLCIwN19jcmVhdGUxMGsiLCIwOF9jcmVhdGUxay1hZnRlcjFrX3gyIiwiMDlfY2xlYXIxa194OCIsIjIxX3JlYWR5LW1lbW9yeSIsIjIyX3J1bi1tZW1vcnkiLCIyM191cGRhdGU1LW1lbW9yeSIsIjI1X3J1bi1jbGVhci1tZW1vcnkiLCIyNl9ydW4tMTBrLW1lbW9yeSIsIjMxX3N0YXJ0dXAtY2kiLCIzNF9zdGFydHVwLXRvdGFsYnl0ZXMiXSwiZGlzcGxheU1vZGUiOjEsImNhdGVnb3JpZXMiOlsxLDIsMyw0LDVdfQ== https://krausest.github.io/js-framework-benchmark/2023/table... And is highly inefficient in both compute and space: https://timkadlec.com/remembers/2020-04-21-the-cost-of-javascript-frameworks/ https://timkadlec.com/remembers/2020-04-21-the-cost-of-javas... Comparatively, Vue for example, can be used progressively. It is one of the core reasons the Wikimedia Foundation and GitLab chose it: https://phabricator.wikimedia.org/T241180 https://phabricator.wikimedia.org/T241180 . Solid and Preact both perform close to Vanilla and bundle far smaller, improving the end user experience. One of Vue's main technical goals this year is Vapor mode (inspired by Solid) which should yield lighter, faster, and more modular client packages. My take is that React now is the worst of the major libraries yet the most heavily used. It's core design is fundamentally flawed so additional layers of complexity are needed to mitigate it. It doesn't make any sense except for the complexity peddlers who's fortunes depend on more suckers. If you watched the Next.js conf last year, you know what I mean. You can tell they invested a lot of money into production value. I watched a Microsoft developer conference shortly after and the difference was night and day. Ask yourself why Vercel needs to invest that much into a developer conference where ostensibly we developers want good tech, not flashy presentations. Who are they actually selling to? Working at a startup building on Next.js and React, I commiserate with the author's take on complexity peddlers. We have dozens of lines of code for what should take just a handful to do in vanilla. In look at this code everyday wondering why we have piles of JavaScript for very simple interactions. Most recently, a dev made some well intentioned changes that somehow changed Next to only output CSR (no server output HTML); thereby fully defeating the purpose. Now we have a server render cycle calling out to an API that returns JS to render on the client. Probably should just render on the client and skip the middle man! The senior eng team absolutely regrets going Next.js (decision made before I joined). We've been fleeced.
college_physics 4y ago
> We lost a decade to smooth talkers and hollow marketeering To eliminate lemon markets somebody has to be tasked (and rewarded) for doing the slog work that will reduce the information asymmetry. This would normally be trusted experts (tech journalism, academia etc).
xyzelement 4y ago
Few jobs ago I was a PM director at a scaleup and at some point our frontend platforms engineering (or something like that) came into my purview. This team didn't build front end experiences but tried to build out tooling in which other devs would. Which was weird to me given that we didn't do anything extraordinary in terms of experience so off the shelf stuff should have worked. I think this was some evidence towards the point in this article. Two things were at play: First, the gross complexity of the available frameworks made it seem like something like this was necessary. Second, the people involved were excited to further their careers on this, so motivation to call out unneeded complexity was low. If I had owned this space from the start, I'd have asked the question of "what business outcomes does this enable which we can't achieve at least for a while, with static-ish html, forms, etc" and maybe allow a little complexity where justified. But since it was purely engineering owned for a few years before it got to me, it was way too late to reign the complexity and we ended up doing shit like porting from one framework to another.
- danielvaughn 4y ago
  One of the mantras I like to chant is that your job as a developer is not to write code. Your job is to implement solutions to business problems. I didn’t understand that until I became a manager. Your whole perspective shifts because you realize that salaries don’t just grow on trees.
  - nine_k 4y ago
    "Lines of code are not produced but spent" (Dijkstra)
  - jiggunjer 4y ago
    Unless you work for government.
- patrickthebold 4y ago
  One thing to consider: a lot of devs are most familiar with React and some set of tools in it's ecosystem. Sticking with what you know is generally good advice. Especially if you consider hiring and onboarding.
tambourine_man 4y ago
The article is a bit too bitter for my taste, but I agree with most of it. Except for the developer experience improvement these frameworks supposedly offer, I don’t even buy that. For over a decade it seems to me the industry has been enamored with crazy complex solutions to problems that mostly don’t exist. I keep reading their proposals in dismay and basically chugging along with almost the same stack as before. Clients are as happy as ever. I tried to show (here and elsewhere) that, for instance, PHP/MySQL + HTML/CSS/VanillaJS is faster, easier to read and write than React/Angular/FrameworkDuJour, but we seem to live in different worlds. I still think jQuery was the biggest improvement in frontend development quality of life and hasn’t been matched since. I’ve mostly resigned to believe that React and friends are maybe great for hiring, being hired, manage teams. Actual coding is another discussion altogether.
Sai_ 4y ago
I wish I knew what the author was fulminating about. This article is in dire need of examples and case studies but instead, the author says that it is hard to summarise a “decade” of JS/SPA bloat into one article. Anyway, to his point about the market for JS frameworks shrinking, I’ve moved my projects to HTMX + AlpineJS. Couldn’t be happier though the entire apparatus seems to be holding together with wire and spit and prayers.
jFriedensreich 4y ago
My god, this article reads like a non fiction incarnation of "infinite jest" its basically impossible to understand the authors concrete intent and meaning of whole paragraphs without reading the footnotes and the linked articles while reading the post. And if i understand it correctly, it completely misses the point who is to blame. Angular and react solutions were seldom sold from an actor with deep information to a manager or business with less information. In my experience the top 2 situations were a) managers/half-technical founders wanted what they had read about and google or facebook were backing and did not want to hear about a proper evaluation, b) devs and whole dev teams wanted to just use what they knew and read about 100% thinking this was the best solution because of their inexperience and lack of reflection. The first is just your usual ignorance towards the experts by buzz word driven and half-knowledge managers, the latter could be more likened to the brainwashing of cult members than intransparent market situations.
- giaour 4y ago
  > And if i understand it correctly You did not. Per the article, the "buyers" of SPAs are the developers and teams who heard about a technology and thought it would be the right tool.
iamsanteri 4y ago
SPAs were a zero interest rate phenomenon :’DDD I laughed so hard
twodave 4y ago
I think there’s a bit too much “blaming the tool” going on here. Be reasonable about what you introduce into a software project. If it’s a bunch of CRUD you probably can wait to add a front-end framework. If you find yourself needing it for that one big feature where you have to implement drag-and-drop and a bunch of DOM manipulation, don’t rewrite your whole app, just tailor that one experience. If you don’t NEED a high level of server communication or data continuation between components, you probably also don’t need any crazy state management. And again, when you build that one wizard experience that really needs something more, tailor the solution local to that one experience. Not to say that larger and more complex projects don’t exist, but for most things you can get away with a lot less, and there’s balance between performance, developer joy and increasing productive capacity.
- sublinear 4y ago
  > Be reasonable about what you introduce into a software project. ... don’t rewrite your whole app, just tailor that one experience. You just described exactly why most web devs strongly prefer to build SPAs today instead of using SSR (separation of concerns).
  - twodave 4y ago
    Well, I think the main difficulty with SSR is you'd think it would be more of an incremental step. I don't think it's so much a "separation of concerns" issue (i.e. just having some of your presentation logic running on-server doesn't mean it's necessarily not isolated logic) as it is a "wow I have to rewrite significant parts of my application to take advantage of this" issue. Some frameworks definitely do a better job with this than others IMO, but not everybody wants to (or should) migrate their React app to NextJS (for example) just to get SSR.
IYasha 4y ago
Hilarious. The page isn't rendering as (I think) it was intended - half of the screen literally sticks to the top. Maybe the author went too far with his point %) Otherwise, I generally agree. )
vikR0001 4y ago
In the author's footnote #1, he praises Svelte and Vue. So the whole article boils down to "Don't use React, use Svelte/Vue instead."
bambax 4y ago
TFA is a rant that seems mostly targeted at React, judging from the links/examples. The article is not very clear or easy to follow but it still has a point. All modern frameworks are ridiculously complex, esp. given the fact that modern JavaScript is extremely versatile, with classes, modules, web components, etc. A new empty Angular project via the Angular CLI copies almost 40,000 files of node modules (350 Mo), which is apparently considered "very little space" by today's standard (actual quote from a SO answer). It's all quite demoralizing. I actually like SPAs! and I agree that state must be managed on the client somehow; but this is insane. Plain old JS with some Redux, querying a well thought out and simple API on the server will get you a long long way.
- nnurmanov 4y ago
  And there are a number of vulnerabilities with those packages, which are not being fixed. I think NPM should remove any package that are not maintained or have severe (any?) vulnerabilities. IMO, we have too many packages,some restriction to publish will be good.
- _fat_santa 4y ago
  As someone whose worked with React/Angular/Svelte/etc for the past 5-6 years, the biggest benefit and the biggest hurdle to these frameworks is the complexity. The complexity in these frameworks has resulted in us being able to build massive complex applications, but if not done with the proper level of care, that application will be a performance crap sandwich. And that I would say is the biggest problem with these stacks, they are incredibly powerful and can get you places but you have to know how to use them! If you are an experienced web developer you should be able to pick up these frameworks and run with them. But the problem arises when you have a team made up of a number of Sr developers along with Mid/Jr devs. The Sr devs might know all these footguns and hurdles, but the Jr's/Mid's might not. With a small team this gap in knowledge can be effectively managed but the issue really becomes apparent when you have multiple teams, all with the same makeup. But say you are building an app with a very experienced team and don't run into the knowledge issues above, well you can still have issues depending on your vendors. In this case I'm talking about say a chatbot or some other integration into your app where the vendors team wrote said code. In this case you have the same issue where you can have the most experienced devs on your team, but if the vendor wrote some crap code, you're going to have issues in your app. All of this is to say, applications have just become massive recently, and managing that complexity and making sure your application stays performant gets harder and harder.
AlbertCory 4y ago
Yesterday there was a post for Patterns, an AI framework. Deja vu. Pretty soon everyone and his school buddies are going to be putting out frameworks for building an AI-enabled application, if they aren't already. And eventually Microsoft and Apple will incorporate one into their developer products, and maybe some of those VC startups will get acquired.
christophilus 4y ago
Every non-SPA that I’ve worked on ended up accreting interactivity to the point that I’d wished we had started with a single, unified, well-structured way for managing the UI that handled interactivity well. I used to do a lot of native Windows apps in C, VB6, and C#. To me, Preact + TypeScript is as good in many ways, better in some, and worse in others— but it averages out to be just fine from a developer perspective. I personally don’t miss the old native UI days. The majority of jank that I see on the web is not due to React or Angular or whatnot. It’s due to ads, trackers, and to product owner’s inability to say “no” to piling a million things into important screens. It is a misplacement of blame to blame React.
asherah 4y ago
the author recommends in the first footnote to use other frameworks like vue, svelte, lit/polymer etc., which makes this seem more like an argument against react, when the entire article is about how javascript-driven spa/ssr stacks are bad. there are a couple clarifications next to it to soften that blow but react also "start[s] with simple output" in the same way these tools do. why act like react is the only lemon merchant? i say this as an active user of vue, so maybe im simply at the most complex of them but from my perspective the other tools are about as complex

This is a pompously written puff piece. Moving logic to the client is the right choice for an application, and the wrong choice for mostly non-interactive content. Know what you're building and choose the right tools/use the right techniques. Javascript has been (and kind of continues to be) a mess, but thankfully you can compile almost anything to WebASM these days, and 95% of people have browsers that support WebASM, so if you want to build your app in Rust with QT have at it.

Waterluvian 4y ago
Is there an example of QT via WASM? That would be quite the sight.
- CuriouslyC 4y ago
  https://www.qt.io/qt-examples-for-webassembly https://www.qt.io/qt-examples-for-webassembly
  - slightlyoff 4y ago
    Hard pass: https://www.webpagetest.org/video/compare.php?tests=230205_BiDcRF_2WD-r%3A1-c%3A0&thumbSize=200&ival=100&end=full https://www.webpagetest.org/video/compare.php?tests=230205_B...
  - BuckyBeaver 4y ago
    Holy crap is that a broken mess. They should take that down.
CharlieDigital 4y ago
> Know what you're building and choose the right tools/use the right techniques. I feel that this is the author's point: in the modern era, the "right tool" is React (in the worst possible way and often because of ignorance). As the saying goes: when all you have is a hammer, every problem looks like a nail.
jimbob45 4y ago
JavaScript is a mess but HTML is a catastrophe. I don’t understand how JS gets so much flak when most of its shortcomings are actually shortcomings of HTML interaction.
deleted 4y ago
[deleted]
mixedCase 4y ago
> Moving logic to the client is the right choice for an application, and the wrong choice for mostly non-interactive content Well then we're fucked. Juniors and a good chunk of intermediate level devs do not understand where one solution ends and another begins, let alone how they work or their trade-offs, so if we want things to not suck ass in the real world (where there aren't enough senior devs who actually know and care) we'll have to figure this one out. My gut says that it starts with a solution similar to Qwik, but I haven't thought about the DX implications deeply enough.
BuckyBeaver 4y ago
Is Rust with Qt a thing?

travisgriggs 4y ago

> "why is this market so inefficient?" I don’t know, but I too have felt this for the last many (10 or so) years. And not necessarily just web. I think the answer lies in part in this line: “The complexity merchants…” With so much free money floating around, software development has grown more bureaucratic than ever. I’m not sure how effective emphasis on IDEs, processes, or languages really was 10+ years ago. But the fact that “being more efficient, higher productivity for lower inputs” was something people paid money for indicates (to me) that it was a priority more than it is now. When the economic model becomes “throw money at moonshots looking for the next 1000x thing” then inefficiency is going to take a back seat. One of the truly amazing things to me is the increase in specialties that must exist and cooperate to deliver/maintain products of any size.

drewda 4y ago
A recent blog post making similar points: https://laughingmeme.org/2023/01/23/software-and-its-discontents-part-2-complexity.html https://laughingmeme.org/2023/01/23/software-and-its-discont...
- travisgriggs 4y ago
  Good read there. I think there’s a missing complexity from his list. The complexity of abstractions. Working in software often feels like advanced philosophy now days.
mathgladiator 4y ago
I think part of the problem is the nature of ownership versus a salary. Would you rather have equity within a company and partake of the profits, or would you like a nice salary? I'm writing a longer post on how I think about hiring for my company, but the gist is that I want 100% equity players with the thesis that work will get done without the excess headcount.
- bruce511 4y ago
  As someone with equity I always assumed everyone wants equity. I've come to discover that most people just want a nice stable salary. The incidence of "owners" is higher in tech, in part because its an easy way to start a business. Low capital needs, cheap equipment, no formal qualification required, and lots of examples of success to emulate. In other words equity in computer startup is highly attractive to those who have that bent in the first place. >> I'm writing a longer post on how I think about hiring for my company, but the gist is that I want 100% equity players with the thesis that work will get done without the excess headcount. In my experience this hasn't always worked well for me. Those that favour equity often end up going off to start their own business, where they get more equity, and don't have to deal with pesky folk like me. It's certainly worth a try, but I think you'll discover that most people just want a salary. Equally, my advice to workers is to get a good salary first, and consider options et al to be likely worth nothing. For equity to be meaningful it has to be substantial, and you just don't get infinite substantial slices out of 100%. Of course if your company is google successful, then great, even tiny slices make millionaires. But its vanishingly unlikely that your company turns out like that. I'll end with this - you have a thesis and it's certainly worth a punt. If nothing else it's valuable data for your next business. It'd be great if your thesis works out (for your sake I hope it does) but be prepared for unexpected outcomes, and try and recognize those outcomes early. Perhaps, just perhaps, there's a reason most companies don't work like this.

mattgreenrocks 4y ago

> Those who dared speak up were branded "negative" and "haters", no matter how much data they lugged in tow. I'd argue the rot goes beyond JS frontends and into a lot of webdev infrastructure, including libraries and full-stack frameworks. And that lemons tend to cluster with other lemons.

deleted 4y ago
[deleted]
mathgladiator 4y ago
I've made a peace with this, but I'm building what I would consider a modern stack. The central component is a reactive back-end much like Excel, and the UI is then a minimal HTML shim on top of a server. I believe tailwind is a great way to represent styles and CSS without a bunch of fuss, and this combo is working well with me. The key challenge I have is that I need to switch gears from platform building and building products. https://www.adama-platform.com/ https://www.adama-platform.com/
- mattgreenrocks 4y ago
  I really love what you’re building here. If you ever get to a point where you’d want outside help from a PL wonk, let me know. Email is my HN username at Google’s ubiquitous email service.

cagenut 4y ago

Its interesting as a theme to spot check things these days with: "is what I think is normal really a zirp/vc-bubble anomaly?"

postalrat 4y ago

People tried different things for many years and web apps won simply because they did what people want without the trouble of native apps. Installing, maintaining, and securing native apps is too much trouble.

effie 4y ago
Web apps can't work without at least one native app. If that native app can be installed, maintained and secured, so can the others. The real reason is HTML/JS/CSS is universal platform to code against, unlike myriad of OS-specific toolkits.
cxr 4y ago
The author is not advocating for native apps over Web apps. That's not the pretext for this post, and if you're reading it (and the author's motives) through that lens, then you're reading it wrong. (In fact, they lament the domination of native mobile apps over Web apps—blaming "complexity merchants" for that outcome.)

ng12 4y ago

At this point articles like this exhaust me beyond the point of caring. The popular tools are all reasonably good and in my experience the people complaining about the JavaScript ecosystem do so at the expense of getting stuff done.

deleted 4y ago
[deleted]
ramones13 4y ago
I’m guessing you’ve got a nice $1k+ dev box and high-speed internet?
- taurath 4y ago
  The landscape for non SPAs don’t look great either - Amazon and other e-commerce sites come to mind. It’d be nice to show some examples of who’s doing things well while also being complex, and having a nice UI.
- ng12 4y ago
  Yep, and my users do too. Most of these blog posts can be distilled down to "pick the right tools for the job".
DangitBobby 4y ago
Absolutely. Always eye-roll inducing, particularly the ones with bitter, angry, or in this case accusatory tones. JS solves problems people have, and it's not goin away anytime soon. I would love to be something other than a frontend code monkey, but I don't see that happening anytime soon. I just wish people here could shut the fuck up about it.

friedman23 4y ago

People that complain about SPAs are the modern knights tilting at windmills. What are the primary ways people today consume content? Youtube, tiktok, whatsapp, facebook messenger, instagram, discord, etc, etc. Before someone qualifies my post with "ackshually I do this thing", yes I read blogs too. That being said, NOBODY READS BLOGS. People don't want static html and css. They want real time updates, they want notifications, they want gamification. They want to play the slot machine. So while you want to shit on javascript (it's fun to bundle in the shit language javascript when going on these tirades because everyone fucking hates javascript). The problem is not javascript. The problem is, we want real fucking apps, with interactivity, and we want them instantly, over an internet connection. I want to play chess in my browser over an internet connection. And when chess 2.0. comes out I better have that shit in my browser in under 100ms. Oh, and sure JS is shit. But if we were using Rust for our UIs we'd have the same problem. The most prominent Rust web UI frameworks are literal React and SolidJs clones. And JS will be replaced, but we don't have a good enough garbage collected language for it yet. edit: Can you even think of a modern business that could be just served by just html and css. Like what? A restaurant? Is that what we really think the average software engineer is working on? Restaurant websites?

bfgoodrich 4y ago
[dead]
the__alchemist 4y ago
Perhaps I interpreted the article differently, but I don't think it's about Javascript - it's about complex Javascript frameworks. Ie, ones that cause bloat via large dependency trees, and unnecessary computations. These aren't required for the interactivity you described. I've written one of those React clones in Rust you mention. It was as you say - as much of a mess in practice as a JS framework.
- friedman23 4y ago
  > but I don't think it's about Javascript I get that and that's part of the point of my comment. That these screeds always make sure to mention javascript because by bundling javascript in the screed you get default acceptance from the JS haters. But the fundamental essence of the article is about complaining about SPAs. Which betrays a striking ignorance of what most frontend web software engineers are working on. They are not working on websites for businesses that only need a single form and an email to get the form responses. That usecase is solved and does not require a software engineer. It can be built on wordpress or squarespace. SPAs are the answer to the question of how do we build an app that is delivered in real time over an internet connection. The reason these apps are built with JS is because until relatively recently it was the only option. Why is it still used while there are other options? Because WASM is not mature and JS is still faster and there is no killer reason to switch off it.

projektfu 4y ago

I can't look at an app and tell you that it's written in framework A or B, but so many websites are becoming dogs these days, and not just because they have to run Javascript. I think the scripts actually spend a lot of time blocking on the I/O that would have originally been delivered with the initial page. Server side rendering may be a solution but it seems lots of sites have a rather modular approach to putting components on a page that then load lazily over ridiculous amounts of time. As an example, the American Express account management website. Lots of banking websites are going this way, where it's taking long enough to finish a request that you worry the logout timer will fire before it's done. They have also lost niceties like the ability to take you back to the same page with the items in the same order, that I had on the Dollar Bank website circa 1998. (Seriously, that bank was ahead of the curve and the website was fast, on 33kbps dial-up and a Pentium MMX 200.) Other websites are the same. Kaiser. State taxes. Delta airlines. Formerly fast things replaced by janky lazy loads that reflow the page and cause you to click the wrong thing. And so much telemetry! Can you actually process all that data? Because if it's working it must be screaming that people are constantly clicking the wrong thing.

MBCook 4y ago
I remember when Reddit (old.reddit.com, the good one) loaded ultra fast and didn’t move around. I could use the back button without noticeable waiting. And it didn’t freeze up network requests on other tabs on my phone. I STILL don’t know how it does that. I would love a fix. At least at some point I discovered opening a new tab with HN “unblocked” it somehow. SPAs have their place. It’s not everywhere. Just like microservices. And ORMs. And all the other “magic” that will solve all my problems.
- slightlyoff 4y ago
  You might try https://sh.reddit.com https://sh.reddit.com
  - consumer451 4y ago
    Thanks, I knew about www.reddit, old.reddit, i.reddit, m.reddit, but I didn't know about this one. I can't find any info on it, what is the goal of sh.reddit UI exactly? On another note, all kinds of interesting subdomains[0]. I wonder why a few subs get a subdomain? [0] https://domain.glass/reddit.com https://domain.glass/reddit.com

zeroonetwothree 4y ago

Similar article: https://biggestfish.substack.com/p/information-asymmetry-part-1 https://biggestfish.substack.com/p/information-asymmetry-par...

phendrenad2 4y ago

I disagree that JS frameworks are in any way a problem. React is not substantially different from developing a Rails frontend using um... what do the kids use these days? HAML? Hamlet! No, that's not right. Anyway... The real trouble comes when you think that "switching to <hot new framework>" will solve all of your problems. This is equivalent to thinking that giving your troops Scottish-made swords (when they've been using German-made swords) will somehow make them fight better. Armed with this disinformation, teams march blindly into the meat grinder of reality. "We need to do auth... again? Didn't we just do that in Django? And then Angular? Arghhhh". If your auth implementation in django was bad, and you rewrote it in angular and introduced problems, rewriting it in react is not going to magically make your developers do it right this time.

robin_reala 4y ago
React is not substantially different from developing a Rails frontend I think you misinterpreted the article. The developer experience isn’t what’s at stake here, it’s what the user experiences. And for 95% of systems (99%?) as simple Rails app will be faster than a React app.
- DangitBobby 4y ago
  I'm curious to see actual performance comparison metrics for a site written on rails versus one written on, e.g., Next.js.
  - robin_reala 4y ago
    Really the specific framework isn’t an issue: it’s down to minimising as much as possible the amount of JS you ship to the client.
- phendrenad2 4y ago
  User experience is affected directly by developer experience. If it's tedious, or complex, or error-prone, to develop using a framework, then the user experience will likely suffer.

stevebmark 4y ago

Does anyone else find this writing style hard to follow and alienating? The clever section titles, verbose passages, inflated vocabulary, and indirect descriptions, make it frustrating to read. Just say things directly.

slightlyoff 4y ago
Author of the article here. TL;DR: your JS is probably worse than you think. Write HTML and CSS instead. It will go better for everyone. And feel free to ignore the most popular JS framework vendors; they have not known what they are talking about for at least a decade.
- taurath 4y ago
  Do you have any examples of well trafficked sites with good UIs doing things well? It would seem that there might be outliers you might be able to point to
  - slightlyoff 4y ago
    Most are from a world that is better, but which the complexity merchants have convinced (thanks to asymmetric information) all but their closest competitors to replace with unwieldy tech. E.g.: https://app.speedcurve.com/benchmarks/usa/retail/fast/fully-loaded/ https://app.speedcurve.com/benchmarks/usa/retail/fast/fully-... The fast sites on "legacy" stacks have 1/10th the COGS for the same performance versus the absolutely stupid costs invoked for React/NG/Ember/etc. SSR + hydration. Which brings up the real issue: when the framework is both baseline-costly and runtime nasty, metrics like INP will suffer without extraordinary controls. When you see a React site in the list above, it's a fair guess that I've talked with their tech teams and they have felt trapped between unsubstantiated narratives and the reality that shipping React-based sites is losing them tons of money. The antidote is a frank discussion of up-front cost vs. per-interaction latency. And we aren't having that debate right now. Presumptively the careers of the last decade's charlatans depends on us not levelling up. It's the only reason I can peep for why we haven't evolved past new ways to spell old ideas.

locallost 4y ago

I agree with the article, but think it's poorly written. In a way, it's a bit like the developer work that its criticizing -- overly complex. One of the linked articles is much better and to the point: https://ericwbailey.website/published/modern-health-frameworks-performance-and-harm/ https://ericwbailey.website/published/modern-health-framewor... My 2c: I've seen good experiences, but a lot more poor ones. I've worked on them and they were n times more expensive for very little benefit. I don't think it's by design, but more cynical people might. I think it's just a dogma among developers and management too afraid to step in because developers hold too much power. They want to work on this because everyone else is, and if they can't they will go somewhere else and then you need to find new developers and everyone knows there aren't any available. We switched to a server side rendered spa stack because the developers said "don't want to be stuck on old fashioned stacks, want to work on cool things". We then needed twice the time and twice the developers to get things done. So basically the way out of this is for someone to hype up a server side solution and sell it as a shiny new thing. It needs to be logical in a way that makes lights in heads go on, but also somewhat mysterious and new. Deno Islands fit that mold, we'll see if it pans out.

cxr 4y ago
> if they can't they will go somewhere else and then you need to find new developers and everyone knows there aren't any available The recurring resume-requires-React pattern sure isn't helping.
Existenceblinks 4y ago
No "isomorphic" please. Please don't moving forward with js-everything, that's actually moving backward.

quxbar 4y ago

Has this author been on the other side of the fence? I have encountered, for every bloated javascript problem child, an equally burdensome python monolith, or sprawling maze of go microservices. I suspect the root cause is something to do with human error, but I digress. The benefit of much-derided React code when I can onboard new developers from 3 different countries and backgrounds and have them all writing DRY, tested, idiomatic code within a few days. They can then ship a feature that then provides more values to the end user, who probably doesn't care a fig what HTML is. Or, like a patient senior developer, they understand that shipping is preferable to not shipping, and that perfect performance, accessibility, and usability are all asymptotic to us mere mortals.

DangitBobby 4y ago
We are replacing truly the most disgusting codebase I've ever seen right now, a WP instance (alright) highly customized (worrisome) written by pre-for-loop contractors (uh-oh) which has over 10k lines of jQuery (uh-oh) for a relatively small site, but all of the jQuery lives in one main.js (UH-OH) and executes on every page whether or not it does anything to that page. It's also written in such a way that it crawls the DOM so many times on huge HTML payloads that the entire page slows to a crawl as your computer fan winds up. You'll often get 10 seconds of non-responsive page after the first paint. There's barely any interactivity here as well, just a couple of modals and buttons. As the client scaled up, they started having serious performance problems that rendered the site completely unusable for some users, and some pages were so bad on the backend that simply visiting a page could cause an outage. Refactorings were considered (minor ones attempted), but the code is so poorly written and brittle that it's actually easier to just fucking rewrite it, so they/we just do targeted performance enhancements, bugfixes, and minor updates while rewriting. All that to say, the worst codebases I've ever seen are PHP monoliths, (though I've seen some rough Django/flask as well) shitted out by contracting firms which bill high rates for code written by juniors. People (particularly those who frequent this site) are way too focused on the choice of framework when trying to assess these outcomes.

quickthrower2 4y ago

Despite all this NextJS has brought me a lot of joy using it. Probably the most joy of all front end experiences web or even desktop (and I quite liked WPF!) That said I get it: it can be annoying for the user when the site does unpredictable shit which it can sometimes do with a SPA. For example shit appearing just before you click an area of the screen so you end up clicking the wrong thing. The complexity is a problem too, there is a lot of shit to learn these days to get the app working. NextJS is like autopilot most of the time but you still gonna drop down and troubleshoot NPM dependencies etc. sometimes so there is a lot to know.

seanhunter 4y ago

Setting aside the FA for a second and considering just the market for lemons itself. Imagine being George Akerlof. You coined one of the most famous things in economics (the market for lemons), for which you won the Nobel Frikkin' Prize[1] and your spouse[2] is still a more famous economist than you. [1] Nobel Memorial Prize if you're a Taleb-inspired pointless hair splitter [2] Janet Yellen

profstasiak 4y ago
I studied economics. Akerlof is more famous economist. Yellen is famous political economist
- seanhunter 4y ago
  To be clear, I meant "famous person who is an economist" rather than "economist who is famous among economists" but I take your point.

oli5679 4y ago

For me the biggest source of unnecessary complexity is Kubernetes. If you use envelope math, you rarely need more than one reasonably sized instance, and your key performance bottleneck is database and external apis. Lots of people can get away with single machine running on Heroku/ec2, until their product logic becomes too complicated for a single dev team to maintain.

BuckyBeaver 4y ago

Did I miss it, or did the author not state what the better solution is?

BuckyBeaver 4y ago
[flagged]
BuckyBeaver 4y ago
[flagged]
- dang 4y ago
  Breaking the site guidelines like this will get you banned here, even if you're right or feel you are. Would you mind reviewing https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html and using the site as intended? You may not owe jagoffs better but you owe this community better as long as you're participating in it.
  - BuckyBeaver 4y ago
    [flagged]
deleted 4y ago
[deleted]
erik_seaberg 4y ago
> No, we need to move our attention back to the folks that have been right all along. The people who never gave up on semantic markup, CSS, and progressive enhancement for most sites. The people who, when slinging JS, have treated it as special occasion food.
BuckyBeaver 4y ago
[flagged]
- 4y ago

ebiester 4y ago

Is the author talking about information websites, websites with limited interactivity, or web applications that would feel more at home as desktop applications? I honestly believe that many of the complaints about SPAs as a bad paradigm don't solve themselves with progressive enhancement; they solve themselves with a better cross-OS development environment and safe, sandboxed modern applets. (Alternatively, your company needs to be homogeneous, and third-party vendors need to develop for both Mac and Windows, and hope Wine is good enough for any other option.) That leaves websites with limited interactivity. If the author is speaking about these, I can understand the frustration. I'd love to see solutions like liveview or htmx take over. Maybe other solutions will be good enough. However, for us to get beyond talking past each other on these conversations I think we need to always be considering the context and detail the use cases.

naet 4y ago

The author spends the bulk of the post (as far as I could tell from the opaque writing style) criticizing React and the React ecosystem. But when you see the first footnote for their recommended alternatives, many are very similar to React in practice. Notably: Preact (basically just another implementation of React) Vue (very similar ecosystem to React in terms of the mentioned SPA SSR etc) SolidJS Svelte Etc. Then some of the recommended alternatives to the SPA are just as complex or more complex than the things the author had just criticized, including Astro (SSR with islands), Fresh (denos edge based "just in time" SSR), Sveltekit (the same SPA SSR SSG etc complained about for React above). Not sure how these don't fall under the same opaque criticisms of the JS "lemon market".

CharlieDigital 4y ago
I think author's point is that React is the absolute worst of the evils and it's proprietors shout its false virtues so loudly that it drowns out all discourse and rational thought. It performs the worst (by a large margin) of the major JS frameworks https://krausest.github.io/js-framework-benchmark/2023/table_chrome_109.0.5414.87.html#eyJmcmFtZXdvcmtzIjpbImtleWVkL2FuZ3VsYXIiLCJrZXllZC9yZWFjdCIsImtleWVkL3JlYWN0LWhvb2tzIiwia2V5ZWQvc29saWQiLCJrZXllZC9zdmVsdGUiLCJrZXllZC92YW5pbGxhanMiLCJrZXllZC92dWUiLCJub24ta2V5ZWQvcmVhY3QiLCJub24ta2V5ZWQvc3ZlbHRlIiwibm9uLWtleWVkL3ZhbmlsbGFqcyIsIm5vbi1rZXllZC92dWUiXSwiYmVuY2htYXJrcyI6WyIwMV9ydW4xayIsIjAyX3JlcGxhY2UxayIsIjAzX3VwZGF0ZTEwdGgxa194MTYiLCIwNF9zZWxlY3QxayIsIjA1X3N3YXAxayIsIjA2X3JlbW92ZS1vbmUtMWsiLCIwN19jcmVhdGUxMGsiLCIwOF9jcmVhdGUxay1hZnRlcjFrX3gyIiwiMDlfY2xlYXIxa194OCIsIjIxX3JlYWR5LW1lbW9yeSIsIjIyX3J1bi1tZW1vcnkiLCIyM191cGRhdGU1LW1lbW9yeSIsIjI1X3J1bi1jbGVhci1tZW1vcnkiLCIyNl9ydW4tMTBrLW1lbW9yeSIsIjMxX3N0YXJ0dXAtY2kiLCIzNF9zdGFydHVwLXRvdGFsYnl0ZXMiXSwiZGlzcGxheU1vZGUiOjEsImNhdGVnb3JpZXMiOlsxLDIsMyw0LDVdfQ== https://krausest.github.io/js-framework-benchmark/2023/table... And is highly inefficient in both compute and space: https://timkadlec.com/remembers/2020-04-21-the-cost-of-javascript-frameworks/ https://timkadlec.com/remembers/2020-04-21-the-cost-of-javas... Comparatively, Vue for example, can be used progressively. It is one of the core reasons the Wikimedia Foundation and GitLab chose it: https://phabricator.wikimedia.org/T241180 https://phabricator.wikimedia.org/T241180 . Solid and Preact both perform close to Vanilla and bundle far smaller, improving the end user experience. One of Vue's main technical goals this year is Vapor mode (inspired by Solid) which should yield lighter, faster, and more modular client packages. My take is that React now is the worst of the major libraries yet the most heavily used. It's core design is fundamentally flawed so additional layers of complexity are needed to mitigate it. It doesn't make any sense except for the complexity peddlers who's fortunes depend on more suckers. If you watched the Next.js conf last year, you know what I mean. You can tell they invested a lot of money into production value. I watched a Microsoft developer conference shortly after and the difference was night and day. Ask yourself why Vercel needs to invest that much into a developer conference where ostensibly we developers want good tech, not flashy presentations. Who are they actually selling to? Working at a startup building on Next.js and React, I commiserate with the author's take on complexity peddlers. We have dozens of lines of code for what should take just a handful to do in vanilla. In look at this code everyday wondering why we have piles of JavaScript for very simple interactions. Most recently, a dev made some well intentioned changes that somehow changed Next to only output CSR (no server output HTML); thereby fully defeating the purpose. Now we have a server render cycle calling out to an API that returns JS to render on the client. Probably should just render on the client and skip the middle man! The senior eng team absolutely regrets going Next.js (decision made before I joined). We've been fleeced.

college_physics 4y ago

> We lost a decade to smooth talkers and hollow marketeering To eliminate lemon markets somebody has to be tasked (and rewarded) for doing the slog work that will reduce the information asymmetry. This would normally be trusted experts (tech journalism, academia etc).

xyzelement 4y ago

Few jobs ago I was a PM director at a scaleup and at some point our frontend platforms engineering (or something like that) came into my purview. This team didn't build front end experiences but tried to build out tooling in which other devs would. Which was weird to me given that we didn't do anything extraordinary in terms of experience so off the shelf stuff should have worked. I think this was some evidence towards the point in this article. Two things were at play: First, the gross complexity of the available frameworks made it seem like something like this was necessary. Second, the people involved were excited to further their careers on this, so motivation to call out unneeded complexity was low. If I had owned this space from the start, I'd have asked the question of "what business outcomes does this enable which we can't achieve at least for a while, with static-ish html, forms, etc" and maybe allow a little complexity where justified. But since it was purely engineering owned for a few years before it got to me, it was way too late to reign the complexity and we ended up doing shit like porting from one framework to another.

danielvaughn 4y ago
One of the mantras I like to chant is that your job as a developer is not to write code. Your job is to implement solutions to business problems. I didn’t understand that until I became a manager. Your whole perspective shifts because you realize that salaries don’t just grow on trees.
- nine_k 4y ago
  "Lines of code are not produced but spent" (Dijkstra)
- jiggunjer 4y ago
  Unless you work for government.
patrickthebold 4y ago
One thing to consider: a lot of devs are most familiar with React and some set of tools in it's ecosystem. Sticking with what you know is generally good advice. Especially if you consider hiring and onboarding.

tambourine_man 4y ago

The article is a bit too bitter for my taste, but I agree with most of it. Except for the developer experience improvement these frameworks supposedly offer, I don’t even buy that. For over a decade it seems to me the industry has been enamored with crazy complex solutions to problems that mostly don’t exist. I keep reading their proposals in dismay and basically chugging along with almost the same stack as before. Clients are as happy as ever. I tried to show (here and elsewhere) that, for instance, PHP/MySQL + HTML/CSS/VanillaJS is faster, easier to read and write than React/Angular/FrameworkDuJour, but we seem to live in different worlds. I still think jQuery was the biggest improvement in frontend development quality of life and hasn’t been matched since. I’ve mostly resigned to believe that React and friends are maybe great for hiring, being hired, manage teams. Actual coding is another discussion altogether.

Sai_ 4y ago

I wish I knew what the author was fulminating about. This article is in dire need of examples and case studies but instead, the author says that it is hard to summarise a “decade” of JS/SPA bloat into one article. Anyway, to his point about the market for JS frameworks shrinking, I’ve moved my projects to HTMX + AlpineJS. Couldn’t be happier though the entire apparatus seems to be holding together with wire and spit and prayers.

jFriedensreich 4y ago

My god, this article reads like a non fiction incarnation of "infinite jest" its basically impossible to understand the authors concrete intent and meaning of whole paragraphs without reading the footnotes and the linked articles while reading the post. And if i understand it correctly, it completely misses the point who is to blame. Angular and react solutions were seldom sold from an actor with deep information to a manager or business with less information. In my experience the top 2 situations were a) managers/half-technical founders wanted what they had read about and google or facebook were backing and did not want to hear about a proper evaluation, b) devs and whole dev teams wanted to just use what they knew and read about 100% thinking this was the best solution because of their inexperience and lack of reflection. The first is just your usual ignorance towards the experts by buzz word driven and half-knowledge managers, the latter could be more likened to the brainwashing of cult members than intransparent market situations.

giaour 4y ago
> And if i understand it correctly You did not. Per the article, the "buyers" of SPAs are the developers and teams who heard about a technology and thought it would be the right tool.

iamsanteri 4y ago

SPAs were a zero interest rate phenomenon :’DDD I laughed so hard

twodave 4y ago

I think there’s a bit too much “blaming the tool” going on here. Be reasonable about what you introduce into a software project. If it’s a bunch of CRUD you probably can wait to add a front-end framework. If you find yourself needing it for that one big feature where you have to implement drag-and-drop and a bunch of DOM manipulation, don’t rewrite your whole app, just tailor that one experience. If you don’t NEED a high level of server communication or data continuation between components, you probably also don’t need any crazy state management. And again, when you build that one wizard experience that really needs something more, tailor the solution local to that one experience. Not to say that larger and more complex projects don’t exist, but for most things you can get away with a lot less, and there’s balance between performance, developer joy and increasing productive capacity.

sublinear 4y ago
> Be reasonable about what you introduce into a software project. ... don’t rewrite your whole app, just tailor that one experience. You just described exactly why most web devs strongly prefer to build SPAs today instead of using SSR (separation of concerns).
- twodave 4y ago
  Well, I think the main difficulty with SSR is you'd think it would be more of an incremental step. I don't think it's so much a "separation of concerns" issue (i.e. just having some of your presentation logic running on-server doesn't mean it's necessarily not isolated logic) as it is a "wow I have to rewrite significant parts of my application to take advantage of this" issue. Some frameworks definitely do a better job with this than others IMO, but not everybody wants to (or should) migrate their React app to NextJS (for example) just to get SSR.

IYasha 4y ago

Hilarious. The page isn't rendering as (I think) it was intended - half of the screen literally sticks to the top. Maybe the author went too far with his point %) Otherwise, I generally agree. )

vikR0001 4y ago

In the author's footnote #1, he praises Svelte and Vue. So the whole article boils down to "Don't use React, use Svelte/Vue instead."

bambax 4y ago

TFA is a rant that seems mostly targeted at React, judging from the links/examples. The article is not very clear or easy to follow but it still has a point. All modern frameworks are ridiculously complex, esp. given the fact that modern JavaScript is extremely versatile, with classes, modules, web components, etc. A new empty Angular project via the Angular CLI copies almost 40,000 files of node modules (350 Mo), which is apparently considered "very little space" by today's standard (actual quote from a SO answer). It's all quite demoralizing. I actually like SPAs! and I agree that state must be managed on the client somehow; but this is insane. Plain old JS with some Redux, querying a well thought out and simple API on the server will get you a long long way.

nnurmanov 4y ago
And there are a number of vulnerabilities with those packages, which are not being fixed. I think NPM should remove any package that are not maintained or have severe (any?) vulnerabilities. IMO, we have too many packages,some restriction to publish will be good.
_fat_santa 4y ago
As someone whose worked with React/Angular/Svelte/etc for the past 5-6 years, the biggest benefit and the biggest hurdle to these frameworks is the complexity. The complexity in these frameworks has resulted in us being able to build massive complex applications, but if not done with the proper level of care, that application will be a performance crap sandwich. And that I would say is the biggest problem with these stacks, they are incredibly powerful and can get you places but you have to know how to use them! If you are an experienced web developer you should be able to pick up these frameworks and run with them. But the problem arises when you have a team made up of a number of Sr developers along with Mid/Jr devs. The Sr devs might know all these footguns and hurdles, but the Jr's/Mid's might not. With a small team this gap in knowledge can be effectively managed but the issue really becomes apparent when you have multiple teams, all with the same makeup. But say you are building an app with a very experienced team and don't run into the knowledge issues above, well you can still have issues depending on your vendors. In this case I'm talking about say a chatbot or some other integration into your app where the vendors team wrote said code. In this case you have the same issue where you can have the most experienced devs on your team, but if the vendor wrote some crap code, you're going to have issues in your app. All of this is to say, applications have just become massive recently, and managing that complexity and making sure your application stays performant gets harder and harder.

AlbertCory 4y ago

Yesterday there was a post for Patterns, an AI framework. Deja vu. Pretty soon everyone and his school buddies are going to be putting out frameworks for building an AI-enabled application, if they aren't already. And eventually Microsoft and Apple will incorporate one into their developer products, and maybe some of those VC startups will get acquired.

christophilus 4y ago

Every non-SPA that I’ve worked on ended up accreting interactivity to the point that I’d wished we had started with a single, unified, well-structured way for managing the UI that handled interactivity well. I used to do a lot of native Windows apps in C, VB6, and C#. To me, Preact + TypeScript is as good in many ways, better in some, and worse in others— but it averages out to be just fine from a developer perspective. I personally don’t miss the old native UI days. The majority of jank that I see on the web is not due to React or Angular or whatnot. It’s due to ads, trackers, and to product owner’s inability to say “no” to piling a million things into important screens. It is a misplacement of blame to blame React.

asherah 4y ago

the author recommends in the first footnote to use other frameworks like vue, svelte, lit/polymer etc., which makes this seem more like an argument against react, when the entire article is about how javascript-driven spa/ssr stacks are bad. there are a couple clarifications next to it to soften that blow but react also "start[s] with simple output" in the same way these tools do. why act like react is the only lemon merchant? i say this as an active user of vue, so maybe im simply at the most complex of them but from my perspective the other tools are about as complex