4 ms·

These are all very, very weird points to raise, except maybe the SSR which is inherently hard to do.

by efdee 6y ago

irrational 6y ago
Not if you've been doing web development for a few decades, which I feel the author probably has. I feel like people who came into web development during the past decade really don't understand how much simpler and easier things used to be. It really feels like web development has become crazy complex without much added benefit.
- gherkinnn 6y ago
  I will never ever go back to the jQuery or vanilla js days. It might have been simpler (what ever that means) but the result was a nightmare to maintain and add to.
  - runawaybottle 6y ago
    I’m prepared to go back as the developer I am today versus the developer I was before. It’s almost like just when we’re ready to write some dope Jquery code, it’s time to go write in a new framework. I can say for certain the best React code we will all write will be 5 years from now, but, it’ll be time to move on to the next one.
- lumens 6y ago
  You know it's real when it hits you in the feels.
- baddox 6y ago
  It’s not more difficult now to make dynamic server-rendered web sites than it was 10 or 20 years ago (I don’t know about PHP these days, but it’s never been easier to start a new Django or Rails app), but your clients will probably want features they’re accustomed to in modern web applications that are not easily implemented in server-rendered web sites.
  - grey-area 6y ago
    What kind of features require you to use react?
    - baddox 6y ago
      None require React specifically, of course. I’m only referring to the dichotomy between server-rendered apps and apps with significant client-side interactivity.
      - grey-area 6y ago
        I sincerely think that dichotomy is not a useful one - that's not a choice you have to make. You can have server-rendered apps with significant interactivity (where it makes sense). Many large websites still use server side rendering (in whatever language they want), and js to refresh data client-side as required and respond to user actions, pulling data from the server side. There is no need to attempt to move everything to client-side, it doesn't make the UX better IMO, sometimes it makes it worse. Keeping most logic and templates server-side works just fine on large complex sites serving millions of people, and it's significantly simpler and more stable for development than react or other frameworks, which seem to be in a permanent state of flux.
        baddox 6y ago
        I should be more clear. I mean the dichotomy between a web site that is only rendered on the server (which is not more difficult to build now than it was 10 years ago), and web sites that have significant client-side interactivity (which are usually and understandably more difficult to build than the former). Of course, there are different versions of the latter: you can have an entirely client-rendered site, or a site that runs largely the same client-side code on the server for initial HTML renders (like React SSR), or a site that renders HTML from the server and then has separate client-side code to enhance interactivity, or any number of combinations of these and other approaches.
- noahtallen 6y ago
  Certainly, the software we write for the browser is much more complex these days. Sure, plenty of website don’t need react and shouldn’t use it. But many of us find react very useful because we are building software with similar creature parity to desktop apps, which wasn’t the case in the early days of the web. Not only that, but the “simple sites” that used to need a dev to build (like for a local restaurant or business or something) can now be done by the restaurant owner on WordPress.com or Wix or something without much effort
- efdee 6y ago
  I have been doing web development for over two decades now, and honestly things were only simpler if your expectations were much, much lower. If you have the same expectations today, everything is still just as simple. If you see no added benefit to having your page run in the browser, then by all means do things the old way, and you'll find that even doing the things the old way is today much simpler than it used to be. If you do want to create a web application that for a large part runs in the browser, I can only see things getting better every year. The perceived added complexity is simply because we are now doing stuff that's more complex. TL;DR: Building horse carriages was a lot easier than building autonomous cars.
- sunaurus 6y ago
  I started my career with jQuery, and soon after moved to Angular v1. There was nothing simple about those tools - the mental models involved were complex, different parts of an application were difficult to isolate from each other and optimizing performance was a nightmare. Compared to all that, React is ridiculously simple - it has a very small API surface, different parts of your app are isolated by default and performance optimization is generally very straightforward. As somebody who really loves simplicity, React is by far my favorite UI library at the moment. I think when people fondly remember simpler times with jQuery, it's not because jQuery itself was simple, it's just that they remember working on less complex applications.
  - mjfisher 6y ago
    When people say "web development used to be simpler", they're probably not referring to the front-end tooling (which has certainly improved) - but when most of the functionality of web apps were built and rendered on the back end, with new state being displayed after full page refreshes or simple AJAX calls.
    - grey-area 6y ago
      > when most of the functionality of web apps were built and rendered on the back end, with new state being displayed after full page refreshes or simple AJAX calls. Most websites (including this one for example) still function that way. It works fine. JS frameworks simply are not required for most of the work the web does nowadays - you can add interactivity and immediate feedback where it makes sense very easily with vanilla js.
