[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

[darby_nine]

Absolutely disagree. You shouldn't roll your own bcrypt, but you should have full knowledge of how it's used to offer authentication. Hell this is required to even move forward with sales in many enterprise software contexts. If you don't know how passwords work, for the love of god don't offer password-based login.

[PaulHoule]

Exactly. It is not the implementation of the auth module that matters to me so much as is the API through which it slots into the rest of the system. I want the expert designed modules that I can plug various systems into.

Because we haven’t seen good frameworks at the user management level, I think, the mistakes made by the creators of that YT video are common in the industry.

[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.

[oslonoway]

What do you recommend?

[sandreas]

inertia.js is his choice (see his comments). Not bad actually.

As I already said: My comment was not meant totally serious, I also hate this framework hopping... although hono.js is promising.

[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

[bentonnn]

Hono is great, the context object is really just a collection of helper methods for returning responses, a way to store values through the lifetime of the request, and the Req and Res objects. I understand the concern but I wouldn't let that stop you from trying it out.

[sandreas]

I was not totally serious about it. My hunt for the next best framework is over... I tend to use vanilla JS for my pet projects and for more serious stuff I use whatever I find interesting or what the project uses :-)

[0xblinq]

So instead of using battle proven frameworks (such as Laravel, rails, Django, etc) you just invent your own?

Doesn’t sound like a great idea to me.

[sandreas]

It depends. If its something like my personal todo list pure-todo [1], I tend to write it down in less than a week without using any frameworks and hardly ever touch it again.

If it's something like m4b-tool[2] or tone [3], that has to be maintained for a while, I tend to use battle proven libraries or frameworks (in this case Symfony, because it is an older project and Spectre.Console and atldotnet for tone). I prefer libraries over frameworks though, less background magic.

However, I have the feeling that you also find something in this comment that you don't like - maybe the shameless advertisement of my FOSS projects ;-)

1: https://github.com/sandreas/pure-todo

2: https://github.com/sandreas/m4b-tool

3: https://github.com/sandreas/tone

[oslonoway]

What do you use instead?