13 ms·

Moving on from React, a year later

• kellysutton 2y ago
  A friend mentioned this made the front page. I'll try to answer any questions on our approach at Scholarly. Thanks for reading!
  • Swizec 2y ago
    > Let’s assume that making a JS change costs twice as much time a Ruby change, which I think is being generous to JS I don’t grok this part. Based on my experience with RoR and JS/TS, making changes in TS-land is much easier and quicker than dealing with Ruby. Is this just a preference/experience thing in the end? For you and your team RoR is faster/easier, so that makes it the better choice. For a different team JS/TS may be faster/easier, so that makes it the better choice?
    • kellysutton 2y ago
      Haven't written much TS, so can't speak to that. I should have made the distinction between client-side and server-side JS/TS. Familiarity and expertise will be a main driver of productivity for a team, regardless of language/framework. For us, that's RoR. Client-side JS however has a multiplying property, where we often need to write more server-side code to accommodate the growth in client-side code. If the client-side code is providing undifferentiated value (e.g. authoring HTML), we now have more pieces in our system to accomplish our goal (author HTML). What's been surprising to me is that you don't need to author HTML client-side to have a reactive experience. With Turbo, Stimulus, and server-rendered HTML, a great experience is possible with fewer layers.
      • Swizec 2y ago
        Great answer. Thanks! I think the power of fat clients comes when you have different consumers of the same APIs/logic. Like a browser app or two, maybe backend services, a few task queues, etc. Then having a clean separation between client code and business logic becomes super valuable. In my experience with SPA we got to a point where my team could go weeks, even months, without having to make changes in server code. Whole new features that were fully supported by our existing APIs because they were written as reusable APIs. If you’re having to write a bunch of Rails to support the growing client code, you probably didn’t need a separate client yet. But when your codebase gets to that point even Rails is just a frontend really. So it’s mostly about which tradeoffs you prefer. Unfortunately I left Rails right around the time Turbo was becoming a proper thing you could use so I don’t have the best feel for what it’s like.
  • evanmoran 2y ago
    Thank you for writing this all up. Just curious if you ever considered switching away from Ruby? I think many people are living in parallel stacks (TS, Go, Python, Rust) and it would be interesting to hear how it’s been going more recently in that ecosystem from your perspective. As to rendering, I’ll be honest and say that my code has moved more towards client-side (using ConnectRPC and my framework ojjs.org—-shameless plug :), but I love that you have had success with a different path. Super interesting, and thanks again!
    • kellysutton 2y ago
      I don't have a reason for switching away from Ruby at this point in my career. Things can always change down the line. Maintaining multiple languages at the same layer sounds like a personal nightmare to me. I'd rather learn to write PHP and have that be the only language, than to write Ruby+another language on the server-side. We're building our company on Rails because we think it's the best choice for a young company, since it allows us to respond to customer feedback more quickly. That's what we're optimizing for right now!
  • fareesh 2y ago
    Did you give inertia a try?
• abc-1 2y ago
  I was apprehensive at first, but it seems like it works for them and they make some interesting points.
• stevage 2y ago
  Never thought about SSR making your code more testable. That sounds pretty appealing. Also, does p50 mean median?
  • kellysutton 2y ago
    Yes
  • SrslyJosh 2y ago
    It's much simpler to not write an entire second application in the fucking browser, which is what React et al frequently entail.
    • meiraleal 2y ago
      by fucking browser you mean the client? That's actually the most important place you want to have an application, unless you are developing a blog.
    • stevage 2y ago
      Depends on your perspective. Everything I write is in the browser, there's very rarely much server side bit.
• tyre 2y ago
  > Let’s assume that making a JS change costs twice as much time a Ruby change, which I think is being generous to JS. Everyone's mileage varies, of course, but this is quite the assumption. It feels like a lack of familiarity/comfort with the frontend or poor tooling. With typescript and a basic UI library like MUI, this really shouldn't be the case for UI changes. If you're using raw JS and manipulating the DOM, maybe?
  • GiorgioG 2y ago
    [flagged]
  • mvdtnz 2y ago
    My experience with very highly paid frontend developers is they like to spend hours and hours (and thousands and thousands of dollars) building out little libraries and components and frameworks that will enable other teams to be faster. Except this never eventuates because things rarely turn out to be reusable along the right axis so a new component or library or framework is developed to solve the problem. On top of this UI developer propellor-heads love to spend time (and money) pontificating on abstract theories about functional programming and homomorphisms and endofunctors so they can render some text inside a <b> tag. It's how we wound up with utterly ridiculous pieces of code like the "hooks" API in React.
    • goosejuice 2y ago
      I also get the feeling that modern frontend is a massive money pit but this seems to be a leadership problem. I wouldn't go so far as to blame the IC. There are developers over-engineering in every ecosystem.
      • Earw0rm 2y ago
        Something about the psychology of front-end - not quite as hardcore technical, a little more humanities-aligned - perhaps makes them even more susceptible. The self-consciously cool kids are always going to be more easily swayed by fashion than cave hermits.
