6 ms·

React gives me happiness in these unpredictable times

by lpa22 4y ago

ralusek 4y ago
It's aight
cersa8 4y ago
Sounds pretty dramatic on the surface, but it does indeed give great comfort to have a stable frontend library that's improving in all the right places. React + TypeScript powers the UI of my business and I've never felt more happy about my frontend code. Being on a dead-end framework library and still having to add features because you dread moving to greener pastures is pretty demotivating.
- steve_adams_86 4y ago
  I couldn’t agree more. People are quick to criticize, but in a very long time spent building user interfaces for the web, I’ve never been more confident in and happy to build with a set of tools. TypeScript and React together are excellent. There’s plenty to improve still, but like you said, it’s stable and improving in all the right places.
  - ricardobeat 4y ago
    Unfortunately React + Typescript is not a complete solution for building websites. What people are “quick to criticize” includes tools like webpack, CRA, emotion, remotion, redux/recoil, babel, the 1000 modules and all the other crap required to build a single page. Experiences vary tremendously.
    - cersa8 4y ago
      A "complete solution" is perfectly fine to hit the ground running, but will not stay complete once you go beyond an MVP. I started with WordPress with a bunch of plugins and after extending WP beyond its intended purpose decided I rather pick a set of high quality mainstream libraries (next.js, knex.js, passport.js, sharp, bcrypt, MobX, etc) to build upon than shoehorn a complete solution to my needs. I think Next.js has taken a lot of pain out of Webpack/bundling even though I have some gripes with the (SSR) data fetching API.
      - steve_adams_86 4y ago
        What are your gripes with SSR in Next? I have some too. I find the router in next is generally lacking, and there’s no proper way to say “render this on the server for the first request, but do this if the request comes from the application”. I believe there was a method to do it that was deprecated, but in my experimenting it was still not behaving the way I expected. The main issue was that it was hard to prevent various levels of rendering in the page even though I knew it was redundant. When using remix this is trivial to accomplish. I’m not sure I’m sold on remix entirely, but the routing capabilities are far better than Next’s. Also some recent tweets from vercel suggest to me that they might be resolving this soon. Here’s hoping!
        cersa8 4y ago
        Routing is indeed another pain point especially with internationalisation and having multiple dynamic/translated paths to the same page. My issue with data fetching is about the depreciation of getInitialProps() without a good alternative in place: https://github.com/vercel/next.js/discussions/10874 https://github.com/vercel/next.js/discussions/10874 I need a single place to load site translations, user data and what not, preferably without refetching this data on each page transition. I also briefly looked at Remix and love the routing, but do not necessarily want Remix to dictate how I mutate my data.
        steve_adams_86 4y ago
        Yeah, we’re on the same page with getInitialProps. Next needs something which accomplishes what people want from that, but with ongoing support from the team. I think it’s a special circumstance but still important to support. I’m not aware of a work around at this point. How does remix dictate how you mutate your data?
        cersa8 4y ago
        "How does remix dictate how you mutate your data?" I didn't word it correctly as Remix doesn't dictate the model. It does seem to have a strong opinion on how to handle form submissions. Trying to closely follow the browsers native form api does make a lot of sense in most situations, but I like a more JavaScript heavy approach to form handling. Especially since I have a lot of complex form interactions.
    - steve_adams_86 4y ago
      You’re not wrong. I think a big part of this problem is that people need to know why they’re choosing a dependency and what problem it solves, and if that aligns with what they’re building properly. For example, if you choose redux, why are you choosing it? Why choose it over the context api in react with built in state management, or zustand, jotai, or etc. In any stack you should be able to answer these questions, not just JS in the browser, but my experience is that a lot of JS teams haven’t determined this properly. It’s a recipe for struggle because they end up using more dependencies and in house code to band aid the fact that their tooling doesn’t work well with their software. The result is that the wrong dependencies and too many of them are used. This makes everything from building to testing to maintenance harder. A great goal on any team is to minimize the number of dependencies used in the first place; they’re often looked at as necessary to solve various problems, but they might not be at all. Some degree of trouble is inevitable because the JS world is kind of crazy, but it doesn’t have to be bad.
- veidelis 4y ago
  "stable frontend library" - I disagree. How class components were deprecated is just ridiculous to me.
  - aarpmcgee 4y ago
    As far as I can tell, class components are not deprecated and still featured prominently in the official React docs. Did you mean something else?
sph 4y ago
Meh, to me it's indeed a product of our times. Someone came to us with the solution to all (frontend) problems - our unhappiness - and then you find out it's even more complex than what came before so we're working even harder for this new master. [1] I like React on a 10 line project, I loathe it on a 100k line project, the overengineering, the npm dance, the hundred of dependencies that are a gust of wind away from breaking the illusion of a coherent and working system. Now we just have wait for the solution to the React problem. Sorry, this came out more depressing than I originally intended. 1: https://youtu.be/egNKT0k__2w https://youtu.be/egNKT0k__2w

