4 ms·

Honest question though, what abstraction do you use in place of React? I don't disagree that it's pretty obtuse, despite loving working in it. I miss being ab

by diob 6y ago

Honest question though, what abstraction do you use in place of React? I don't disagree that it's pretty obtuse, despite loving working in it. I miss being able to look up the source of Backbone.js and gain a real understanding of why something was happening. Maybe I'll get to that point in React, but it seems much harder to grasp what the source is doing.

axelf4 6y ago
I consider part of the blame to lie with React. The React source code structure is pretty obtuse. Compare that to the Inferno.js source code which is easy to understand and navigate for anyone familiar with how a VDOM library should work.
- jokethrowaway 6y ago
  this, I understood how react is supposed to be used by reading the preact codebase
xyzzy_plugh 6y ago
I just write JavaScript? The concepts of Basecamp's Hotwire[0] are particularly simple and elegant enough for the 1% of stuff that isn't just a static page or can't be solved in a single JS function. I've never been like "boy I really need a virtual DOM" so I guess I've never really seen the appeal of React. It just seems like a bundle of complexity, obfuscation and anti-patterns. 0: https://hotwire.dev https://hotwire.dev
- amenod 6y ago
  While you don't _need_ React (or a similar powerful library / framework), it takes one's productivity to a whole different level. I have a feeling that you have already made up your mind not to like it, but if you ever give it a fair try, you might find it useful for some projects. It is very complex under the hood, of course, so if you want to have total control you might need to dig into the internals. But to a casual user it gives a very nice abstraction, very powerful, easy to use (granted - and abuse) and performant. The thing that sold it for me is the declarative programming. You have state, state translates to rendering... and that's pretty much it. Compared to thinking about transitions in native JS (or jQuery or whatever) it is like night and day in any non-trivial project.
  - xyzzy_plugh 6y ago
    I've tried it. And yes, I want full control. The abstractions mostly work, but when they don't -- there you are again, thinking about transitions in native JS again. What was the point?
    - amenod 6y ago
      Well, newsflash: you are always dealing with abstractions, no matter which layer you pick. You might just as well pick one that lets you develop more complex things faster and more reliably. That said, if you are set on actively fighting it (not installing react dev tools, being frustrated by not having visibility under the hood) then it's probably best to stay away from React. I have quite a lot of history with native JS, but was happy to relinquish control to webpack/babel/react... not at first (had the same reaction as you do), but once I gave it a fair chance I discovered that things just work. Never had any problem with React not performing the way it should.
- qudat 6y ago
  > I just write JavaScript? This is the tell. If you are able to satisfy your business requirements with "just JavaScript" then you are in a completely different world than the people building production-grade web apps and there's absolutely nothing wrong with that. If you can be productive with "just JavaScript" then that's awesome! However, I'm sure you understand there's a massive difference between simple pages that need *some* interactivity and a full-blown app inside a web browser. I'm sure you've come across projects that probably didn't need the same tooling that I'm describing which ultimately boils down to a judgement call. > I've never been like "boy I really need a virtual DOM" so I guess I've never really seen the appeal of React. It just seems like a bundle of complexity, obfuscation and anti-patterns. That's because you've never needed it before. I've never been like "boy I really need a batteries-included web framework" so I guess I've never really seen the appeal of Rails. It just seems like a bundle of complexity, obfuscation and anti-patterns.
  - gmfawcett 6y ago
    > ...than the people building production-grade web apps... Please don't co-opt the word "production" to mean what you're implying here. Production doesn't mean single-page, reactive, etc. applications, it just means "in production."
    - bobthebuilders 6y ago
      Words are given a meaning by society.
      - gmfawcett 6y ago
        Obviously? And a society needs to correct misuses if it wants its words to keep meaning things.
        bobthebuilders 6y ago
        Literally?
    - 6y ago
vaughan 6y ago
I miss Backbone too. You could just step through the code in the debugger and it was so compact. With React you can’t really do that. It’s always following an error message saying: “look near this component” which is often deep in the hierarchy of some third party package’s component hierarchy that is transpiled into a single line with no source maps. I think there is a huge benefit in making things easy to step-through in a debugger when something goes wrong.
- arcanon 6y ago
  That’s because Jeremy Ashkenas is a beast. Coffeescript started modern JavaScript.

