9 ms·

As someone who lived through all major waves of JS for the last ~16 years, I do love react, in a sense: React is the worst JS framework except for all the othe

As someone who lived through all major waves of JS for the last ~16 years, I do love react, in a sense: React is the worst JS framework except for all the others we've tried. I'd take React over the Angular 1 days any time. I'd take Angular 1's full-bodied MVC over the "build it yourself from scratch every time" approach of Backbone. I'd take Backbone's minimal MVC structure over the classic JQuery Soup architecture. And I'd take JQuery's dom manipulations and standard-library improvements over the native apis (of that era) in an instant. React has its tradeoffs, but we got here after a long slog of other things that don't work.

kcrwfrd_ 4mo ago
As someone who went through that same journey, agreed. Compared to previous paradigms, React lets you compose complexity and rich interactivity really, really well. Even for all its flaws.
veryfancy 4mo ago
Chesterton’s framework.
skydhash 4mo ago
> React is the worst JS framework except for all the others we've tried. > React has its tradeoffs, but we got here after a long slog of other things that don't work. I strongly believe it's because of trying to achieve the wrong goal with the wrong tool. So many websites could just be bare html pages and forms with just a sprinkle of JS for some interactivity, but they want to add JS for whatever reason. If you can have a complete repo browser without JS (cgit), most web applications can survive without it too.
- fishtoaster 4mo ago
  Sounds like your argument is with SPAs, not React in particular?
  - lambdaone 4mo ago
    SPAs are a monster that grew and grew; an idea that at first seemed like a clever optimization has generated huge and complex systems that are a nightmare to work with, and are bloated, slow and insecure. Web components are the next big idea. I hope they have a chance to work.
    - onemoresoop 4mo ago
      I hate spas everywhere too but if you needed to build one for valid reasons React is probably a good bet due to large ecosystem and adoption. I personally avoided React as much as I could and luckily I won’t have to have to work with it.
    - buzzerbetrayed 4mo ago
      > Web components are the next big idea. I hope they have a chance to work. This comment could work equally well in any of the past 15 years. And for all we know, any of the next 15.
      - pjmlp 4mo ago
        Angular supports web components as first class, as do frameworks like Blazor. It is mostly the React crowd that dislikes them.
- hajile 4mo ago
  There are four culprits here and neither is due to JS. First is the pursuit of polish. Each extra 1% in polish adds tons and tons of lines of code. If you want that level of polish on a non-SPA, you'll still have to add all that code then reload it one page at a time. I see a lot of these "bare HTML pages" and they are lacking important stuff like i18n/a11y/WCAG compliance. Try adding all that back in and you'll see your website bloat right up. Second is bloated do-everything libraries. Ant, MUI, Mantine, or whatever else is aimed to be a superset of all possible website needs which means that the components you adopt have tons of features and bloat you don't need that slow down loading, parsing, and execution. Simply replacing that <Paper> component with a <div> and a few lines of CSS will get you the same thing you want, but will save you layers of unnecessary React components and sometimes a layer or two of unneeded DOM nodes as well that were added because the <Paper> component had weird interactions with some other component. Third is manpower/experience. Many/most JS devs today (sad to say) don't actually know how to make that simple <Paper> component on their own. Those that do often skip it because they've got too much to do already. I've lost count of the number of teams I've seen where a bog-standard backend has 25 people working on stuff while the frontend team has 3x as many total lines of code (which are often times handling human-computer interaction issues the backend couldn't even imagin), but only 3-4 people to maintain it all. Fourth is of course management. Designs on the backend change at a trickle while changes to the frontend arrive in a torrent. Understaffed frontend teams can't keep up with all the things shoved on their plate, so they usually can't optimize things even if they know how (eg, only a small percentage of SPA actually know/take the time to lazy load various parts of their apps to improve load time). Fix these things and the SPA performance will improve drastically and almost certainly exceed BE templates with some jQuery spaghetti.
  - bryanrasmussen 4mo ago
    >I see a lot of these "bare HTML pages" and they are lacking important stuff like i18n/a11y/WCAG compliance. Try adding all that back in and you'll see your website bloat right up. having lots of JavaScript tends to make more WCAG problems, because you do interactive stuff that needs to be described. Having bare HTML and the accessibility that is required for that is not tending to bloat in my experience.
