[afloatboat]

We just turned back from Nextjs after a 4 month trial for a new application.

Some issues we ran into:

- The dev environment is too finicky. Full page reloads instead of HMR and random errors after x reloads.

- Cache is a black hole and works differently between dev and production. They’re changing things up now with v15, but this lack of stability is not fun to rely on.

- The file based router has its limitations. For instance: having the language in the URL means your entire tree remounts when the language is changed.

- No clear way to bootstrap specific stuff outside of React

- Portals don’t seem to work on the server.

- very easy to mess up auth stuff. At some point Supabase even put out a YT video [0] where their implementation caused auth to be accidentally cached. There are 3 levels of checks you need to do just to be safe, but this is all very opaque.

For me it also wasn’t clear how to combine client and server state. These patterns haven’t been defined yet and I kept running into hydration issues with no clear solution.

A year after the app router the eco system still feels very much in limbo and brittle.

I also worked with Next as a replacement for Gatsby’s SSR, but quickly discovered that there’s no easy way for Next to just pre generate all responsive image sizes it needs for a static output like Gatsby has. You need to implement a custom loader and rely on something like cloudinary. This is ridiculous for a completely static site.

[0] https://youtu.be/v6UvgfSIjQ0

[PaulHoule]

  - very easy to mess up auth stuff. At some point Supabase even put out a YT    
  video [0] where their implementation caused auth to be accidentally cached. There 
  are 3 levels of checks you need to do just to be safe, but this is all very opaque.

Auth is all you need. It is a non-functional requirement in that your site is non-functional if auth is broken.

In the large it is Yahoo or Google or Facebook buying a site and hooking it up into their entire service but in the small it is "I want an email newsletter script" and instead of messing around with HMR and file-based routing and other inessentials to develop my own, I just pick a best-of-breed application and hook it up to my user database and auth system and I am in business. (Today, without a clean API, I can hack that application to query my user database and be behind my auth module if the tech stack is sufficiently similar to my own at risk of braving whatever inessentials that route entails)

[malfist]

Rolling your own auth is like the first big no no in application security. Unless you're an expert, leave it to the experts

[sandreas]

Try hono.js ;)

https://hono.dev/

[0xblinq]

Cool, let’s bet on another framework which nobody knows where it will be next year, or if it will still exist at all.

At some point people will realize there’s some value on full stack batteries included frameworks that have been around for a long time.

[hamasho]

Yet another JS framework, and it looks great. I've only skimmed the doc, but I already like its simplicity.

But I have a mixed opinion on the big Context object. It may help to write less verbose code, but it can also cause OOP's antipattern God Object[1], even though the context is more of a namespace rather than a big object.

  // Not
  app.get('/hello', (c) => { return c.json({ greet: `Hello ${c.req.params('id')}`)
  // But
  import { jsonResponse } from 'library'
  app.get('/hello', (req) => { return jsonResponse({ greet: `Hello ${req.params('id')}`)

[1] https://www.wikiwand.com/en/God_object

Fix: format

[oslonoway]

What do you use instead?