• bloomingkales 2y ago
  Maybe it’s the changing interest rates or political winds, but I think the “fat client” era JS-heavy frontends is on its way out. This is just not going to be true. It’s an AI world and we need to funnel so much high velocity text and dynamic UIs to provide a high fidelity experience. Investing in static server rendered pages is just a surrender, the long surrender that people desperately seek from the onslaught of JavaScript. But it won’t happen, it will either be JS or another language, but server side pages is the wrong bet.
  • kellysutton 2y ago
    I'd encourage you to spend an afternoon kicking the tires on Turbo/StimulusJS, HTMX, Laravel Livewire, or Phoenix LiveView!
  • SrslyJosh 2y ago
    [flagged]
  • thomasfromcdnjs 2y ago
    I can't agree with the quoted sentiment either. Even I attempt to remove all my bias, most of the tools I use to work (app developer) are fat javascript clients.
    • bloomingkales 2y ago
      Yeah. There’s been a little bit of a puritanical pursuit back out of SPA on HN (it might actually be isolated to here honestly, almost like a local band that plays in the neighborhood), but it’s an emotional over correction (imho) to the exhausting JS climate. Nevertheless, the facts on the ground are the facts on the ground.
  • remram 2y ago
    [flagged]
• 65 2y ago
  I got so sick of having to deal with thousands of dependencies with a React project, I manually implemented JSX to string components (e.g. building with ESBuild then writing the createElement and fragment functions as my own package, which would return a string to render server side), added Alpine.js, and it's just as, if not more productive than standard React. So many fewer packages to deal with (especially if you want to SSR your app), and my site is way faster. And I get to use JSX which is my favorite templating engine and requires little porting from my React app. I suggest people really take a look at Alpine.js, you can do everything in it as you can with React and it's a significantly smaller, simpler package that runs right in your browser.
  • jack_pp 2y ago
    Can you provide more details about the project you are talking about? I somehow doubt that a website like facebook would be easier to write and manage in a minimalist framework. I'm not sure the only project I have written React for would compare to something like facebook but it was a pretty complex SPA that I seriously doubt would've been better written in something like alpine. Sure React may be overkill for a personal blog and no one is saying it isn't but I wish people that have ported from React also assess honestly the complexity of the app we're talking about
    • 65 2y ago
      I have a website I use to host all my personal software. This includes a front end portfolio with various somewhat complicated data applications, I have a personal notes app, RSS reader, content feed algorithm, games, e-book reader, and S3 file manager. You are definitely right that complexity isn't as big in terms of number of users (for me, it's one), though I'm still making functionally complex applications. Facebook is obviously going to have a ton of shit going on all at once, though for the vast majority of sites it's mostly just some form or another of CRUD with perhaps some somewhat complex front end UX. You can build many web apps without React. To me the secret is with JSX, which makes everything way easier to manage. Realistically the only issues with using a more minimalist framework instead of React is global state management and persistent components on page navigation. Global state management in Alpine can be done with Alpine.store and persistent components can be implemented with either Hotwired Turbo, Alpine AJAX, or HTMX. Are these things better than React Context/Redux and React Router/Next Router/Some other router? Probably not. But it does work. I wouldn't recommend this approach for actual businesses, mostly because devs will already know React and thus be more productive. But I think it's genuinely a viable approach for building web apps.
• elchief 2y ago
  Went all in on the BALL stack (bootstrap, alpine.js, laravel livewire) and couldn't be happier
  • uncomplexity_ 2y ago
    > BALL Stack Remove the T, it's cleaner.
• deleted 2y ago
  [deleted]
• deleted 2y ago
  [deleted]
• forrestthewoods 2y ago
  The only UI framework I’ve ever used that I didn’t absolute hate is DearImGui. I realize it doesn’t produce polished, professional looking UIs. But my god is it the only thing that doesn’t suck. JavaScript and ReactJS are at least 10 times less efficient to write than C++ Dear ImGui. That’s so crazy.
  • andrewmcwatters 2y ago
    Dear ImGui isn't for end-user facing UI.
    • forrestthewoods 2y ago
      Did you read my whole comment? It feels like you didn’t read my whole comment. Because I said “I realize it doesn’t produce polished, professional looking UIs”. I don’t think that’s an intrinsic quality of a DearImGui type API design. I’m reasonably confident it could produce a professional end-user facing UI. And that it would be perfectly performant and battery efficient.
      • lmz 2y ago
        Good luck making that immediate UI accessible.
        • forrestthewoods 2y ago
          Why is immediate-mode fundamentally incompatible with accessibility?
          • lmz 2y ago
            React is "immediate" so it probably could work. However the accessibility tools in that case operate on the rendered DOM layer. Without such a "retained" structure it would be very hard. You can imagine web accessibility tools wouldn't like it either if you rebuilt the whole DOM on every change instead of only updating the changed parts.