- pjmlp 4mo ago
  Exactly, for most websites out there classical webserver rendering does the job pretty well. Even fancy animations can be taken care by pure CSS.
wg0 4mo ago
I was a big Sevelte fan. After writing a sizeable application in Sevelte I realized that React is superior in every way overall speaking and at least you're writing 100% pure JavaScript directly. Or Typescript. Plus the ecosystem. It's huge. Nothing comes closer.
- tcfhgj 4mo ago
  Could you expand on your experience compared to react?
  - wg0 4mo ago
    I had main issue with smaller ecosystem. Very limited components and everything else is geared towards React. Take React Query for example. If you want first class data caching and retry logic etc, then Svelte support was second class at least couple of years ago. Same goes for component libraries.
- gobdovan 4mo ago
  You might be interested in solid.js. To me, it's easier to work with than React. What I like about it is that the reactivity model is small enough that you can understand it, and even implement a basic version yourself. It also uses JSX, but since there's no virtual DOM, you can also write 100% JS, but, unlike React, you can do it without any special wrapper. So you don't need to use or write a `react-dnd`, just use any vanilla drag and drop library.
  - skew-aberration 4mo ago
    I've tried solid and it's much nicer on small projects. How well does it scale though? Modern React is also 'more functional' (for some definition) but it comes at a cost of cumbersome and leaky abstractions. Classic React walked a fine line of being 'just reactive enough'. You could make code declarative and composable while still micromanaging certain lifecycle and data dependency decisions that can be critical for performance.
    - 4mo ago
ricardonunez 4mo ago
I like react over angular and vue over react.
- synergy20 4mo ago
  same here thus I'm with vue
tcfhgj 4mo ago
What about Angular 2+?
- microflash 4mo ago
  Angular 2+ is equally horrible. Having spent 6 years on various versions of Angular, their migration story time and again has been an incredible pain. These days I use web components for component writing and frameworks to handle routing, state management, bundling, and so on.
  - tcfhgj 4mo ago
    can you compare it to other frameworks? I migrated from Angular 4 to 18 (including ngrx and material) and didn't find it especially problematic. Migrating mostly was little effort and consisted of automatic migration and walking through the provided checklist (mostly to ensure I didn't miss anything important), but I don't have any comparison in the JS SPA ecosystem.
    - microflash 4mo ago
      Vue 2 to Vue 3 has been equally painful for atleast one app I know about. Compare that to last three versions of Astro (with web components) and it has been a breeze. > I migrated from Angular 4 to 18 (including ngrx and material) and didn't find it especially problematic. The pain varies from project to project. Mine has been touched by a generation of developers of different levels of proficiency. A more disciplined project would’ve been easier to migrate in retrospective. I think Angular ecosystem really missed the train with schematics (even ngrx!). Schematics could tackle a lot of toil if implemented exhaustively but apart from Angular and Material, nobody else seems to implement them effectively for brownfield projects.
- jamesrr39 4mo ago
  I tried Angular 2+ back in the day. I found it frustrating to learn as the API had changed between versions, and when searching for help you would come across a blog post/stackoverflow answer, start implementing it and realise it didn't work in the version of Angular your project was in. Frustrating. Tried React afterwards, this frustration didn't really exist and it was much easier to pick up.