React gives me happiness in these unpredictable times

by lpa22 4y ago

React gives me happiness in these unpredictable times

ralusek 4y ago

It's aight

cersa8 4y ago

Sounds pretty dramatic on the surface, but it does indeed give great comfort to have a stable frontend library that's improving in all the right places. React + TypeScript powers the UI of my business and I've never felt more happy about my frontend code. Being on a dead-end framework library and still having to add features because you dread moving to greener pastures is pretty demotivating.

steve_adams_86 4y ago
I couldn’t agree more. People are quick to criticize, but in a very long time spent building user interfaces for the web, I’ve never been more confident in and happy to build with a set of tools. TypeScript and React together are excellent. There’s plenty to improve still, but like you said, it’s stable and improving in all the right places.
- ricardobeat 4y ago
  Unfortunately React + Typescript is not a complete solution for building websites. What people are “quick to criticize” includes tools like webpack, CRA, emotion, remotion, redux/recoil, babel, the 1000 modules and all the other crap required to build a single page. Experiences vary tremendously.
  - cersa8 4y ago
    A "complete solution" is perfectly fine to hit the ground running, but will not stay complete once you go beyond an MVP. I started with WordPress with a bunch of plugins and after extending WP beyond its intended purpose decided I rather pick a set of high quality mainstream libraries (next.js, knex.js, passport.js, sharp, bcrypt, MobX, etc) to build upon than shoehorn a complete solution to my needs. I think Next.js has taken a lot of pain out of Webpack/bundling even though I have some gripes with the (SSR) data fetching API.
    - steve_adams_86 4y ago
      What are your gripes with SSR in Next? I have some too. I find the router in next is generally lacking, and there’s no proper way to say “render this on the server for the first request, but do this if the request comes from the application”. I believe there was a method to do it that was deprecated, but in my experimenting it was still not behaving the way I expected. The main issue was that it was hard to prevent various levels of rendering in the page even though I knew it was redundant. When using remix this is trivial to accomplish. I’m not sure I’m sold on remix entirely, but the routing capabilities are far better than Next’s. Also some recent tweets from vercel suggest to me that they might be resolving this soon. Here’s hoping!
      - cersa8 4y ago
        Routing is indeed another pain point especially with internationalisation and having multiple dynamic/translated paths to the same page. My issue with data fetching is about the depreciation of getInitialProps() without a good alternative in place: https://github.com/vercel/next.js/discussions/10874 https://github.com/vercel/next.js/discussions/10874 I need a single place to load site translations, user data and what not, preferably without refetching this data on each page transition. I also briefly looked at Remix and love the routing, but do not necessarily want Remix to dictate how I mutate my data.
        steve_adams_86 4y ago
        Yeah, we’re on the same page with getInitialProps. Next needs something which accomplishes what people want from that, but with ongoing support from the team. I think it’s a special circumstance but still important to support. I’m not aware of a work around at this point. How does remix dictate how you mutate your data?
        cersa8 4y ago
        "How does remix dictate how you mutate your data?" I didn't word it correctly as Remix doesn't dictate the model. It does seem to have a strong opinion on how to handle form submissions. Trying to closely follow the browsers native form api does make a lot of sense in most situations, but I like a more JavaScript heavy approach to form handling. Especially since I have a lot of complex form interactions.
  - steve_adams_86 4y ago
    You’re not wrong. I think a big part of this problem is that people need to know why they’re choosing a dependency and what problem it solves, and if that aligns with what they’re building properly. For example, if you choose redux, why are you choosing it? Why choose it over the context api in react with built in state management, or zustand, jotai, or etc. In any stack you should be able to answer these questions, not just JS in the browser, but my experience is that a lot of JS teams haven’t determined this properly. It’s a recipe for struggle because they end up using more dependencies and in house code to band aid the fact that their tooling doesn’t work well with their software. The result is that the wrong dependencies and too many of them are used. This makes everything from building to testing to maintenance harder. A great goal on any team is to minimize the number of dependencies used in the first place; they’re often looked at as necessary to solve various problems, but they might not be at all. Some degree of trouble is inevitable because the JS world is kind of crazy, but it doesn’t have to be bad.
veidelis 4y ago
"stable frontend library" - I disagree. How class components were deprecated is just ridiculous to me.
- aarpmcgee 4y ago
  As far as I can tell, class components are not deprecated and still featured prominently in the official React docs. Did you mean something else?

sph 4y ago

Meh, to me it's indeed a product of our times. Someone came to us with the solution to all (frontend) problems - our unhappiness - and then you find out it's even more complex than what came before so we're working even harder for this new master. [1] I like React on a 10 line project, I loathe it on a 100k line project, the overengineering, the npm dance, the hundred of dependencies that are a gust of wind away from breaking the illusion of a coherent and working system. Now we just have wait for the solution to the React problem. Sorry, this came out more depressing than I originally intended. 1: https://youtu.be/egNKT0k__2w https://youtu.be/egNKT0k__2w