• andrewmcwatters 2y ago
  I removed all of our React and replaced it with Web Components, and I'm not missing anything. I'm sticking to cached static resources, and just sending data over. Not rendering from the server, but not writing single-page apps, either. The more you render from the server, the larger your caches end up. Not doing that for HTML. Just HTML, CSS, and JavaScript. No tooling. No building. Web Components and fetch(). No frameworks on the client-side. Express still on the server. I'm trying to optimize for not swapping out dependencies on a several year scale, and it's working out pretty well so far. I removed React because they're not interested in UMD builds anymore, and I'm not going to jump through hoops to make it work on my end, either.
  • morganherlocker 2y ago
    Same, and I've found this works quite well with a C++ backend. Just send over binary data as struct-of-arrays, load it into typed arrays, render components. Your app will be bottlenecked only on bandwidth, as it should be, even for heavy 3d applications. There's nothing fundamentally stopping react apps from being fast like this, but the dependency snowball has a way of hiding accumulated dynamic memory allocations and event listeners. Instead, we should be intentionally grouping allocations and events, keeping them contained to a few well understood pieces of code. Without this, these apps could be ported to native C++ or rust and they would still be nearly as slow because there is no magic language that can make a slop of millions of tiny dynamic allocations fast and low overhead.
    • kopirgan 2y ago
      C++ backend? Could you elaborate please?!
      • morganherlocker 2y ago
        If most data between the backend/frontend is raw numeric array binary blobs, and you target array types that can be loaded directly into JS TypedArrays (int32_t* -> Int32Array, float* -> Float32Array, etc.), you have a more or less optimal data transfer mechanism with zero dependencies. The JS parsing is faster than the fetching, even with 10s of millions of items, provided you keep the number of arrays fixed and reasonably small. This is a natural fit for data-oriented programming in most systems languages, including C++. It's also compatible with numpy and any other dynamic language backends that have a performance-oriented array primitive or lib. The data can be served dynamically from memory, or written to files on a static server like nginx.
• willsmith72 2y ago
  > p75 at 350ms Is this really that impressive if you're prefetching? Surely a cached response is <50ms always. What's the prefetch cache hit rate? If it's anything like remix/react router prefetch caching, it's also useless on mobile. Depending on your target market, that's a huge difference
• sc68cal 2y ago
  I was worried that an application I was building in Django, with a frontend built with Bootstrap and some LIGHT jquery was making me look like an old curmudgeon but the part about testability of the frontend really resonated with me. It was MUCH easier to structure everything as pytest unit tests and completely rely on Django for all the business logic rather than trying to put state in the frontend and deal with synchronizing states between FIVE distinct systems (remote devices, the Django application, the database, an event stream, AND the front end). I recognize that I'm not hip or with it, because I really fell out of front end development at the peak of jQuery where it was mostly about fixing browser incompatibilities, but it's nice to see that maybe it went too far in the other direction and we're overdue for a bit of a swing back towards server side.
  • pinoy420 2y ago
    Serverside rendering is apparently a new technology now. And this brand new thing called islands which someone reinvented recently.
    • emptiestplace 2y ago
      It's back, but the nice thing is it's 10x more complicated now!
      • khana 2y ago
        [dead]
      • mattmanser 2y ago
        And in slow javashit!
        • otabdeveloper4 2y ago
          So, an overall win for software developers and cloud providers?
    • belter 2y ago
• overstay8930 2y ago
  Watching Meta rewrite Messenger twice without success was enough for me to never touch React for any large project, especially after that botched e2ee chat rollout.
  • cwalv 2y ago
    You think the major complicating factor of rolling out e2ee was that they used react?
    • overstay8930 2y ago
      Given I was able to see the errors directly in the js console, yes. You used to be able to break everyone's state by putting an emoji in a URL.
      • fsociety 2y ago
        I was hoping for stronger rationale than this. This is not a React-specific problem.
        • overstay8930 2y ago
          Of course it's not a "react problem". It's a skill issue created by the reality that React is incredibly difficult to scale in large projects. If Meta cannot even handle React, what hope is there for the rest of us?
  • gejose 2y ago
    You really think Messenger isn't successful? You think any issues Messenger had was because of react? Do you have sources on this?
    • overstay8930 2y ago
      I didn't say Messenger wasn't successful. I said that Meta rewrote Messenger twice and did not meet their internal goals both times. Even today you can see Messenger completely break down if you have to sync for more than ~30 seconds. JS console fills up with errors about your broken state as you start to lose messages. Local storage is out of sync, session state breaks, and it's all right there in the console. It's been like this for years on WebKit. React just has too many bugs for a complex behemoth like Messenger. React Native is just as bad and basically everyone I know in real life can corroborate lost messages, broken group chats, horrible photo experiences, and memory leaks! You can just look at Messenger vs WhatsApp and the difference is just night and day in the user experience. The e2ee backends are the same (according to my pcaps, I could be lying), it's purely the front end that changes - and you won't find anyone that says Messenger is better than WhatsApp.
