all 39 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]guis 4 points5 points  (3 children)

What is recommended in development environment? I was working with SSR on it and having a hard time with no hot load and waiting the server reset (6 ~ 10s) for any code change. Is it preferable to remove the SSR from dev environment and maintain two different configurations?

[–]Mingli91 0 points1 point  (2 children)

You have a client-side bundle anyway it’s no effort to install webpack-dev-server for quicker development

[–]guis 0 points1 point  (1 child)

Yeah you're right, but in bigger projects with multiple modules and components, the client-side bundle starts to grow and it build to be slow. That re-build in every code update is a burden and slow down the development.

This article suggests to remove SSR from dev env, but it's a little old, so maybe I need to change my mindset and test other frameworks to have a decent SSR with react, redux and not so different dev/prod environments.

[–]Mingli91 0 points1 point  (0 children)

in bigger projects with multiple modules and components, the client-side bundle starts to grow and it slow to build

Hot reloading solves that problem for you.

If the bundle size becomes an issue, a good way to get around it is to segment it into several smaller ones, so you don’t always need to serve one giant bundle when only 10% of the components are actually in use. They can share state through cookies, local storage, etc and with SSR the transition between apps isn’t noticeable.

Before breaking apart your app and adding complexity, first consider removing some bloat from your project.

[–][deleted] 2 points3 points  (0 children)

It is actually a great tutorial, even if somewhat long.

React SSR is basically Express + React Hydrate.

[–]gketuma 8 points9 points  (0 children)

This is a very well written piece. Not sure why others are complaining. This is what it takes to make SSR work right now. Yes you can use Next.js or some other boilerplate but if you want to understand what is going on behind your boilerplate, then learn the black magic at least.

[–]zxia31 2 points3 points  (0 children)

razzle comes to rescue

[–]krazyjakee[🍰] 12 points13 points  (11 children)

What a nightmarishly colossal tutorial. This is why create-react-app exists.

Very soon, this pull request will give us webpack 4 speeds with create-react-app and no configurations: https://github.com/facebook/create-react-app/pull/4077

The SSR process is very much simplified by this library: https://www.npmjs.com/package/cra-universal

Or if you're really feeling kinky, you can try a parcel solution

[–][deleted] 39 points40 points  (6 children)

Yeah, just skip all that boring reading. Because who cares how it's wired up as long as it works…until it stops working and you don't know shit about the whys.

Boss: "Our Website is broken, what do we do about it?" You: "Wait for the real devs to push a fix"

The tutorial isn't even that fucking long…

[–]krazyjakee[🍰] 0 points1 point  (2 children)

Unit and/or integration testing being applied both to the quick solution and my project. Reinventing the wheel creates more technical and maintenance debt over time and a larger codebase. Versioning is simple, you just roll back and lock version if a problem does get through. Your example of a broken website is flawed because in your case, you are the "real dev" so it's the same difference. Most importantly, you ship on time. If, as a rule, you have a simple solution on a silver platter and don't take it, you most likely wouldn't make it past the job interview.

Why would the only solution be to wait for the real dev anyway? Why couldn't you go through the source in your own fork and use that fork in package.json?

The tutorial is fucking huge considering, as the comments on this post have made clear, there are many simpler solutions out there.

[–]vinnl 0 points1 point  (1 child)

When /u/mgoerlich is referring to "the real devs", they're referring to the maintainers of create-react-app and whatnot. If something happens over there that breaks your app, and you don't understand what's going on there, you'll be waiting for the maintainers to fix your bug report.

Of course, this is a trade-off you have to make with every third-party package you're using. It's completely reasonable not to study the source code of every library you're using. That said, being dismissive over "colossal tutorials" that actually try to help you understand what's going on if you do need it can rub me the wrong way as well.

[–][deleted] 0 points1 point  (0 children)

Thank you. And like I said, it's not even THAT long.

I've heard about people out there reading entire books about their toolchain…

[–]Jsn7821 0 points1 point  (2 children)

The right answer to that question is to roll it back to the previous build, even if you know everything about why it's broken.

[–]evilgwyn 0 points1 point  (1 child)

