6 ms·

In general I really like React but after spending years tinkering with JS and seeing my codebases rot away faster than I could keep up due to ecosystem/tooling

In general I really like React but after spending years tinkering with JS and seeing my codebases rot away faster than I could keep up due to ecosystem/tooling churn (I started in 2014 when React was ES5 and still using mixins), I started replacing my frontends with regular server-side rendered ones. I enrich these with vanilla JS and some smart things like using async fetch and the history API to seamlessly replace content when clicking links. There are of course solutions like HTMX or Turbolinks that do similar things but it's really easy to make something simple work with just JS. With some of these tricks the resulting application feels very similar to a real SPA. Of course if you're really building an application in the sense that a lot of the computation and state handling happens in the browser you will still need to use JS, but even then I would just go with vanilla JS in most cases. That said my experience is from building mostly CRUD-like apps alone or in small teams, so I can see the benefit of more complex toolchains in larger organizations. But yeah, browsers and JS offer so much out of the box, most people don't seem to realize how easy it is to do cool things without relying on frameworks.

0xblinq 3y ago
I’m using this approach for a side project and it works great. Just traditional express, tagged template literals (with some xss escaping helpers) and stimulus + turbo. Using vite for bundling and reloading on changes.
- unsupp0rted 3y ago
  I used to do this too. Express + PUG templating. Maybe a little <script> injected VUE on the front end for some light client side stuff.
nymanjon 3y ago
Yeah, for my personal apps I just write offline-first apps. I need to make it so I can build apps as efficient as I can as I don't have a lot of free time. So, I wrote a little library under 1kB that just finds where I left off and re-centers/focuses there. It makes for dead simple applications.[^1] I also created an HTMX-like library that is focused on forms so it stays to the HTML speck pretty closely. I need to make a couple of corrections to it. But it is amazing how far it can get you and much smaller footprint than HTMX. Granted, it can only do a fraction of what HTMX can do.[^2] For anything stateful I just use web components. [^1]: https://github.com/jon49/mpa-enhancer https://github.com/jon49/mpa-enhancer [^2]: https://github.com/jon49/htmf https://github.com/jon49/htmf
verelo 3y ago
Ok so this is topical for me right now. I somehow managed to avoid the world of react since it became a thing. All the code i was writing was pre react and we kept the old frameworks, and that’s was all good and well. Fast forward to today, i took over a project that is full react. What a mental shift. Having said that, sometimes i love it, sometimes i hate it. A friend put it best when he said “i struggle to predict what might be trivial and what will take a full day or two”, and that’s my experience too. I found myself just the other day wishing i could await the setting of a state variable, it was making saving a file in a complicated form a little difficult. I found a work around but i don’t love it and i know the next time i come back to work on it I’ll be scratching my head at what i was trying to achieve and why i did it this way. Naturally i over commented my rational here. I do miss writing in basic js and server side code, it’s probably slower over all, but i do miss it for the simple things being predictably simply and the hard things typically being predictably hard.
- no_wizard 3y ago
  I realize this is unsolicited advice, however this sounds like you're hitting the "DOM has an imperative API but React is declarative" barrier, because React (until `use` ships at least) has no way to just await reactive values, you can: if sufficiently complex, you may want to look into `useSyncExternalStore`[0] which can be used to store and update state (IE maintaining UI reactivity) in a microcosm. Otherwise, I'd recommend framing it as a series of dispatch-able steps, which maps well to `useReducer`[1] possibly in combination with `useEffect` [0]: https://react.dev/reference/react/useSyncExternalStore https://react.dev/reference/react/useSyncExternalStore [1]: https://react.dev/reference/react/useReducer https://react.dev/reference/react/useReducer
- gabereiser 3y ago
  You don't need any of it. You can write vanilla JS, using ES6 classes, as web components and be done with the whole front-end framework game. All you need for data-binding is an Observable of some kind that can loop through listeners for events and call their handler. Component classes all have a render function so that React kids feel at home. Those components are registered using CustomElementRegistry.define [1]. Tools like vite help roll up all that code and styles into a minified bundle but doesn't include all the crap that these "modern" frameworks add. Take this from someone who has been writing web sites since 1996. You don't need any of those frameworks unless you're looking to give away control of your product to the roadmap of the framework or need to hire a bunch of people to accomplish something quickly and all they know is React. [1] https://developer.mozilla.org/en-US/docs/Web/API/CustomElementRegistry/define https://developer.mozilla.org/en-US/docs/Web/API/CustomEleme...