• arvindrajnaidu 2y ago
  Do you also have a native app? How do you plan on using your current setup with Swift?
  • stephenhuey 2y ago
    How about Hotwire Native? https://native.hotwired.dev https://native.hotwired.dev https://pragprog.com/titles/jmnative/hotwire-native-for-rails-developers https://pragprog.com/titles/jmnative/hotwire-native-for-rail...
• insane_dreamer 2y ago
  > Many interactions are not possible without JavaScript, but that doesn’t mean we should look to write more than we have to. PREACH. And many site actions can be handle server-side without degrading the user experience.
• senti_sentient 2y ago
  The older I get, the more I find myself gravitating toward building with Express.js, using front-end HTML with a touch of Alpine.js—and that covers 99% of my use cases. React is mostly an overkill.
• htmxsucks 2y ago
  HN is not real world, just like how Reddit is not real world. I am a FE with 10 years of experience, and has tried, and tried really really hard and multiple attempts to make HTMX works well. Doesn’t work. UX is much worse, code discoverability is much worse, slower to code in, everything is messier than just plain React SPA with JSON data. Terrible, terrible DX and UX. Seriously, there is a reason why despite all the rage in going back to multi page Django/Rails app, very very few people actually take it seriously. You just don’t hear the negativity because most folks just tried it, saw that it is worse, and moved on without writing a blog post.
  • Epskampie 2y ago
    I'm a freelance webdev with 15 years of experience, and recently I've made some new projects with Symfony Stimulus & Turbo to great success. A few thoughts: I tried just htmx too, too limiting. Stimulus/Turbo combination is much better. Use the right tool for the job. Highly interactive app, like an editor? Use react or similar js framework. Mostly page/document website? A backend framework is much faster and easier to develop, and much simpler to test. Use what you know yada yada.
    • fullstackchris 2y ago
      A blend of both? Drop in a React component where needed on a given page! People forget (me included) that even React can be mounted into a single DOM element. With all this framework nonsense its hard to forget at the end of the days its all just javascript.
      • deleted 2y ago
        [deleted]
      • mst 2y ago
        If you're doing something something reasonably small, using preact rather than react and then wrapping it into a web component so you can just ... put it in there ... is a really nice option to have. (it may not be the right option in any given case, but it's worth knowing it's there even so)
• phaedryx 2y ago
  I think the idea of "sprinkling" JavaScript into your server-rendered HTML is a good one. However, I think that Stimulus is terrible. 1. There isn't a good way to test it. There is nothing in the docs about how to test it. 2. Keeping state in the DOM is dangerous 3. Messaging between Stimulus controllers is painful 4. They disconnect parameters from functions. The functions have to scan through the DOM to find what they need which I think is fundamentally weird 5. Reusability is rare 6. It doesn't try to play nice with the larger JavaScript ecosystem. I personally prefer Vue.
  • nchmy 2y ago
    Care to elaborate on #2?
    • tomnipotent 2y ago
      In the "old days" I'd colocate data as HTML attributes: <div data-parent-id="1234" data-category="Article"> We'd use this data for any number of purposes to build out other little features that'd rely on the attributes.
    • phaedryx 2y ago
      I remember when Backbone first came on the scene and “get your truth out of the DOM” was the rallying cry. I'm going to cheat and get a list from AI: 1. Difficulty in maintaining and debugging: When state is scattered throughout the DOM, it becomes challenging to track and manage, leading to code that is hard to maintain and debug. 2. Performance issues: Frequently querying the DOM for state information can be more expensive and slower compared to accessing data stored in JavaScript objects or dedicated state management solutions. 3. Lack of a single source of truth: Storing state in the DOM makes it difficult to establish a centralized, authoritative source for application data, which can lead to inconsistencies and errors. 4. Synchronization problems: Keeping DOM elements in sync with a mutable list of data can quickly become complex, especially when dealing with dynamic lists or elements without unique identifiers. 5. State persistence issues: DOM-based state is vulnerable to loss during page refreshes or navigation, which can lead to poor user experiences, especially in single-page applications. 6. Scalability challenges: As applications grow, managing state in the DOM becomes increasingly cumbersome and can result in performance bottlenecks. 7. Difficulty in implementing advanced features: Techniques like time-travel debugging, state snapshots, and easy hydration become more challenging or impossible when state is primarily stored in the DOM. 8. Increased complexity in component communication: Relying on DOM for state can complicate the process of sharing data between components, potentially leading to prop drilling or other anti-patterns.
• oDot 2y ago
  Unfortunately for many of the HTMX/Turbo people, they did right to identify the problem but they have the wrong solution. The way to alleviate those issues is not to bloat the frontend with things that shouldn't be in it nor is it to fragment the code base with never ending "sprinkle" of JS. The best solution is something like Gleam's Lustre, where you use the right tool for the job, while keeping a coherent code base: https://blog.nestful.app/p/gleams-lustre-is-frontend-developments https://blog.nestful.app/p/gleams-lustre-is-frontend-develop...