ndc 4mo ago
Wait, react is a framework now? People used to say that react is just a model binding library. FYI I haven't used react.
- fishtoaster 4mo ago
  "React is actually a library, not a framework" is definitely a thing people have said here and there since its inception. It's a distinction that doesn't seem to buy anything in terms of explanatory power or clarity, so I tend to ignore it.
  - vkou 4mo ago
    Generally the difference between a library and a framework is that you can use bits and pieces of a library to add functionality to your project. A framework expects most of your project to be shoehorned into it. Whether something is one or the other depends on which of the two most users are doing. It's not a very interesting argument, though, because debating semantics is the worst use of the limited time you have on this planet.
  - ndc 4mo ago
    I think it's a shortcut for saying that react doesn't have an 'official' routing library (like vue-router) and state management library (like vue's pinia). So depending on what you choose to manage routing / state, one react app can be quite different from another. Maybe nowadays there is a set of popular libraries for react so it becomes framework-y?
    - 9dev 4mo ago
      Vue-Router and Pinia have always been optional add-ons for Vue too, however, yet the Vue ecosystem seemed to to fine without those "aaakshually“ kinds of people that feel the need to micro-manage other people’s speech.
- paulddraper 4mo ago
  jQuery isn’t exactly a “framework” either, at least not like Angular or Vue, though it can be extended with “plugins.” Both jQuery and React are foundational technologies, and comparison is valid.
digitaltrees 4mo ago
But why over vue? My biggest frustration has been how vue ends up moving in the direction of react. The original component architecture with the html template, JavaScript state and css styles in vue was so nice. Even the data fetching a url in the component was so intuitive.
- synergy20 4mo ago
  I'm using Vue and do not feel it's becoming react
  - lwansbrough 4mo ago
    This sentiment only really applies if you’re coming from Vue 1/2 to Vue 3. The Composition API is definitely more like React but makes some better design decisions that make it easier to work with than React. Such as implicit reactivity.
    - 9dev 4mo ago
      If anything, composition API has taken the good parts from React. Once you get the hang of it, it’s amazing. Everything clicks together, is easily composable, and fully typed-safe.
      - sevenzero 4mo ago
        Yup I'd sign this. We use Vue2 in a old codebase with options API and composition API in new projects. Both feel way better than anything I ever had to do with React (how many Hooks do you have to learn by now? 13?) Vue just has a very simple lifecycle and combined with a simple store like Pinia it's just really fun to work with.
- hajile 4mo ago
  Vue doesn't solve problems better than React (and solves them worse if you have to learn all their proprietary files and DSLs instead of JSX), so there's not much of a reason to switch. The real discussion would be between React's vdom and something like Solid's signals.
shermantanktop 4mo ago
That’s right — the outcome is path-dependent. If we knew then what we know now, surely we’d have gotten over the idea that the web is DOM-documents-plus-REST-plus-JS-handlers-everywhere. A lot of people did and do like that idea — I like it too — but it’s woefully inadequate for making rich web apps that a team of average devs can handle.
queenkjuul 4mo ago
I never wanna use anything but Svelte ever again, honestly.
beering 4mo ago
Agreed. Like you, I went from hand-written cgi-bin html to jquery to angular v1 to React. I will willingly reach for React as a tool - it does what I want to do.
- stevepotter 4mo ago
  I remember in 1999 being so psyched about changing a button image on mouseover. Went hard on jquery, little bit of angular and bootstrap. React was big for me because it’s one way data binding solved the kinds of bugs I had spent years dealing with. Vue svelte and others are cool but they are all very similar to me. I always encourage people to work at first without any framework because then you gain an appreciation for why these things exist (or you stay vanilla and constantly blog about it)
dwd 4mo ago
React was a major improvement over Backbone + Marionette. Pre-jQuery was a shit-show as they hadn't even standardised the DOM. Before that was XMLHttpRequest (particularly during my .Net WebForm days) and even had to use the ActiveXObject in IE that predated JSON.
- biinjo 4mo ago
  Oh boy the ActiveXObject brings back some ~~ptsd~~ fond memories.
- SoftTalker 4mo ago
  XML, XMLHttpRequest, and XSLT in IE 5 was peak web dev for me. Never been more productive.
  - kibibu 4mo ago
    This feels like the equivalent of "whatever music you liked at 16 defines your taste"
    - SoftTalker 4mo ago
      I suppose. And I'm not at all saying there's nothing better today, or that it would be possible to build today's web apps using that stack. Just at that point in time and with those technologies everything was clicking.
  - dwd 4mo ago
    Back in the days when launching a website was an event, and sometimes included junket trips to attend.
- strictnein 4mo ago
  Give me Backbone + anything over React. Backbone was the last time I really felt close to the web page I was creating.
  - chipx86 4mo ago
pjmlp 4mo ago
We are very far away from Angular 1.0 days, and not every single website needs JavaScript.
- dev_l1x_be 4mo ago
  Exactly right. And this is why Astro works very well for me.
deleted 4mo ago
[deleted]
pointlessone 4mo ago
Where would you put custom elements in your list?
- wildrhythms 4mo ago
  Not comparable because custom elements don't handle rerenders elegantly without extra plumbing.
wink 4mo ago
I've never had the sort of problems I[0] had with React when using Angular (1 or 2), despite the apps having more complexity. Maybe that's just anecdata, but I hated them a lot less. (I am mostly a Backend dev who also does Frontend, so I don't love any of them.) [0]: and by that I mean my whole team at the appropriate time, it's not simply me misunderstanding things
victorbjorklund 4mo ago
Have you used Svelte? I can’t see why anyone would like React more. The only upside I think react has it’s the IBM of frontend. No one has been fired for choosing React.
- stevepotter 4mo ago
  Svelte is cool although I didn't have some big epiphany. I'm not going to use Svelte because "it compiles" and "is faster" when my existing React app performs very well. Plus there are some libraries for my specific use case that didn't exist in Svelte. I know people love things besides React, and I would be happy to see it unseated. Sure I'm part of the problem but it's been good to me and I have bigger fish to fry.
  - bryanhogan 4mo ago
    > Plus there are some libraries for my specific use case that didn't exist in Svelte. A lot of these libraries aren't needed in Svelte because 1) the functionality might already be built into Svelte, and 2) you can use any JavaScript library directly, unlike in React where you often need a React-specific wrapper. Not saying that applies to your specific use case, but I've seen this argument way too many times.
    - narvidas 4mo ago
      As someone who has written both React and Svelte for many years I must interject. React is itself just a library. No, you don’t need any specific “wrappers” for it. Let’s not mislead the readers here.
      - owebmaster 4mo ago
        A wrapper is a quite common pattern in react, even if it's just to create some hooks and call it react-anything
  - brikym 4mo ago
    Just use JS libraries. You don't need wrappers.