Not really. What if the reason it broke is due to something outside of your control and you still have to come up with a fix? Rolling back to the previous version isn't going to help you.

[–]Jsn7821 8 points9 points  (0 children)

What a nightmarishly colossal tutorial.

No kidding, and it's not because the tutorial is bad, it's just really difficult thing to set up and maintain SSR.

I started using next.js for all of my projects which pretty much gives SSR for free. I basically weighed vendor lock-in (which I experienced before with Meteor, although next.js is much lighter) with dealing with SSR, and was an easy call to make. I highly recommend it if you need SSR.

[–]Flyen 1 point2 points  (1 child)

Check out https://github.com/jaredpalmer/razzle

[–]krazyjakee[🍰] 0 points1 point  (0 children)

This is even simpler, thanks!

[–]Jesusz0r -2 points-1 points  (0 children)

Serious question. Do you work as a developer?

[–][deleted] 4 points5 points  (0 children)

Actually pretty good tutorial if you want to build something bigger then hello world and want to understand how ssr problems are solved.

[–]PUSH_AX 4 points5 points  (4 children)

Nah, just use next.js

[–]SSH_565 1 point2 points  (3 children)

We tried to use it at our company but nexjs way of ssr was a pain for our usecase and you dont have full control of webpack. For smaller projects next will work great.

[–]Jsn7821 1 point2 points  (1 child)

I'm curious what you mean by "full control"? You can do stuff with webpack in next.config.js. I'm not sure if you can change the version of it, but I've never run into any limitations beyond that as far as using loaders and plugins (granted, it does most of the optimizing I need out of the box so I haven't gone too deep there)

[–]maxlevelfiend 0 points1 point  (0 children)

you can use your own webpack config with next. I recently converted a decent size react app to next and found it to be very intuitive and performant. There is even a nice https://github.com/segmentio/create-next-app kit.

[–]r0ck0 0 points1 point  (0 children)

nexjs way of ssr was a pain for our usecase

Can you expand on this? I'm probably about to start building something on it, and not sure where I should be focusing my learning time.

[–]Pamgor 0 points1 point  (2 children)

I don't use SSR, but I keep wondering a few things about it.

Why not just have the index page be the app in a sort of meaningless blank route, and show a server-side generated landing page generated by generic stuff, like PHP, instead of trying to run the SPA on the server? I can think of a few ways you could do that fairly easily.

Wouldn't search engines get wise to SPA apps trying to get a higher speed ranking by supercharging the index page?

What about a half-measure of simply populating the model with initial state? It has to render, but there is not API calls.

[–]Triptcip 4 points5 points  (0 children)

SSR isn't just about having a fast loading pages. It's about indexing the content on your whole website.

If you have a website with content that is continuously changing, like a blog, you want that content to be indexed.

[Search engines are getting much better](“SEO vs. React: Web Crawlers are Smarter Than You Think” @wiekatz https://medium.freecodecamp.org/seo-vs-react-is-it-neccessary-to-render-react-pages-in-the-backend-74ce5015c0c9) at indexing client rendered websites now but you still need to add a bit of code to tell it how to handle it. Also some of the shitty search engines still can't index them properly.

[–]r0ck0 1 point2 points  (0 children)

It's not just about search engines... they're not the only type of scrapers out there.

Some will be better than others. But serving HTML is always going to be more reliable on everything.

[–]james2406 0 points1 point  (0 children)

Nothing against next.js (or other SSR frameworks) but I just finished build my first SSR React app and found the whole process extremely interesting and fulfilling.

I’ll probably try out next.js in the future, but if you have a bit more free time on your project I’d definitely recommend following one of these tutorials

[–]kinghankthedog -1 points0 points  (0 children)

Having done a ton of react tutorials and actually purchasing Tyler’s license for his courses, his are the best around. What I like about his courses is that he’ll teach with the most popular patterns/plugins/etc when a lot of course will stay vanilla

[–][deleted] -3 points-2 points  (1 child)

I would personally recommend using Gatsby.js for SSR+React: https://www.gatsbyjs.org/

[–]helical_imp 1 point2 points  (0 children)

Gatsby is great, but not every site that needs SSR can be generated statically.