Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We fell out of love with Next.js and back in love with Ruby on Rails

hardcover.app

Post reply on HN
Print view View original

421–430 of 533 posts

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#421

Post by const_cast »

hombre_fatal wrote: post #400
Capricorn2481 wrote: post #396

Earlier quoted context omitted.

> I would actually say overall C++ is much more reasonable. This is where I know that, some people, are not actually programming in either of these languages, but just writing meme driven posts. JS has a few footguns. Certainly not so many that it's difficult to keep in your head, and not nearly as complex as C++, which is a laughable statement. You've "seen null make it to the database," but haven't seen the exact s…

Yeah, I don't know how someone can say that with a straight face to other engineers. It's like people just talk in memes or something. This is how a lot of discourse feels these days. People living in very different realities. Though in this case, seeing the most complex C++ app they've built would illuminate what's going on in theirs.

It's not a different reality. To give perspective to what JS I've dealt with - I worked a couple years on a legacy webapp. It used vanilla JS and the only library used was jQuery. It heavily used iframes for async functionality in combination with XSLT to translate backend XML apis to HTML.

Opening up a 10K lines JS file is like jumping into the ocean. Nothing is obvious, nothing makes sense. You're allowed to just do whatever the fuck in JS. Bugs where always ephemeral. The behavior of the code was impossible to wrap your head around, and it seemed to change under your feet when you weren't looking.

Now, the backend was written in old C++. And yes, it was easier to understand. At least, I could click and go to definition. At least, I could see what was going in and out of functions. At least, I could read a function and have a decent understanding of what it should be doing, what the author's intention is.

The front end, spread across a good thousand JS files, was nothing of the sort. And it was certainly more buggy. Although, I will concede, bugs in C++ are usually more problematic. In JS usually it would just result in UI jankyness. But not always.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#422

Post by dyogenez »

henning wrote: post #10

> hitting a GraphQL API (Hasura) for getting data, and caching as much as possible using Incremental Static Revalidation. The first load was often a bit slow, but caching helped. Why do you need GraphQL here? If your developer workstation can't send a few KB of data over a TCP socket in a reasonable amount of time due to the colossal amount of Zoomer JavaScript abstraction nonsense going on, something has gone terrib…

> Why do you need GraphQL here?

The app was initially client-side only. I choose GraphQL over REST because Hasura created a super quick API for the database.

Also, our API is public! We started as an alternative to Goodreads when they closed their API.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#423

Post by tekno45 »

wordofx wrote: post #281
lmm wrote: post #157

Earlier quoted context omitted.

Every webapp built with something other than GraphQL ends up with an ad hoc, informally-specified, bug-ridden, slow implementation of half of GraphQL. Yes, a book tracking app absolutely needs GraphQL. Do you need a separate frontend framework? No, probably not, and that's exactly the problem that Next solves - write your backend and frontend in the same place. Do you need a complicated build process? No. You want yo…

GraphQL is the new mongodb. This fancy new thing that people want to use and makes no sense in reality and just causes more problems than it solves. It solves a very specific problem that makes sense at Facebook. It makes 0 sense for companies that have a web app or web and mobile app. And nothing else. Anyone deciding to use graphql is making a dumb decision.

GraphQL is webscale

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#424

Post by const_cast »

balencpp wrote: post #325
const_cast wrote: post #195

Earlier quoted context omitted.

No you really don’t. I’ve worked on exceptionally complex legacy applications with essentially no state in the front end. At most, you’re looking at query parameters. You just make everything a full page reload and you’re good to go.

So you make incrementing a counter a full page reload?

What's the business usecase for incrementing a counter?

We can sit here all day and think up counterexamples, but in the real world what you're doing 99% of the time is:

1. Presenting a form, custom or static.

2. Filling out that form.

3. Loading a new page based off that form.

When I open my bank app or website, this is 100% of the experience. When I open my insurance company website, this is 100% of the experience. Hell, when I open apartments.com, this is like 98% of the experience. The 2% is that 3D view thingy they let you do.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#425

Post by neonsunset »

t-writescode wrote: post #409
neonsunset wrote: post #368

Earlier quoted context omitted.

Sounds improbable. Unlike Ruby, JavaScript has multiple runtime implementations with capable JIT compilers that sometimes let it even compete with Java on numeric code. Ruby is very, very far away. Please note that Elixir is also in the same single-threaded performance ballpark as Ruby and Python, of course it does not suffer from any of the single-threaded bottlenecks the other two do though.