dmux 4mo ago
Curious to see where you'd place Knockout (still my favorite framework to date)
- hajile 4mo ago
  We'll set aside performance because that could be fixed with a renderer rewrite. The biggest issue when I worked with it was weaving a spiderweb of bindings that eventually trap you. At some point, you wind up spending most of your time fighting weird bugs that show up in places very far removed from the bindings that actually caused the bug.
- fishtoaster 4mo ago
  Unfortunately I never got around to trying it! I remember it being a contender around the time of Backbone, but then Ember and Angular were the main options thereafter.
incangold 4mo ago
I enjoy React and I’d take it over all of those other things. I wouldn’t take React over htmx/data-star and server rendering if that’s all I needed, and even if I had a couple of pages that needed a little bit more.

kcrwfrd_ 4mo ago

As someone who went through that same journey, agreed. Compared to previous paradigms, React lets you compose complexity and rich interactivity really, really well. Even for all its flaws.

veryfancy 4mo ago

Chesterton’s framework.

skydhash 4mo ago

> React is the worst JS framework except for all the others we've tried. > React has its tradeoffs, but we got here after a long slog of other things that don't work. I strongly believe it's because of trying to achieve the wrong goal with the wrong tool. So many websites could just be bare html pages and forms with just a sprinkle of JS for some interactivity, but they want to add JS for whatever reason. If you can have a complete repo browser without JS (cgit), most web applications can survive without it too.

fishtoaster 4mo ago
Sounds like your argument is with SPAs, not React in particular?
- lambdaone 4mo ago
  SPAs are a monster that grew and grew; an idea that at first seemed like a clever optimization has generated huge and complex systems that are a nightmare to work with, and are bloated, slow and insecure. Web components are the next big idea. I hope they have a chance to work.
  - onemoresoop 4mo ago
    I hate spas everywhere too but if you needed to build one for valid reasons React is probably a good bet due to large ecosystem and adoption. I personally avoided React as much as I could and luckily I won’t have to have to work with it.
  - buzzerbetrayed 4mo ago
    > Web components are the next big idea. I hope they have a chance to work. This comment could work equally well in any of the past 15 years. And for all we know, any of the next 15.
    - pjmlp 4mo ago
      Angular supports web components as first class, as do frameworks like Blazor. It is mostly the React crowd that dislikes them.