- shlob3 6y ago
  completely irrational comment - the web of the past was garbage and simplistic, and no amount of spaghetti jquery will ever change that HN is full of "le wrong generation"and nostalgia blinded devs who think everything in the past was better when it was complete rubbish just like the 90s
mjfisher 6y ago
Ending up with HoC on top of HoC is also an extremely salient point. While it's not strictly required, the structure of larger React projects highly encourages you to create or use non-visual higher order components to manage connections to state stores, APIs etc - or make use of the Context API to achieve the same result. In both cases, you end up with non-UI wrapper components to provide the plumbing in a tree of components that would ideally be entirely presentational. That leads in turn to trying to separate presentational vs. container components, trying to avoid nesting any kind of container component within a pure presentational component to keep it easily testable, creating more HoCs in an attempt to separate concerns, etc. I certainly wouldn't describe React as garbage like the OP - but I think whether it's the best choice is heavily dependent on the kind of app you're building. The design choices it has made comes with significant challenges and trade-offs and we should not pretend otherwise.
- efdee 6y ago
  Higher order components haven't really been a thing since hooks were introduced though.
  - mjfisher 6y ago
    True, but it's important to remember hooks were only released about a year ago - many large projects in existence before then will either not have migrated or be in a state of partial migration. I'm glad they're putting the effort into making the API simpler and easier to use to address some of those concerns, but React itself has been around for seven years now - the vast majority of existing developments will have been started using versions of React created before hooks were introduced.
    - efdee 6y ago
      I very much agree. It just feels weird to complain about a problem that's been solved a year and a half ago.

These are all very, very weird points to raise, except maybe the SSR which is inherently hard to do.

by efdee 6y ago

These are all very, very weird points to raise, except maybe the SSR which is inherently hard to do.

Not if you've been doing web development for a few decades, which I feel the author probably has. I feel like people who came into web development during the past decade really don't understand how much simpler and easier things used to be. It really feels like web development has become crazy complex without much added benefit.

gherkinnn 6y ago
I will never ever go back to the jQuery or vanilla js days. It might have been simpler (what ever that means) but the result was a nightmare to maintain and add to.
- runawaybottle 6y ago
  I’m prepared to go back as the developer I am today versus the developer I was before. It’s almost like just when we’re ready to write some dope Jquery code, it’s time to go write in a new framework. I can say for certain the best React code we will all write will be 5 years from now, but, it’ll be time to move on to the next one.
lumens 6y ago
You know it's real when it hits you in the feels.
baddox 6y ago
It’s not more difficult now to make dynamic server-rendered web sites than it was 10 or 20 years ago (I don’t know about PHP these days, but it’s never been easier to start a new Django or Rails app), but your clients will probably want features they’re accustomed to in modern web applications that are not easily implemented in server-rendered web sites.
- grey-area 6y ago
  What kind of features require you to use react?
  - baddox 6y ago
    None require React specifically, of course. I’m only referring to the dichotomy between server-rendered apps and apps with significant client-side interactivity.
    - grey-area 6y ago
      I sincerely think that dichotomy is not a useful one - that's not a choice you have to make. You can have server-rendered apps with significant interactivity (where it makes sense). Many large websites still use server side rendering (in whatever language they want), and js to refresh data client-side as required and respond to user actions, pulling data from the server side. There is no need to attempt to move everything to client-side, it doesn't make the UX better IMO, sometimes it makes it worse. Keeping most logic and templates server-side works just fine on large complex sites serving millions of people, and it's significantly simpler and more stable for development than react or other frameworks, which seem to be in a permanent state of flux.
      - baddox 6y ago
        I should be more clear. I mean the dichotomy between a web site that is only rendered on the server (which is not more difficult to build now than it was 10 years ago), and web sites that have significant client-side interactivity (which are usually and understandably more difficult to build than the former). Of course, there are different versions of the latter: you can have an entirely client-rendered site, or a site that runs largely the same client-side code on the server for initial HTML renders (like React SSR), or a site that renders HTML from the server and then has separate client-side code to enhance interactivity, or any number of combinations of these and other approaches.