bravura 3y ago
Can you talk more about more of the tricks you use, with server side rendering and light JS? What about things like real-time (pushed preferably) updates based upon db changes, or another API finally sending streaming results, etc
- 0xblinq 3y ago
  Polling is fine for 99% use cases. Even Amazon does this.
- the_gastropod 3y ago
  Tools like HTMx [1] and Turbo [2] have pretty elegant and simple solutions to deal with Websockets. [1] https://htmx.org/extensions/web-sockets/ https://htmx.org/extensions/web-sockets/ [2] https://turbo.hotwired.dev/handbook/streams https://turbo.hotwired.dev/handbook/streams
jmondi 3y ago
What language and/or framework doesnt have this problem? - Ruby - if your Ruby/Rails app falls behind, you will be paying back debt to get it up to date - PHP - if your Laravel/CI/Cake/Slim/Symphony App falls behind, you will be paying back debt to get it up to date - Go - if your Go app falls behind, you will be paying back dept to get it up to date - Python - if your Django app falls behind, you will be paying back debt to get it up to date - Elixir - if your Phoenix app falls behind, you will be paying back debt to get it up to date
- icedchai 3y ago
  I have 10+ year old sites on PHP 5 and Laravel 4.x that the client doesn't want to pay to upgrade.
- 2023throwawayy 3y ago
  I have CakePHP code bases that are over a decade old and still run fine. Go is backwards compatible.
  - potta_coffee 3y ago
    I have years-old Go code that just keeps running. PHP is very stable. I've found Python to be a PITA sometimes. Javascript rots faster than anything else I've encountered.
- the_gastropod 3y ago
  Of course any system will require maintenance. The question is more about the significance and frequency of the maintenance required. You can take a Ruby on Rails app from 2005, and it will mostly look the same as a 2023 Rails app. You'll need to update some gems, use the newer routing DSL, and update the environment configs. But that's pretty much it, after nearly 2 decades. Contrast that to a React app written 5 years ago, where you'd pretty much need to completely rewrite everything (class components => functional, use hooks instead of callback methods, etc.)
  - jmondi 3y ago
d0100 3y ago
This sentiment makes sense up to the point where you are being glared at by a sweaty PM that can't understand why your foo widget can't be moved to the other side while blinking and ajaxing because HTMX doesn't work like that
- kerkeslager 3y ago
  Uh... what? You can totally do that easily. Not that you should, but this isn't harder to do in HTMX.

0xblinq 3y ago

I’m using this approach for a side project and it works great. Just traditional express, tagged template literals (with some xss escaping helpers) and stimulus + turbo. Using vite for bundling and reloading on changes.

unsupp0rted 3y ago
I used to do this too. Express + PUG templating. Maybe a little <script> injected VUE on the front end for some light client side stuff.

nymanjon 3y ago

Yeah, for my personal apps I just write offline-first apps. I need to make it so I can build apps as efficient as I can as I don't have a lot of free time. So, I wrote a little library under 1kB that just finds where I left off and re-centers/focuses there. It makes for dead simple applications.[^1] I also created an HTMX-like library that is focused on forms so it stays to the HTML speck pretty closely. I need to make a couple of corrections to it. But it is amazing how far it can get you and much smaller footprint than HTMX. Granted, it can only do a fraction of what HTMX can do.[^2] For anything stateful I just use web components. [^1]: https://github.com/jon49/mpa-enhancer https://github.com/jon49/mpa-enhancer [^2]: https://github.com/jon49/htmf https://github.com/jon49/htmf

verelo 3y ago

Ok so this is topical for me right now. I somehow managed to avoid the world of react since it became a thing. All the code i was writing was pre react and we kept the old frameworks, and that’s was all good and well. Fast forward to today, i took over a project that is full react. What a mental shift. Having said that, sometimes i love it, sometimes i hate it. A friend put it best when he said “i struggle to predict what might be trivial and what will take a full day or two”, and that’s my experience too. I found myself just the other day wishing i could await the setting of a state variable, it was making saving a file in a complicated form a little difficult. I found a work around but i don’t love it and i know the next time i come back to work on it I’ll be scratching my head at what i was trying to achieve and why i did it this way. Naturally i over commented my rational here. I do miss writing in basic js and server side code, it’s probably slower over all, but i do miss it for the simple things being predictably simply and the hard things typically being predictably hard.