• henning 2y ago
  I have a 6k monitor. why are you embedding a 1400 px image I can view fine into a little 640px column which makes it hard to read?
  • kellysutton 2y ago
    Sorry. Will try to fix
• ec109685 2y ago
  Server rendered HTML is all well and good until you want to add native apps or a first class API layer. At that point, it makes more sense to have the web be just another client and move as much business logic into the API layer as possible.
  • neeleshs 2y ago
    Even with react, we have found that having a separate API layer was more ergonomic. Maybe with graphql it is different
  • timr 2y ago
    There's absolutely nothing preventing you from emitting JSON (or whatever) API responses from the same controller logic that renders HTML. Rails makes it easy.
    • ec109685 2y ago
      A native app is more than just translating each html page into a screen. You’ll likely want to build a data model that you use throughout the app, instantly load as much of the next screen from data already fetched as you can, etc. Having a flexible API tier makes that more ergonomic.
      • timr 2y ago
        Nobody said anything about translating pages into screens. The point is that the data model (and hence, the API design) applies equally to a web UI or a native application. The issues you're raising also matter for making webpages fast. When you think about the data model design before you make the presentation layer, in almost all cases, the choice of what you render is basically a straightforward transformation.
        • hombre_fatal 2y ago
          > Nobody said anything about translating pages into screens. Well, someone did. The person above them said you can just map your Rails html routes into JSON returning routes (translating pages into API endpoints). Which obviously gives you a suboptimal API since data access is tied to Rails pages instead of having a flexible, deliberate API. And once you build and have to maintain the latter along with the former, you are now duplicating work. It's a familiar issue for people who have built SSR apps.
• cyberax 2y ago
  > One of the arguments for a SPA is that it provides a more reactive customer experience. I think that’s mostly debunked at this point That's not true. You absolutely can make edge applications faster than anything running server-side. A great example is Linear, it can switch between issues within 100ms (it even supports hjkl keys for navigation!). But this requires you to be EXTREMELY careful. In case of Linear, they're using a sync engine to replicate the data onto the client side, rather than doing the request/response model.
  • JodieBenitez 2y ago
    > A great example is Linear, it can switch between issues within 100ms (it even supports hjkl keys for navigation!). That's nothing special and definitely easy to achieve with a server-side backed MPA.
    • cyberax 2y ago
      A triple handshake to a datacenter across the US is already ~80ms. It can be mitigated with HTTP2/3 but that still leaves you with not that much time to serve the request. It's certainly doable, but not at all straightforward to make it reliable. A local app, on the other hand, does not depend on the network latency and the server load.
      • deleted 2y ago
        [deleted]
      • JodieBenitez 2y ago
        But then... if no network latency I would expect much better than 100ms.
        • cyberax 2y ago
          It often is. I'm just saying that even for pretty complicated cases it's still within 100ms.
  • 2y ago
• temporallobe 2y ago
  Angular apologist here. Learning curve is somewhat steep but I can be immediately productive in it and testing is built into the framework as a first-class citizen. Routing, debugging, state management, SSR, it’s all there. I like the separation of controllers, HTML, spec tests, and CSS because it allows the developer to reason about these separately. DX is damn good. In fact I recently whipped up a front-end UI in a few days using the BAEL stack (Bootstrap Angular Electron). You still need the data layer of course, but this would be true of any UI framework unless you want to go full monolith like Rails (which I still fully believe is a superb solution). And having done Rails, React, Angular, and a mishmash of other frameworks, libraries, and architectures, I can say that a “pure” Rails app out of the box is impressively good for most use cases, especially now with Turbo.
• est 2y ago
  I think the key takeaway of the article is: > Code is not an asset, it’s a liability. > What is the least amount of code we can write and maintain to deliver value to customers? regardless of HTMX/Bootstrap/react, the simpler the better.
• xutopia 2y ago
  I’m building an application with much the same stack and it’s refreshingly easier for a one man shop to use the tools he describes. I used React at my previous job and it feels like a nightmare thinking about it again. Hotwire is a simpler approach that pays off.
• sonicgear1 2y ago
  From slop to even bigger slop, congrats!