Tl; dr: color me genuinely surprised. --- I have now done several Google searches to - well, admittedly, to try and counter your argument; but what I've since found is: * Every friggin' benchmark is wildly different [0, 1] * Some of these test pages are obnoxious to read and filter; **BUT** Javascript regularly finds itself to be **VERY** fast [0] On a more readable and easily-filtered version (that has very differne…

FWIW web-frameworks-benchmark is bad and has strange execution environment with results which neither correlate nor are reproducible elsewhere. TechEmpower also has gotten way worse, I stopped looking at it because its examples perform too little work and end up being highly sensitive to factors not related to the languages chosen or may be a demonstration of underlying techniques optimizing for maximum throughput, which in real world is surprisingly rare scenario (you would probably care more about overall efficiency, reasonable latency and reaching throughput target instead). TechEmpower runs on very large machines where you get into a territory that if you're operating at such scale and hardware, you're going to (have to) manually tune your application anyway.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/... is the most adequate, if biased in ways you may not agree with, if you want to understand raw _language_ overhead on optimized-ish code (multiplied by the willingness of the submission authors to overthink/overengineer, you may be interested in comparing specific submissions). Which is only a half (or even one third) of the story because the other half, as you noted, is performance of frameworks/libraries. I.e. Spring is slow, ActiveJ is faster.

However, it's important to still look at the performance of most popular libraries and how well the language copes with somewhat badly written user code which absolutely will dominate the latency way more often than anyone trying to handwave away the shortcomings of interpreted languages with "but I/O bound!!!" would be willing to admit.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#426

Post by neonsunset »

const_cast wrote: post #419
Capricorn2481 wrote: post #396

Earlier quoted context omitted.

> I would actually say overall C++ is much more reasonable. This is where I know that, some people, are not actually programming in either of these languages, but just writing meme driven posts. JS has a few footguns. Certainly not so many that it's difficult to keep in your head, and not nearly as complex as C++, which is a laughable statement. You've "seen null make it to the database," but haven't seen the exact s…

I haven't seen null make it to the database, I've seen undefined . And here you demonstrate one of many problems - there's multiple null types! In C++, there's only one null, nullptr . But most types can never be null. This is actually one area where C++ was ahead of the competition. C# and Java are just now undoing their "everything is nullable" mistakes. JS has that same mistake, but twice. It's not about complexit…

C# introduced nullable reference types back in 2019, so it's been some time and now the vast majority of the ecosystem uses null-aware code. The only remaining warts are around a. codebases which refuse to adopt this / opt out of it and b. serialization.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#427

Post by TranquilMarmot »

vdfs wrote: post #216
twodave wrote: post #168

We used NextJS on a couple of projects where I work and are already phasing them out. The reasons are manifold, but a few key factors: * difficult auth story. next-auth is limited in a few ways that drove us to use iron-session, such as not being able to use a dynamic identity provider domain (we have some gov clients who require us to use a special domain). This required us to basically own the whole openid flow, wh…

What did you move to? We've been using NextJS as a frontend with somehelpful server-side/api handling, but the backend is done in Django. We are basically just using ReactJS with the convenience of NextJS (like file based routing)

I like Remix a lot better for this use case than Next.js. Much simpler, easier to host on your own servers.

Astro is also really nice and easy to learn and host.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#428

Post by TranquilMarmot »

twodave wrote: post #275
vdfs wrote: post #216

Earlier quoted context omitted.

What did you move to? We've been using NextJS as a frontend with somehelpful server-side/api handling, but the backend is done in Django. We are basically just using ReactJS with the convenience of NextJS (like file based routing)

We have some other projects that are Angular, and NextJS was sort of a proof of concept for us. The goal is to just have one front-end framework for our devs to work with (and keep up to date, ugh!), so we’re folding those deploys back into our Angular family of features.

Have you checked out https://astro.build/ yet? You can drop in any framework where you need it, so if you need to bring along those Angular components you can but you can also lean on React if you need it.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#429

Post by petre »

jjani wrote: post #327
petre wrote: post #316

Earlier quoted context omitted.

They don't want to be subject to app store approval policies, shitty TOS, nor pay Google or Apple a 30% cut. Installing the app is easy, visit the web site, clck the install banner, add to home screen and you're good to go. On the developer side you get to deploy as iften as needed. Yes, the service worker thing is annoying but you possibly don't need it if you have a server backend. It's basically a glirified websit…

> They don't want to be subject to app store approval policies, shitty TOS, nor pay Google or Apple a 30% cut. Installing the app is easy, visit the web site, clck the install banner, add to home screen and you're good to go. On the developer side you get to deploy as iften as needed. And the metrics are saying that people click it?

We don't care about people clicking it as it's not tiktok but an app that complements a certain hardware solution. If you don't have the hardware, you don't need the app.

Re: We fell out of love with Next.js and back in love with Ruby on Rails

#430

Post by TranquilMarmot »

welder wrote: post #344
mattgreenrocks wrote: post #170

Earlier quoted context omitted.

Yep. The ORM situation in JS is not great. There’s no one go-to, and it seems like the question often prompts a patronizing response about how ORMs aren't really necessary. Kysely is really great, but it’s not an ORM. My take: the JS ecosystem tends to avoid abstraction for whatever reason. Example: they don’t believe that their web framework should transparently validate that the form submission has the correct shap…

The go-to is Drizzle

That's funny, I would say the go-to is Prisma. We use it heavily and have not had any issues.
Post reply on HN