hajile 4mo ago
There are four culprits here and neither is due to JS. First is the pursuit of polish. Each extra 1% in polish adds tons and tons of lines of code. If you want that level of polish on a non-SPA, you'll still have to add all that code then reload it one page at a time. I see a lot of these "bare HTML pages" and they are lacking important stuff like i18n/a11y/WCAG compliance. Try adding all that back in and you'll see your website bloat right up. Second is bloated do-everything libraries. Ant, MUI, Mantine, or whatever else is aimed to be a superset of all possible website needs which means that the components you adopt have tons of features and bloat you don't need that slow down loading, parsing, and execution. Simply replacing that <Paper> component with a <div> and a few lines of CSS will get you the same thing you want, but will save you layers of unnecessary React components and sometimes a layer or two of unneeded DOM nodes as well that were added because the <Paper> component had weird interactions with some other component. Third is manpower/experience. Many/most JS devs today (sad to say) don't actually know how to make that simple <Paper> component on their own. Those that do often skip it because they've got too much to do already. I've lost count of the number of teams I've seen where a bog-standard backend has 25 people working on stuff while the frontend team has 3x as many total lines of code (which are often times handling human-computer interaction issues the backend couldn't even imagin), but only 3-4 people to maintain it all. Fourth is of course management. Designs on the backend change at a trickle while changes to the frontend arrive in a torrent. Understaffed frontend teams can't keep up with all the things shoved on their plate, so they usually can't optimize things even if they know how (eg, only a small percentage of SPA actually know/take the time to lazy load various parts of their apps to improve load time). Fix these things and the SPA performance will improve drastically and almost certainly exceed BE templates with some jQuery spaghetti.
- bryanrasmussen 4mo ago
  >I see a lot of these "bare HTML pages" and they are lacking important stuff like i18n/a11y/WCAG compliance. Try adding all that back in and you'll see your website bloat right up. having lots of JavaScript tends to make more WCAG problems, because you do interactive stuff that needs to be described. Having bare HTML and the accessibility that is required for that is not tending to bloat in my experience.
pjmlp 4mo ago
Exactly, for most websites out there classical webserver rendering does the job pretty well. Even fancy animations can be taken care by pure CSS.

wg0 4mo ago

I was a big Sevelte fan. After writing a sizeable application in Sevelte I realized that React is superior in every way overall speaking and at least you're writing 100% pure JavaScript directly. Or Typescript. Plus the ecosystem. It's huge. Nothing comes closer.

tcfhgj 4mo ago
Could you expand on your experience compared to react?
- wg0 4mo ago
  I had main issue with smaller ecosystem. Very limited components and everything else is geared towards React. Take React Query for example. If you want first class data caching and retry logic etc, then Svelte support was second class at least couple of years ago. Same goes for component libraries.
gobdovan 4mo ago
You might be interested in solid.js. To me, it's easier to work with than React. What I like about it is that the reactivity model is small enough that you can understand it, and even implement a basic version yourself. It also uses JSX, but since there's no virtual DOM, you can also write 100% JS, but, unlike React, you can do it without any special wrapper. So you don't need to use or write a `react-dnd`, just use any vanilla drag and drop library.
- skew-aberration 4mo ago
  I've tried solid and it's much nicer on small projects. How well does it scale though? Modern React is also 'more functional' (for some definition) but it comes at a cost of cumbersome and leaky abstractions. Classic React walked a fine line of being 'just reactive enough'. You could make code declarative and composable while still micromanaging certain lifecycle and data dependency decisions that can be critical for performance.
  - 4mo ago

ricardonunez 4mo ago

I like react over angular and vue over react.

synergy20 4mo ago
same here thus I'm with vue

tcfhgj 4mo ago

What about Angular 2+?

microflash 4mo ago
Angular 2+ is equally horrible. Having spent 6 years on various versions of Angular, their migration story time and again has been an incredible pain. These days I use web components for component writing and frameworks to handle routing, state management, bundling, and so on.
- tcfhgj 4mo ago
  can you compare it to other frameworks? I migrated from Angular 4 to 18 (including ngrx and material) and didn't find it especially problematic. Migrating mostly was little effort and consisted of automatic migration and walking through the provided checklist (mostly to ensure I didn't miss anything important), but I don't have any comparison in the JS SPA ecosystem.
  - microflash 4mo ago
    Vue 2 to Vue 3 has been equally painful for atleast one app I know about. Compare that to last three versions of Astro (with web components) and it has been a breeze. > I migrated from Angular 4 to 18 (including ngrx and material) and didn't find it especially problematic. The pain varies from project to project. Mine has been touched by a generation of developers of different levels of proficiency. A more disciplined project would’ve been easier to migrate in retrospective. I think Angular ecosystem really missed the train with schematics (even ngrx!). Schematics could tackle a lot of toil if implemented exhaustively but apart from Angular and Material, nobody else seems to implement them effectively for brownfield projects.