noahtallen 6y ago
Certainly, the software we write for the browser is much more complex these days. Sure, plenty of website don’t need react and shouldn’t use it. But many of us find react very useful because we are building software with similar creature parity to desktop apps, which wasn’t the case in the early days of the web. Not only that, but the “simple sites” that used to need a dev to build (like for a local restaurant or business or something) can now be done by the restaurant owner on WordPress.com or Wix or something without much effort
efdee 6y ago
I have been doing web development for over two decades now, and honestly things were only simpler if your expectations were much, much lower. If you have the same expectations today, everything is still just as simple. If you see no added benefit to having your page run in the browser, then by all means do things the old way, and you'll find that even doing the things the old way is today much simpler than it used to be. If you do want to create a web application that for a large part runs in the browser, I can only see things getting better every year. The perceived added complexity is simply because we are now doing stuff that's more complex. TL;DR: Building horse carriages was a lot easier than building autonomous cars.
sunaurus 6y ago
I started my career with jQuery, and soon after moved to Angular v1. There was nothing simple about those tools - the mental models involved were complex, different parts of an application were difficult to isolate from each other and optimizing performance was a nightmare. Compared to all that, React is ridiculously simple - it has a very small API surface, different parts of your app are isolated by default and performance optimization is generally very straightforward. As somebody who really loves simplicity, React is by far my favorite UI library at the moment. I think when people fondly remember simpler times with jQuery, it's not because jQuery itself was simple, it's just that they remember working on less complex applications.
- mjfisher 6y ago
  When people say "web development used to be simpler", they're probably not referring to the front-end tooling (which has certainly improved) - but when most of the functionality of web apps were built and rendered on the back end, with new state being displayed after full page refreshes or simple AJAX calls.
  - grey-area 6y ago
    > when most of the functionality of web apps were built and rendered on the back end, with new state being displayed after full page refreshes or simple AJAX calls. Most websites (including this one for example) still function that way. It works fine. JS frameworks simply are not required for most of the work the web does nowadays - you can add interactivity and immediate feedback where it makes sense very easily with vanilla js.
shlob3 6y ago
completely irrational comment - the web of the past was garbage and simplistic, and no amount of spaghetti jquery will ever change that HN is full of "le wrong generation"and nostalgia blinded devs who think everything in the past was better when it was complete rubbish just like the 90s

mjfisher 6y ago

Ending up with HoC on top of HoC is also an extremely salient point. While it's not strictly required, the structure of larger React projects highly encourages you to create or use non-visual higher order components to manage connections to state stores, APIs etc - or make use of the Context API to achieve the same result. In both cases, you end up with non-UI wrapper components to provide the plumbing in a tree of components that would ideally be entirely presentational. That leads in turn to trying to separate presentational vs. container components, trying to avoid nesting any kind of container component within a pure presentational component to keep it easily testable, creating more HoCs in an attempt to separate concerns, etc. I certainly wouldn't describe React as garbage like the OP - but I think whether it's the best choice is heavily dependent on the kind of app you're building. The design choices it has made comes with significant challenges and trade-offs and we should not pretend otherwise.

efdee 6y ago
Higher order components haven't really been a thing since hooks were introduced though.
- mjfisher 6y ago
  True, but it's important to remember hooks were only released about a year ago - many large projects in existence before then will either not have migrated or be in a state of partial migration. I'm glad they're putting the effort into making the API simpler and easier to use to address some of those concerns, but React itself has been around for seven years now - the vast majority of existing developments will have been started using versions of React created before hooks were introduced.
  - efdee 6y ago
    I very much agree. It just feels weird to complain about a problem that's been solved a year and a half ago.