8 ms·
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
by afloatboat 2y ago
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 https://youtu.be/v6UvgfSIjQ0
- sandreas 2y agoTry hono.js ;) https://hono.dev/ https://hono.dev/
- hamasho 2y agoYet 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 https://www.wikiwand.com/en/God_object Fix: format
- sandreas 2y agoI 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 2y agoSo 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 2y agoIt 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 https://github.com/sandreas/pure-todo 2: https://github.com/sandreas/m4b-tool https://github.com/sandreas/m4b-tool 3: https://github.com/sandreas/tone https://github.com/sandreas/tone
- bentonnn 2y agoHono 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.
- 0xblinq 2y agoCool, 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.
- PaulHoule 2y ago- 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 2y agoRolling your own auth is like the first big no no in application security. Unless you're an expert, leave it to the experts
- PaulHoule 2y agoExactly. 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.
- zer00eyz 2y ago[flagged]
- throwAGIway 2y agoNot implementing auth doesn't mean using platforms. Just use any of the many OIDC client/server libraries or completely pre-made open source dockerized services. For example react-oidc-context on the client side and Passport.js on the server, or Casdoor.
- oslonoway 2y agoWhat do you use instead?