jamesrr39 4mo ago
I tried Angular 2+ back in the day. I found it frustrating to learn as the API had changed between versions, and when searching for help you would come across a blog post/stackoverflow answer, start implementing it and realise it didn't work in the version of Angular your project was in. Frustrating. Tried React afterwards, this frustration didn't really exist and it was much easier to pick up.

ndc 4mo ago

Wait, react is a framework now? People used to say that react is just a model binding library. FYI I haven't used react.

fishtoaster 4mo ago
"React is actually a library, not a framework" is definitely a thing people have said here and there since its inception. It's a distinction that doesn't seem to buy anything in terms of explanatory power or clarity, so I tend to ignore it.
- vkou 4mo ago
  Generally the difference between a library and a framework is that you can use bits and pieces of a library to add functionality to your project. A framework expects most of your project to be shoehorned into it. Whether something is one or the other depends on which of the two most users are doing. It's not a very interesting argument, though, because debating semantics is the worst use of the limited time you have on this planet.
- ndc 4mo ago
  I think it's a shortcut for saying that react doesn't have an 'official' routing library (like vue-router) and state management library (like vue's pinia). So depending on what you choose to manage routing / state, one react app can be quite different from another. Maybe nowadays there is a set of popular libraries for react so it becomes framework-y?
  - 9dev 4mo ago
    Vue-Router and Pinia have always been optional add-ons for Vue too, however, yet the Vue ecosystem seemed to to fine without those "aaakshually“ kinds of people that feel the need to micro-manage other people’s speech.
paulddraper 4mo ago
jQuery isn’t exactly a “framework” either, at least not like Angular or Vue, though it can be extended with “plugins.” Both jQuery and React are foundational technologies, and comparison is valid.

digitaltrees 4mo ago

But why over vue? My biggest frustration has been how vue ends up moving in the direction of react. The original component architecture with the html template, JavaScript state and css styles in vue was so nice. Even the data fetching a url in the component was so intuitive.

synergy20 4mo ago
I'm using Vue and do not feel it's becoming react
- lwansbrough 4mo ago
  This sentiment only really applies if you’re coming from Vue 1/2 to Vue 3. The Composition API is definitely more like React but makes some better design decisions that make it easier to work with than React. Such as implicit reactivity.
  - 9dev 4mo ago
    If anything, composition API has taken the good parts from React. Once you get the hang of it, it’s amazing. Everything clicks together, is easily composable, and fully typed-safe.
    - sevenzero 4mo ago
      Yup I'd sign this. We use Vue2 in a old codebase with options API and composition API in new projects. Both feel way better than anything I ever had to do with React (how many Hooks do you have to learn by now? 13?) Vue just has a very simple lifecycle and combined with a simple store like Pinia it's just really fun to work with.
hajile 4mo ago
Vue doesn't solve problems better than React (and solves them worse if you have to learn all their proprietary files and DSLs instead of JSX), so there's not much of a reason to switch. The real discussion would be between React's vdom and something like Solid's signals.

shermantanktop 4mo ago

That’s right — the outcome is path-dependent. If we knew then what we know now, surely we’d have gotten over the idea that the web is DOM-documents-plus-REST-plus-JS-handlers-everywhere. A lot of people did and do like that idea — I like it too — but it’s woefully inadequate for making rich web apps that a team of average devs can handle.

queenkjuul 4mo ago

I never wanna use anything but Svelte ever again, honestly.

beering 4mo ago

Agreed. Like you, I went from hand-written cgi-bin html to jquery to angular v1 to React. I will willingly reach for React as a tool - it does what I want to do.

stevepotter 4mo ago
I remember in 1999 being so psyched about changing a button image on mouseover. Went hard on jquery, little bit of angular and bootstrap. React was big for me because it’s one way data binding solved the kinds of bugs I had spent years dealing with. Vue svelte and others are cool but they are all very similar to me. I always encourage people to work at first without any framework because then you gain an appreciation for why these things exist (or you stay vanilla and constantly blog about it)

dwd 4mo ago

React was a major improvement over Backbone + Marionette. Pre-jQuery was a shit-show as they hadn't even standardised the DOM. Before that was XMLHttpRequest (particularly during my .Net WebForm days) and even had to use the ActiveXObject in IE that predated JSON.

biinjo 4mo ago
Oh boy the ActiveXObject brings back some ~~ptsd~~ fond memories.
SoftTalker 4mo ago
XML, XMLHttpRequest, and XSLT in IE 5 was peak web dev for me. Never been more productive.
- kibibu 4mo ago
  This feels like the equivalent of "whatever music you liked at 16 defines your taste"
  - SoftTalker 4mo ago
    I suppose. And I'm not at all saying there's nothing better today, or that it would be possible to build today's web apps using that stack. Just at that point in time and with those technologies everything was clicking.
- dwd 4mo ago
  Back in the days when launching a website was an event, and sometimes included junket trips to attend.
strictnein 4mo ago
Give me Backbone + anything over React. Backbone was the last time I really felt close to the web page I was creating.
- chipx86 4mo ago

pjmlp 4mo ago

We are very far away from Angular 1.0 days, and not every single website needs JavaScript.

dev_l1x_be 4mo ago
Exactly right. And this is why Astro works very well for me.

deleted 4mo ago

[deleted]

pointlessone 4mo ago

Where would you put custom elements in your list?

wildrhythms 4mo ago
Not comparable because custom elements don't handle rerenders elegantly without extra plumbing.

wink 4mo ago

I've never had the sort of problems I[0] had with React when using Angular (1 or 2), despite the apps having more complexity. Maybe that's just anecdata, but I hated them a lot less. (I am mostly a Backend dev who also does Frontend, so I don't love any of them.) [0]: and by that I mean my whole team at the appropriate time, it's not simply me misunderstanding things

victorbjorklund 4mo ago

Have you used Svelte? I can’t see why anyone would like React more. The only upside I think react has it’s the IBM of frontend. No one has been fired for choosing React.

stevepotter 4mo ago
Svelte is cool although I didn't have some big epiphany. I'm not going to use Svelte because "it compiles" and "is faster" when my existing React app performs very well. Plus there are some libraries for my specific use case that didn't exist in Svelte. I know people love things besides React, and I would be happy to see it unseated. Sure I'm part of the problem but it's been good to me and I have bigger fish to fry.
- bryanhogan 4mo ago
  > Plus there are some libraries for my specific use case that didn't exist in Svelte. A lot of these libraries aren't needed in Svelte because 1) the functionality might already be built into Svelte, and 2) you can use any JavaScript library directly, unlike in React where you often need a React-specific wrapper. Not saying that applies to your specific use case, but I've seen this argument way too many times.
  - narvidas 4mo ago
    As someone who has written both React and Svelte for many years I must interject. React is itself just a library. No, you don’t need any specific “wrappers” for it. Let’s not mislead the readers here.
    - owebmaster 4mo ago
      A wrapper is a quite common pattern in react, even if it's just to create some hooks and call it react-anything
- brikym 4mo ago
  Just use JS libraries. You don't need wrappers.

dmux 4mo ago

Curious to see where you'd place Knockout (still my favorite framework to date)

hajile 4mo ago
We'll set aside performance because that could be fixed with a renderer rewrite. The biggest issue when I worked with it was weaving a spiderweb of bindings that eventually trap you. At some point, you wind up spending most of your time fighting weird bugs that show up in places very far removed from the bindings that actually caused the bug.
fishtoaster 4mo ago
Unfortunately I never got around to trying it! I remember it being a contender around the time of Backbone, but then Ember and Angular were the main options thereafter.

incangold 4mo ago

I enjoy React and I’d take it over all of those other things. I wouldn’t take React over htmx/data-star and server rendering if that’s all I needed, and even if I had a couple of pages that needed a little bit more.