[smokeyj]

The whole thing is a solved problem. You can easily render React apps on the server and send HTML down the wire, then lazy load the rest of the JS. Author could have installed next.js and called it a day.

If you put your app logic in something like Redux it'll work on server-side rendering, client-side rendering, and can be included in react-native down the line.

In the time the author re-wrote his app, I could have gotten the same benefits with SSR and ported it to react native. But yeah, javascript bad REEEE

[tomca32]

> Author could have installed next.js and called it a day.

Not a day, but probably a week of debugging. Each and every suggestion you made in your comment makes the deliverable tremendously more complex, is very expensive, will need ongoing maintenance, and is ultimately not needed.

Javascript apps are tremendously complex, why would do this if you don't have to?

[smokeyj]

Imagine you have a team of rails developers and you're asked to create a simple portal. Rails as a tool may be "overkill" but what does it matter?

If you already know Rails I'd say use that. If you only knew ruby then reaching for rails would be overkill. But if your business requirements need the features of Rails, learn rails instead of rolling your own framework..

[tomca32]

I completely agree with you, which is why I think that telling people to "just install next.js" is a terrible advice. If they are JS devs, experienced in next, sure, go right ahead, but I don't think that's the case here.

I'd be fine to just use Rails for something like that since I'm quite familiar with Rails, but I would never recommend it to someone who doesn't know it.

[smokeyj]

> If they are JS devs, experienced in next, sure, go right ahead, but I don't think that's the case here.

The author is clearly experienced in UI development. The app was already written in React/Redux. So honestly, yeah, just install next.js and fix your routes.

This solution would be a complete non starter for any professional project in terms of accessibility - there's a few issues screen readers would run into with this. Not only that, but good luck getting other developers to sift through your spaghetti code.

But the main thing is, the authors goals are somewhat pointless. If you don't want a SPA then just use jQuery. The author ended up using plugins anyways so the whole story was aimed at people who don't know front-end but latch onto this idea of javascript is baaad. Don't be that guy.

So to recap. If you don't know javascript, and you don't want to learn the standard tooling - please don't roll your own framework and blog about it.

Edit: looks like someone already commented this on his blog. This is all you need to know: https://dev.to/isfotis/comment/9c7k

[cuddlecake]

I am genuinely curious, what kind of Rails features can satisfy which business requirements?

I thought people use Rails mainly because they like it or are thrown into a team that already uses it.

[mickael-kerjean]

The ecosystem is even today the main selling point to rails

[lhorie]

> I could have gotten the same benefits with SSR and ported it to react native

Are you saying that rhetorically? In my experience, React is no silver bullet (e.g. different router and styling mechanisms for RN), trickiness dealing w/ timezones in SSR, etc.

And besides, the point here was largely about bundle size and fast time-to-interactive. Next.js optimizes a lot for developer experience, but you're definitely still going to be shipping a pretty sizeable JS bundle with slower characteristics than a hand-coded "closer-to-the-metal" thing.

[smokeyj]

> Are you saying that rhetorically?

No.

> And besides, the point here was largely about bundle size and fast time-to-interactive.

As long as the point wasn't to be productive I'll just mind my own business.

[hliyan]

A lot of people here (including the author and myself) who have written multiple production applications using React and Redux will know that "just install next.js and call it a day" is a wild oversimplification. In fact, some of us were earlier adopters and enthusiasts of SPAs and flux architecture. You're seeing more and more write-ups on the problems with this approach because the early adopters are now long past the honeymoon and are entering long term maintenance.