3 ms·

Unfortunately React + Typescript is not a complete solution for building websites. What people are “quick to criticize” includes tools like webpack, CRA, emotio

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.

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.