Express JS with Handlebars templating has always been my favourite. Simple, lightweight SSR rendered pages.
We fell out of love with Next.js and back in love with Ruby on Rails
451–460 of 533 posts
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#452Earlier quoted context omitted.
As somebody with an expert level knowledge with MVC frameworks like Ruby on Rails and Phoenix Framework, etc., and an experience building large-scale enterprise-grade apps using simpler technologies like jQuery, StimulusJS and plain old JavaScript on the front end with a little bit of React thrown in here and there, I found Development cycles to be much faster with these simpler stacks overall. The complexity of the…
I never get these comments. I would choose a Next.js / React project to work on 99% of the time compared to the hellish nightmare that is jQuery.
Interesting because I think jQuery, although a nightmare, is a much smaller one than the today's stack of React single page apps. Everything from bundling to package management and the hell with modules and dependencies seems to be too much to maintain. I am probably going to be okay to take it on the front end, but I cannot take JavaScript on the back end.
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#453I'm thankful that I don't work on projects that have SEO needs. SSG (for JS frameworks specifically) feels too unstable for me. I get the value, I understand why people need to do it, but it just makes everything more complicated. Also, I'm not sure if you can have an offline site with SSG? They might be compatible but I'm not sure. I know some SSG is essentially "SPA with the first page rendered already" so maybe th…
What's SSG?
Usually refers to Static Site Generator, but I suspect in this context Server Side Rendering was what was meant.
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#454Earlier quoted context omitted.
The good news is GraphQL is very quick and easy to pick up and it gives that inbuilt functionality to fetch exactly the amount of data that we need. On top of it, it also has enough flexibility to integrate with your business logic. So it can be a straightforward replacement for a traditional REST API that you would have to manually build. For the disadvantages, I cannot think of any. It is a bit slower than hand rol…
The biggest issue is security. More often then not, the API allows you to see more than you should.
This is probably true, and it can only be uncovered by rigorous testing. There is a bunch of layers of abstraction that won't be very obvious if you are using GraphQL as opposed to rolling your own REST API.
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#455I can't speak to the technical aspects here (I'm only familiar with nextjs not rails, so it's unclear to me how much of the article is just a reflection of the author's own comfortability with rails or a reflection of a more technically suitable architecture). But I do find it really weird that a company which apparently has multiple software engineers is worried about infrastructure costs amounting to less than $1k…
We have one developer (me) and we're bootstrapped and not yet profitable. That means I'm paying the difference every month in hosting and working for free. The site makes it look like we have a lot more together than we are.
Fair enough. I think I misinterpreted the "as new team members joined" paragraph as talking about other engineers.
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#456Earlier quoted context omitted.
Multiple times in this thread you have been taking the hardline stance that a framework is always necessary while stating that others are saying the same in the opposite direction. In reality, most people seemingly advocating for non-React are actually saying to start simple and add the complexity where and when it’s needed. Further, being against a bloated framework is not the same as being against frameworks. Those…
Your reading of my point is very strange. When I said “best practices” I clearly meant the most commonly repeated best practices. If I cast doubt on those best practices then clearly I intend to replace them with other best practices that I think are better, and that’s what I did. And suggesting better practices doesn’t imply that I think people should blindly follow them. > Most people seemingly advocating for non-R…
Exactly right. The "start simple and add the complexity where and when it’s needed" is a badly flawed way of thinking, in web apps, because once an app becomes too big to manage without BOTH a framework AND a type-safe language (TypeScript) then it you realize everything you've done up to that point must be reworked line by line, which costs you weeks, and you have to retest everything, and will make mistakes as you try to fix the mess. It's a mess that's easily avoided, just by using a framework from day one.
You can't just switch horses in the middle of the stream. You have to ride back to the ranch, saddle up on a different horse, and restart your entire journey on a better horse.
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#457Earlier quoted context omitted.
That's funny, I would say the go-to is Prisma. We use it heavily and have not had any issues.
Very lucky to not have encountered one of the 500 open and confirmed bugs!
A project suffering from success. The more usage, the more edge cases you'll find and the more bug reports.
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#458Earlier quoted context omitted.
I agree, just use React from day one. The reality is that web pages are hardly ever perfectly static, and once there's any dynamic nature to it at all you need something like React or else you'll have a train wreck of JS DOM-manipulation calls before you know it. React is perfect. You just update your state and the page magically re-renders. It's a breeze.
Multiple times in this thread you have been taking the hardline stance that a framework is always necessary while stating that others are saying the same in the opposite direction. In reality, most people seemingly advocating for non-React are actually saying to start simple and add the complexity where and when it’s needed. Further, being against a bloated framework is not the same as being against frameworks. Those…
> most people seemingly advocating for non-React are actually saying to start simple
This assumes that non-React approaches are simple.
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#459I fell in love with React because of its SPA approach, as opposed to SSR. You must imagine my chagrin when React started moving towards rendering on the server(SSR, Server Components, etc). I was happy to move to a full client implementation. Sadly, SEO cannot be ignored.
NextJS et al are still SPAs. SPA and SSR/SSG are not mutually exclusive.
Re: We fell out of love with Next.js and back in love with Ruby on Rails
#460I wonder why there is a debate Next.js vs. SSR. Nextjs is a hybrid and performs quite well. Contrasting with other SPA frameworks, Nextjs produces prerendered html output for fast first loads, efficient js chunks, config switches to eagerly-load those chunks (ie. when hovering over a link or preloading all n+1 links after page render) and efficient image (pre-)loading depending on breakpoint (usually the achilles hee…
NextJS has a lot of significant drawbacks, that's why there's an ongoing debate (which is healthy): - Cost - Complexity - Learning curve - Scalability - Frequent changes - And surprisingly bad performance compared with the direct competitors Nowadays, NextJS is rarely the best tool for the job. Next and React are sitting in the "never got fired for buying IBM" spot. It is a well earned position, as both had a huge in…
Cost? NextJS is free, and can be hosted on free services like GitHub/Cloudflare Pages.