• RangerScience 2y ago
  FYI - There's some neat ways you can embed React components inside Rails templates. Basically - embed the props in a template-managed `script` tag, and use Stimulus to mount the react code, passing in the props read from the DOM. Now your React is pure state-to-view, no need to synchronize anything, - it's really just a handful of React components instead of a full React app. That said, AFAICT, there's just two advantages: 1. Those annoying little UX doohickeys that actually DO want that level of interactivity 2. You can use any of the vast library of existing React components (for me, that's been react_big_calendar) As a bonus (and, why I rolled my own, since `react_on_rails` doesn't support these), and with a bit of tweaking: 1. It plays nicely with Turbo. I can use Turbo to update my React props and it just... works. 2. You can embed a template as a child of the React component. 2a. This also plays nice with Turbo. It sounds a little screwy, but so far it's working well, and it feels like it lets me use the right tool for the right job - aka, Rails for everything except the stuff with extremely high interactivity.
  • fareesh 2y ago
    I do this too, it works well
  • jnathsf 2y ago
    Amazing! I would love to see a blog post or a gem that unlocks React components with a Rails + Stimulus/Turbo app.
    • caiohsramos 2y ago
      https://evilmartians.com/chronicles/the-art-of-turbo-mount-hotwire-meets-modern-js-frameworks https://evilmartians.com/chronicles/the-art-of-turbo-mount-h...
    • RangerScience 2y ago
      I intend to! And to wrap it in a gem; I’ve got it partly there, but it’s a currently a mess as I ran into a bunch of “oh that didn’t actually work” problems at various points. I’ll post a link later… Edit: Ach, sorry - it's going to be awhile, when I went to roll my own I did it inside my project, so it's not even close to being available as a gem :/
• jillesvangurp 2y ago
  We're four years into a journey that shouldn't have worked but did. I have a lot of experience with mostly server side JVM stuff and a little bit of frontend. Before 2020 that was mostly standard stuff including a largish javascript /typescript project and a bit of react. In 2020 I took over the skeleton team of a startup. My main (junior) developer had a bit of Android and Kotlin experience; not a lot. We had no resources to get more developers. I was focusing on building the backend, which barely existed at that time so it was all new code. I picked spring boot and Kotlin for that. We needed web and IOS apps in addition to Android and the Android app (the only thing that had been built) was a bit of a mess and honestly there wasn't much worth keeping. And with just one developer it was clear the replacement was going to be a web app. The obvious thing would have been to potty train my junior developer on react/typescript and hope that after a few months he would become a bit productive. Instead I took a wild bet on kotlin-js. I honestly did not expect that would work. But it did. We did a brief research spike. Very successful. My junior developer did all the work. And we continued from there. I always had the plan to at some point just parachute in more developers and re-do it properly. But that never happened and nor is it needed. Fast forward a few years, we still work with kotlin-js. Over the last four years that became more stable and better supported. It's great. It's a four year old UI code base and we're making lots of changes with confidence all the time. Kind of the gold standard for a good code base. It sure has its issues but it's under control. Mostly I can't tell the difference whether I'm working on server or frontend code. It's all Kotlin. Kotlin multiplatform ensures we can reuse a lot of code on both. So the default place for code to go is in some multiplatform library. Which then ends up being used on both server and client. We use a small, obscure UI framework for kotlin-js called fritz2. It emulates a lot of what react does but in a Kotlin friendly way (strongly typed, co-routines). We use tailwind for styling (after some adventures with other stuff) and are slowly converging on maybe adding daisyui to that mix (which is nice). A lot of stuff in browsers is of course asynchronous and as it turns out, Kotlin's co-routines are awesome for that stuff. We have a lot of long running or recurring stuff happening in background co-routines. Handlers are suspend functions, etc. Integrating existing javascript frameworks is fairly straightforward. We have a few of those. Things like maplibre and a few other things. The point here is that frontend code doesn't have to be Javascript and it doesn't have to be miserable like many Javascript projects become. Where you run your code and what language you pick for that are two independent choices. And if you have proper well designed code, it should be testable. Just because it runs in a browser is no good reason for that to stop being true. I wouldn't recommend my choices four years ago. But at this point browsers run a lot more than just Javascript. Getting stuck with that stuff is a choice, not a necessity.
• girvo 2y ago
  > but I think the “fat client” era JS-heavy frontends is on its way out Look, you might be right! I still think it’s not the right tool for all situations. But this has been said over and over for at least ~7 maybe 8 years for what I can remember and it’s yet to be true, for better or worse. We’ll see though!
• sharpesttool 2y ago
  By that chart, it looks like you moved that code to the server. Which is fine - I prefer the back end these days too - much easier to monitor and reason about. Especially for a cloudy app. Not so great if you are going for the offline-available featureset though.
• deleted 2y ago
  [deleted]
• sensanaty 2y ago
  I'm just hoping 2025 will be the year of Vue or Svelte. Maddening that people are still picking React over much superior frameworks like those two
  • jpc0 2y ago
    What makes Vue or Svelte different? Is it more abstract? Is the state model simpler? I have my issues with react but I don't think a different framework necessarily solves those issues since those issues are explicitly with how you need to handle state changes in JS and how "components" tie into that. I haven't used it but something like Elixer Pheonix liveview[1] / .NET blazor[2] or skiplabs skip[3] or a well setup apollo client[4]. Nothing prevents you from building that abstraction on react, I don't know about Vue/Svelte. The idea is though that there are models which should come from your backend, viewmodels which should be in your frontend code. And there should be no other state. Whether a button is clicked or not has nothing to do with the backend. What the button does when it is clicked also has nothing to do with the backend. All that should theoretically happen when the button is clicked is you should decide what needs to happen. If a thingabob needs to be deleted from the viewmodel, no calls to.the backend. If that thingamabob is linked to the actual model then no frontend should change, the backend should change and a message that it has successded / failed should go to the frontend. It's when you bring optimistic updates and eventual consistency etc in, then your frontend code becomes absolutely chaotic. You make it a distributed computing problem but then instead of message passing and actors which is a known good way to handle distributed computing you try to synchronise state. 1. https://hexdocs.pm/phoenix/Mix.Tasks.Phx.Gen.Auth.html#module-liveview-vs-conventional-controllers-views https://hexdocs.pm/phoenix/Mix.Tasks.Phx.Gen.Auth.html#modul... 2. https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blazor https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz... 3. https://skiplabs.io/ https://skiplabs.io/ 4. https://www.apollographql.com/docs/react https://www.apollographql.com/docs/react
• tacker2000 2y ago
  Im using RTK Query with React with apps where i dont control the API and just consume the JSON. The problem with RTK Query is the strong reliance on the internal cache, which is often in the way, since i need the updated data from the server most of the time, but otherwise it works quite well. For apps where i control the backend (mostly PHP with Laravel or Symfony), im using Inertia now, which enables me to directly access the entity/model data in the React code, without any API necessary. This works really well and reduces the React code to the minumim, UI based stuff, where it shines. There is a Stimulus/Turbo plugin for Symfony as well, but Im not sure if this technology isnt too niche and unproven yet, in contrast with React, which has been around a long time, has tons of docs, and also loads of devs with experience on the market.
• martijn_himself 2y ago
  I don't know React very well but I used Angular in a large project and it was completely baffling to me how overly complex it was. In certain areas of the application it felt like it was completely unpredictable what value the state was going to be. I sometimes long for the simplicity of something like Windows Forms.
  • jeroenhd 2y ago
    I've spent my teenage years making Windows Forms applications, and the complete lack of state management isn't something I'd like to go back to. Sure, with the knowledge I have now I could set up a whole MVC model with event based updates to form state, but at some point you're just rewriting the complex libraries that you're trying to avoid. Good interactive state management, especially when you're tying to combine it with a stateless protocol like HTTP, is very difficult. Every complex library that's out there started off as a "simple way" of doing things. There's nothing stopping you from doing Windows Forms applications of course, and the modern evolution of ASP.NET does look pretty inviting if you're over all that frontend crap, but don't underestimate the problem libraries like Angular solve. Microsoft tried it with Blazor, and that'll quickly get you a website that's a hundred megabytes in size because it downloads all of .NET into your browser.
• staticelf 2y ago
  I think this varies wildly on the type of app you're building. If you are building something like CRUD interfaces obviously a server side focus is very viable and useful since you don't have to have double state management. I am thinking apps like ecommerce, banking or management software. But if you're building a very client heavy application that does something like Photo editing, CAD, video editing etc I have a hard time seeing a server side generated content to be successful because you need a lot of client side state no matter what. For example, I have done a lot with maps and it's not possible AFAIK to render the canvas on the server since it's a browser only api. Also I don't really see the benefit since it takes too much computational power to generate graphical things on the server.
  • megalord 2y ago
    I agree with this, it was always the case with everything in the real world as well. People use tools that can best handle the problem they have. However, I think most today's websites/apps do not require to be SPA oriented. If only the one page requires heavy client-side interaction, there's always possibility to use SPA library only on that one particular page
    • staticelf 2y ago
      I agree, most websites would benefit greatly from using something like Phoenix Liveview, Hotwire, Livewire etc. That way you get all the benefits of a SPA without having to deal with the extra complexity of double state management. I wish I was doing those kinds of apps because that tech seems wonderfully nice to work with. Unfortunately I do client heavy apps mostly so I don't have the benefit from using one. Offline support is... impossible to do good with those kinds of tools.
• austin-cheney 2y ago
  People in the comments talk all about their favorite pet tech stacks with only a single purpose: how long it takes them to write code. In front end logic that typically means putting text on screen or interactions. Years ago I decided to not worry about those concerns and it turns out those concerns are irrelevant. Writing content, really all front end logic, is as fast as you can type on a keyboard irrespective of your tech stack. Just about everything else is over engineered insanity. That was even true back in the IE7/8 days. It became apparent to me the only thing that mattered is time to refactor. The larger the application is the more true that becomes. The things that help with that the most are type annotations on everything, high execution performance, and fast test automation. Everything else became a distraction or noise that got in the way. The application does what it promises or its defective. It can be modified quickly or good ideas are abandoned for risks or costs. So I don’t worry about tech stacks and spend too much energy on execution speed.
• fredgrott 2y ago
  But, was it JS alone or the rendering of JS and CSS in the browser container??? For context, the Dart Flutter stack started out with the concept to make web apps faster....
• deleted 2y ago
  [deleted]
• scottydelta 2y ago
  On the contrary, I would say the end user's device has never been more powerful and it will continue to get better. In real world we are supposed to use that resource(client side compute/storage) to balance the server side and client side processing, not just for performance but for optimal user experience.
  • panstromek 2y ago
    This is not exactly true, or at least it's misleading. I recommend reading some Stuart Russel's articles on this or watching some of his talks. In summary, performance is getting better on the high end, but at the same time, large parts of the world are coming online with terrible devices, so median device is not very good. P75 device is totally removed from what web developers use to develop on. On top of that, there's still a big concern with battery life, spotty connection and apps competing over phone's resources. E.g. on Android, if your website is too heavy, the system will kill stuff running in the background. If your users watch youtube or listen to a podcast and your website make the audio glitch or kill running spotify, that's not a great experience. Last point is that react-like sites use the phone's resources in a really bad way - phones get more cores (especially e-cores) and special processing units (ai, video, graphics) but JS runs single threaded on the UI thread, competing with everything else, together with expensive JS engine machinery. If you ever profile some SPA on some representative android device, it's just all yellow, bottlenecked on JS.
• DrScientist 2y ago
  Full page navigation is the web's super power and what makes it scale. In my view one of the first things you should be doing when working on a web-app is to work out where you can place them, rather than trying to avoid.
• harel 2y ago
  If you don't over complicate it, React apps are very simple. Emphasis on the very. The opposite is also correct. If you DO over complicate it, React apps are extremely complicated. Also, the SPA model works great for some apps and badly for others. This blanket ruling of "do x and not y because x worked for us and y didn't" is just bad advice.
  • evantbyrne 2y ago
    Simplicity is relative. I wouldn't call having to reimplement basic browser features like forms simple compared to slapping Turbo on server-rendered HTML (which took me ~50 LOC last I did so on Pocket SQL).
    • harel 2y ago
      It is. And it's very much domain dependant. One of my projects is a CRM application, which is a SPA. Years ago, I had a similar incarnation of that projects as a "traditional" html+js model. It works much much better as an SPA on many levels. It's a complex app with a lot of UI elements. A simpler application might not benefit from being an SPA. So it all depends. I'm just allergic to that style of "X is dead to me so X must be dead to you".
      • evantbyrne 2y ago
        That's interesting because a CRM sounds like a strong use case for server-rendered HTML: Relatively low interactivity outside of form handling, which is consistently a weak point for SPAs. I wonder how different your experience would have been back then if you had modern browser APIs and something like Turbo, because the manner in which you go about the JS makes a huge difference. I would not advocate that people use HTMX for example, which strikes me as just being inline JS.
        • harel 2y ago
          An SPA is actually very suitable for this type of app. It was simple forms in the 00s, but it's not that anymore. First, in my case, the back end is an API (python). It is also serving mobile apps, and 3rd party integrations. Turbo is more suitable, if I'm not mistaken, for Javascript based applications. Second, my CRM is fast. The UI is snappy and there is little lag, which is something people comment on a lot. And third, there are many components there where a page reload will break things - for example, when you perform a telephone call from the browser. You can still navigate the data, without reloading the page and cutting the call. It's never simple, and NEVER EVER one size fits all. I'm saying this after about 30 years of doing this job commercially.
• tekkk 2y ago
  It's interesting to hear varying takes on this. But my personal belief is that web apps are moving towards static sites that are cache-friendly and offline-ready. This for couple of reasons, first is easy integration with CDN. Second is easy integration with webviews for mobile apps. And easiest way to implement offlineness so far has been through a state management library. Doesn't mean that doing what the article suggests, moving logic to server, is impossible but it's quite a pain. Much easier is to move logic to client and handling it there. Moreover, the fact there's so many UI components and libraries available for React and so forth, makes developing much faster. Depends on the developer, of course (and I personally prefer Svelte), but is a rather big advantage if you are doing anything complex in UI.
• ksec 2y ago
  Really hope there are more in Rails 8.1 and 9.0. More extracted tools, more defaults, higher performance. I mean we really should be aiming at p99 350ms.
• cloverich 2y ago
  Its somewhat amusing to me that in 2025, you can still find comments equating React to hype. I've been using React professionally for 10 years. Can we at least agree its not a new, hyped technology? IMHO there's exactly two factors when it comes to having success and efficiency with established tech like React or Rails. One is familiarity, the more experience you have, the more you know it, the more you like it, the better you are going to be with it. The other is restraint. The less custom EVERYTHING you make, the easier it will be to maintain and change. If you lack one or god forbid both, you are going to have a bad time. If you have both, probably anything that's not actually bleeding edge will work out well for you.
• the_arun 2y ago
  Where did we go wrong? May be we need something different from HTML. A new spec to render user experience. Possibly same spec for Browser & Native apps across all devices.
• literalat 2y ago
  I think you could achieve the same with Next.js's RSC (React Server Components).