I still much, much prefer the page router. The caching model is much simpler. Shame that they hired all the open source react maintainers and now nothing other than Tan stack gets developed.
pjmlp 1 days ago [-]
Same here.
pjmlp 2 days ago [-]
Wishing for the day it stops being the darlings extension framework for SaaS vendors in the MACH ecosystem [0].
At least the whole headless, DXP hype cycle seems to be wanning down, so maybe we get proper SDKs back.
And while we're at it, what about porting Next.js into Next.rs, and remove all that "use nonsense"?
One of the things I liked about Next is that it presented a “unified platform” instead of the fragmented sea of hacks that is web development. Eg. I was initially taken aback by having to use a special component for images but then it made sense when I realized the platform handles image optimization and stuff like that for me.
But over time I lost the ability to reason about my Next code almost completely. Sometimes it’s the caching, sometimes it’s some little arcane code differences that turn my route into an unexpected type. There is some logic behind it, I can respect that, but I no longer have a coherent mental model of what the framework / the platform does.
It feels like the reality that the abstractions are trying to cover is too wild not to break through at places. Which, I guess, is just web. But it’s a pity, it felt good to have a saner, simpler platform to develop for in older versions of Next.
eknkc 2 days ago [-]
I have used next in a pretty large application. Also built decently large things with base react (vite), vue (nuxt). Also small stuff using other platforms.
Next is by far the worst thing ever. Everything is broken in a weird way and the deeper you dig into it deeper it starts biting back. It was the only thing I dreaded maintaining.
Now that LLMs write code, it probably is not be as big of an issue though.
Still would not wish next upon any of my enemies.
pjmlp 2 days ago [-]
Similar experience, started in the page router days.
Nowadays no idea what they are trying to do with it, I rather be dropped into a random Spring or ASP.NET project, or even C, than Next.js.
Sadly it is the new darling of SaaS cloud products as extension SDK and deployment partner, and thus the only way to some consulting gigs.
zoul 2 days ago [-]
I still hope they will get their act together in the latest releases, after all server components were a huge shift with a lot of rough edges to figure out.
pjmlp 2 days ago [-]
Their act together was keeping improving pages router, with api routes for server side code.
The closest any JavaScript framework had come to Java and .NET frameworks, battle tested in production for almost 30 years now.
It has been downhill since app routing was introduced.
zoul 2 days ago [-]
I have had some very nice experiences with the app router, but I see what you mean.
JimDabell 2 days ago [-]
There are some people who see the web as a platform, and some people who see a web browser as a window for zero-install applications to draw into. There have always been people in the latter group who try to abstract everything away, but it does tend to discard pretty much everything that makes the web great.
zoul 2 days ago [-]
A lot of what Next does/did _is_ leaning into web’s strengths. It was Next that made me declare image size beforehand, for example, drastically reducing layout jumps. It also made image optimization almost effortless, greatly improving load times for my websites. The web as a platform is a nice concept I would love to adopt more, but then I need to write some server-side code and I am completely on my own. Pushing the DX around the client/server boundary is one of the things that made Next great for me.
afiori 2 days ago [-]
I feel like solid-js is in a good place to be a platform
greuceanu42069 2 days ago [-]
[dead]
prodigycorp 2 days ago [-]
Hard to call it a "unified platform" when a good portion of the developer base is using pages router despite app router being out for a few years now
2 days ago [-]
prtmnth 2 days ago [-]
I've found Vite + React SPA ( Tanstack Router/Query) with a Nodejs/Fast API to work so simply and so easy to reason about. The entire SSR and caching etc. thing adds a lot of mental overhead.
Not to mention this stack can be deployed literally anywhere with great ease.
Lucasoato 2 days ago [-]
My favorite combo is NextJS with static export and fastapi backend. Last three years I’ve done countless projects like this, now I just go forward with muscle memory.
For python just get SQLModel (that is basically SQLAlchemy + pydantic), alembic, develop in hexagonal architecture (or just follow the advanced architecture pattern with Python book) and that’s it.
For frontend, just go with tailwind, shadcn, tanstack...
Maybe in 10 years people will look at these technologies as I look at Oracle/JEE today, but they are making me so happy.
kristiandupont 2 days ago [-]
Completely agree. I've had to work with NextJS the past three places I've been and I hate it. I get that there are certain use cases where you want SSR, I guess like an e-commerce site where everything is dynamic but the user isn't logged in and you want SEO. But for a regular SPA, running Vite with a simple router (I like https://kyeotic.github.io/raviger/) is orders of magnitude simpler to work with.
samtheprogram 2 days ago [-]
'use cache' works at the function level as well and is very handy to reduce scaling bottlenecks in a pinch.
skrebbel 2 days ago [-]
Wow that’s so gross! Just put a random unassigned string in your function and it changes behavior completely. Bonkers.
pjmlp 1 days ago [-]
Yes, since the whole app router and React Server Components it feels like Perl's magic strings.
Maybe these folks have rediscovered some mod_perl books.
samtheprogram 20 hours ago [-]
It's almost like C has keywords and pragmas for your compiler too. Neat!
It's really not different. This is just backward compatible (e.g. for intellisense). Honestly better than a #define that I have to declare to get a build going in a lesser C compiler (worst case, looking at you Apple).
abelw 1 days ago [-]
It's not random though, and the good old 'use strict' directive also changes the behavior quite a lot.
slopinthebag 2 days ago [-]
who even cares at this point, with LLMs you can just build exactly what you want without needing to worry about all the constraints a framework imposes on you. the benefits of frameworks are mute now, and you just end up with the downsides.
> The live preview SDK works with JavaScript and has optimized integration for any React.js framework (like Next.js). To see the examples for different frameworks, refer to the live preview SDK.
pretty sure any llm from the last 6 months could wire that SDK into whatever custom setup you're running
pjmlp 1 days ago [-]
Sure, but then it is up to you to support, not create support tickets when it borks in production.
slopinthebag 1 days ago [-]
yea but alternatively, i can fix issues and make improvements without waiting for upstream
pjmlp 18 hours ago [-]
If the customer is willing to pay for that, yeah.
Spend project budget delivering features, or supporting in house custom implementation because the product SDK isn't being used for delivery.
slopinthebag 15 hours ago [-]
it's all about tradeoffs, you could also gain a lot by using a targeted custom approach. devs spend a lot of time dealing with managing frameworks and dependancies as well.
ime the hardest thing is convincing people with your mindset. it's completely valid, i understand it and this isn't meant as a criticism. at my company i'm convinced we could be moving about 10x faster by abandoning some previously held notions about best practices related to this. i could be wrong, but i'd like to at least try.
chaostheory 2 days ago [-]
Svelte and its kit are a much better dev experience
egeozcan 2 days ago [-]
Every time next.js ships something new, I remember the cliché xkcd comic of competing standards and smile a little bit.
They have extremely good engineers, but product/feature management can really benefit from some self-reflection :)
cpursley 2 days ago [-]
It’s a shame that the LLMs default to Next when vibe coding instead of something serious like Phoenix. Then again, maybe it’s a good thing - all of the sloppy copies of my saas are complete dumpster fires and only going to slow them down.
desireco42 2 days ago [-]
Shame but also opportunity... These apps will not be good, they will look good and appear to work, but then... they will need to be rewritten.
I am often posting that if you pick Gleam for UI, Rails or Phoenix, which will make your codebase easier to follow and more stable, I will give you discounts.
Imustaskforhelp 2 days ago [-]
Gleam as a language is genuinely underrated for porting.
I had made a Golang htmx + templ codebase and just out of curiosity I ported it onto gleam using an open weights model (glm 5.3)
Although it struggled a little bit first because of learning some parts of gleam but overall after it searched for documentation and learnt some things on its own, it was able to completely rewrite it in just 1/2 very small prompts which is crazy.
I think phoenix can be great as well and I am doing an experiment to try to port it to many functional languages and just testing which language is the best for it but so far I am impressed by gleam!
desireco42 1 days ago [-]
Yeah my agents do spend a little bit more time with it, and I use GLM Flash mostly. Gleam has good error messages which helps a lot. But once they write something it is much more solid.
Imustaskforhelp 1 days ago [-]
Yea, I think that for AI, good error messages might just be worth their weight in gold.
I was just trying to port the same website to elixir and I am finding that there are issues within it and also for some reason the agent got stuck at something and then it started writing elixir within the repl and doing something related to ecto.
In my current experience, contrary to what I would've expected (given that elixir is a more mature language than gleam), gleam is surprisingly better, though I will try to do more tests
Some other thoughts that I am having at the moment is that starting a project in gleam or within sveltekit/astro/solidjs and then porting it to gleam can be great if what you are doing is frontend heavy. AI will take time once to learn gleam but then the rewrite becomes much more solid and personally interesting to me
Looks like I have to learn gleam to see how fun & managable the codebase can be :-D
sergiotapia 2 days ago [-]
Have faith, you can be the change you want to see.
At my new job we needed a robust platform for executives and ops people to vibe code in. I created the project using latest Phoenix and everything works flawlessly. We get so much for free, hosting is peanuts, and iterating is easy for the AIs.
I even have tons of really strong deterministic guardrails for people vibecoding:
Before you commit, run mix precommit and make sure it's green.
Yeah, I’ve got a “mix quality” task that includes that one and the dup one and skill that points at it, keeps the codebase cleaner that I could manually even before llm era. I’ve thought about building something that can detect if helper functions in a module are generic enough to consider refactoring out to an app-wide helper module, that continues to be an annoyance.
2 days ago [-]
2 days ago [-]
yipinwong 2 days ago [-]
[flagged]
soltanov 2 days ago [-]
[flagged]
2 days ago [-]
Rendered at 23:49:32 GMT+0000 (UTC) with Wasmer Edge.
At least the whole headless, DXP hype cycle seems to be wanning down, so maybe we get proper SDKs back.
And while we're at it, what about porting Next.js into Next.rs, and remove all that "use nonsense"?
[0] https://macharchitecture.com/
But over time I lost the ability to reason about my Next code almost completely. Sometimes it’s the caching, sometimes it’s some little arcane code differences that turn my route into an unexpected type. There is some logic behind it, I can respect that, but I no longer have a coherent mental model of what the framework / the platform does.
It feels like the reality that the abstractions are trying to cover is too wild not to break through at places. Which, I guess, is just web. But it’s a pity, it felt good to have a saner, simpler platform to develop for in older versions of Next.
Next is by far the worst thing ever. Everything is broken in a weird way and the deeper you dig into it deeper it starts biting back. It was the only thing I dreaded maintaining.
Now that LLMs write code, it probably is not be as big of an issue though.
Still would not wish next upon any of my enemies.
Nowadays no idea what they are trying to do with it, I rather be dropped into a random Spring or ASP.NET project, or even C, than Next.js.
Sadly it is the new darling of SaaS cloud products as extension SDK and deployment partner, and thus the only way to some consulting gigs.
The closest any JavaScript framework had come to Java and .NET frameworks, battle tested in production for almost 30 years now.
It has been downhill since app routing was introduced.
Not to mention this stack can be deployed literally anywhere with great ease.
For python just get SQLModel (that is basically SQLAlchemy + pydantic), alembic, develop in hexagonal architecture (or just follow the advanced architecture pattern with Python book) and that’s it.
For frontend, just go with tailwind, shadcn, tanstack...
Maybe in 10 years people will look at these technologies as I look at Oracle/JEE today, but they are making me so happy.
Maybe these folks have rediscovered some mod_perl books.
It's really not different. This is just backward compatible (e.g. for intellisense). Honestly better than a #define that I have to declare to get a build going in a lesser C compiler (worst case, looking at you Apple).
https://www.contentful.com/developers/docs/tutorials/preview...
pretty sure any llm from the last 6 months could wire that SDK into whatever custom setup you're running
Spend project budget delivering features, or supporting in house custom implementation because the product SDK isn't being used for delivery.
ime the hardest thing is convincing people with your mindset. it's completely valid, i understand it and this isn't meant as a criticism. at my company i'm convinced we could be moving about 10x faster by abandoning some previously held notions about best practices related to this. i could be wrong, but i'd like to at least try.
They have extremely good engineers, but product/feature management can really benefit from some self-reflection :)
I am often posting that if you pick Gleam for UI, Rails or Phoenix, which will make your codebase easier to follow and more stable, I will give you discounts.
I had made a Golang htmx + templ codebase and just out of curiosity I ported it onto gleam using an open weights model (glm 5.3)
Although it struggled a little bit first because of learning some parts of gleam but overall after it searched for documentation and learnt some things on its own, it was able to completely rewrite it in just 1/2 very small prompts which is crazy.
I think phoenix can be great as well and I am doing an experiment to try to port it to many functional languages and just testing which language is the best for it but so far I am impressed by gleam!
I was just trying to port the same website to elixir and I am finding that there are issues within it and also for some reason the agent got stuck at something and then it started writing elixir within the repl and doing something related to ecto.
In my current experience, contrary to what I would've expected (given that elixir is a more mature language than gleam), gleam is surprisingly better, though I will try to do more tests
Some other thoughts that I am having at the moment is that starting a project in gleam or within sveltekit/astro/solidjs and then porting it to gleam can be great if what you are doing is frontend heavy. AI will take time once to learn gleam but then the rewrite becomes much more solid and personally interesting to me
Looks like I have to learn gleam to see how fun & managable the codebase can be :-D
At my new job we needed a robust platform for executives and ops people to vibe code in. I created the project using latest Phoenix and everything works flawlessly. We get so much for free, hosting is peanuts, and iterating is easy for the AIs.
I even have tons of really strong deterministic guardrails for people vibecoding:
And mix precommit is: Credo has https://github.com/elixir-vibe/ex_slop added to it.It's really great, try it out.