no_wizard 3y ago
I realize this is unsolicited advice, however this sounds like you're hitting the "DOM has an imperative API but React is declarative" barrier, because React (until `use` ships at least) has no way to just await reactive values, you can: if sufficiently complex, you may want to look into `useSyncExternalStore`[0] which can be used to store and update state (IE maintaining UI reactivity) in a microcosm. Otherwise, I'd recommend framing it as a series of dispatch-able steps, which maps well to `useReducer`[1] possibly in combination with `useEffect` [0]: https://react.dev/reference/react/useSyncExternalStore https://react.dev/reference/react/useSyncExternalStore [1]: https://react.dev/reference/react/useReducer https://react.dev/reference/react/useReducer
gabereiser 3y ago
You don't need any of it. You can write vanilla JS, using ES6 classes, as web components and be done with the whole front-end framework game. All you need for data-binding is an Observable of some kind that can loop through listeners for events and call their handler. Component classes all have a render function so that React kids feel at home. Those components are registered using CustomElementRegistry.define [1]. Tools like vite help roll up all that code and styles into a minified bundle but doesn't include all the crap that these "modern" frameworks add. Take this from someone who has been writing web sites since 1996. You don't need any of those frameworks unless you're looking to give away control of your product to the roadmap of the framework or need to hire a bunch of people to accomplish something quickly and all they know is React. [1] https://developer.mozilla.org/en-US/docs/Web/API/CustomElementRegistry/define https://developer.mozilla.org/en-US/docs/Web/API/CustomEleme...

bravura 3y ago

Can you talk more about more of the tricks you use, with server side rendering and light JS? What about things like real-time (pushed preferably) updates based upon db changes, or another API finally sending streaming results, etc

0xblinq 3y ago
Polling is fine for 99% use cases. Even Amazon does this.
the_gastropod 3y ago
Tools like HTMx [1] and Turbo [2] have pretty elegant and simple solutions to deal with Websockets. [1] https://htmx.org/extensions/web-sockets/ https://htmx.org/extensions/web-sockets/ [2] https://turbo.hotwired.dev/handbook/streams https://turbo.hotwired.dev/handbook/streams

jmondi 3y ago

What language and/or framework doesnt have this problem? - Ruby - if your Ruby/Rails app falls behind, you will be paying back debt to get it up to date - PHP - if your Laravel/CI/Cake/Slim/Symphony App falls behind, you will be paying back debt to get it up to date - Go - if your Go app falls behind, you will be paying back dept to get it up to date - Python - if your Django app falls behind, you will be paying back debt to get it up to date - Elixir - if your Phoenix app falls behind, you will be paying back debt to get it up to date

icedchai 3y ago
I have 10+ year old sites on PHP 5 and Laravel 4.x that the client doesn't want to pay to upgrade.
2023throwawayy 3y ago
I have CakePHP code bases that are over a decade old and still run fine. Go is backwards compatible.
- potta_coffee 3y ago
  I have years-old Go code that just keeps running. PHP is very stable. I've found Python to be a PITA sometimes. Javascript rots faster than anything else I've encountered.
the_gastropod 3y ago
Of course any system will require maintenance. The question is more about the significance and frequency of the maintenance required. You can take a Ruby on Rails app from 2005, and it will mostly look the same as a 2023 Rails app. You'll need to update some gems, use the newer routing DSL, and update the environment configs. But that's pretty much it, after nearly 2 decades. Contrast that to a React app written 5 years ago, where you'd pretty much need to completely rewrite everything (class components => functional, use hooks instead of callback methods, etc.)
- jmondi 3y ago

d0100 3y ago

This sentiment makes sense up to the point where you are being glared at by a sweaty PM that can't understand why your foo widget can't be moved to the other side while blinking and ajaxing because HTMX doesn't work like that

kerkeslager 3y ago
Uh... what? You can totally do that easily. Not that you should, but this isn't harder to do in HTMX.