by diob 6y ago

axelf4 6y ago

I consider part of the blame to lie with React. The React source code structure is pretty obtuse. Compare that to the Inferno.js source code which is easy to understand and navigate for anyone familiar with how a VDOM library should work.

jokethrowaway 6y ago
this, I understood how react is supposed to be used by reading the preact codebase

xyzzy_plugh 6y ago

I just write JavaScript? The concepts of Basecamp's Hotwire[0] are particularly simple and elegant enough for the 1% of stuff that isn't just a static page or can't be solved in a single JS function. I've never been like "boy I really need a virtual DOM" so I guess I've never really seen the appeal of React. It just seems like a bundle of complexity, obfuscation and anti-patterns. 0: https://hotwire.dev https://hotwire.dev

amenod 6y ago
While you don't _need_ React (or a similar powerful library / framework), it takes one's productivity to a whole different level. I have a feeling that you have already made up your mind not to like it, but if you ever give it a fair try, you might find it useful for some projects. It is very complex under the hood, of course, so if you want to have total control you might need to dig into the internals. But to a casual user it gives a very nice abstraction, very powerful, easy to use (granted - and abuse) and performant. The thing that sold it for me is the declarative programming. You have state, state translates to rendering... and that's pretty much it. Compared to thinking about transitions in native JS (or jQuery or whatever) it is like night and day in any non-trivial project.
- xyzzy_plugh 6y ago
  I've tried it. And yes, I want full control. The abstractions mostly work, but when they don't -- there you are again, thinking about transitions in native JS again. What was the point?
  - amenod 6y ago
    Well, newsflash: you are always dealing with abstractions, no matter which layer you pick. You might just as well pick one that lets you develop more complex things faster and more reliably. That said, if you are set on actively fighting it (not installing react dev tools, being frustrated by not having visibility under the hood) then it's probably best to stay away from React. I have quite a lot of history with native JS, but was happy to relinquish control to webpack/babel/react... not at first (had the same reaction as you do), but once I gave it a fair chance I discovered that things just work. Never had any problem with React not performing the way it should.
qudat 6y ago
> I just write JavaScript? This is the tell. If you are able to satisfy your business requirements with "just JavaScript" then you are in a completely different world than the people building production-grade web apps and there's absolutely nothing wrong with that. If you can be productive with "just JavaScript" then that's awesome! However, I'm sure you understand there's a massive difference between simple pages that need *some* interactivity and a full-blown app inside a web browser. I'm sure you've come across projects that probably didn't need the same tooling that I'm describing which ultimately boils down to a judgement call. > I've never been like "boy I really need a virtual DOM" so I guess I've never really seen the appeal of React. It just seems like a bundle of complexity, obfuscation and anti-patterns. That's because you've never needed it before. I've never been like "boy I really need a batteries-included web framework" so I guess I've never really seen the appeal of Rails. It just seems like a bundle of complexity, obfuscation and anti-patterns.
- gmfawcett 6y ago
  > ...than the people building production-grade web apps... Please don't co-opt the word "production" to mean what you're implying here. Production doesn't mean single-page, reactive, etc. applications, it just means "in production."
  - bobthebuilders 6y ago
    Words are given a meaning by society.
    - gmfawcett 6y ago
      Obviously? And a society needs to correct misuses if it wants its words to keep meaning things.
      - bobthebuilders 6y ago
        Literally?
  - 6y ago

vaughan 6y ago

I miss Backbone too. You could just step through the code in the debugger and it was so compact. With React you can’t really do that. It’s always following an error message saying: “look near this component” which is often deep in the hierarchy of some third party package’s component hierarchy that is transpiled into a single line with no source maps. I think there is a huge benefit in making things easy to step-through in a debugger when something goes wrong.

arcanon 6y ago
That’s because Jeremy Ashkenas is a beast. Coffeescript started modern JavaScript.