Leerob, thank you for your patience and help on Reddit community! The NextJS gets a lot of criticism these days but you helped a lot of people, with self-hosting NextJs and other tricky questions.
I am not impressed with Next.js or Lee's evangelism (yes, in the religious sense) of their platform. Being forced to develop in Next.js for a major project was the last straw, and convinced me to abandon the Javascript/Typescript/Node.js ecosystem entirely for future web projects (where I have the choice). Dev-fluencers and Next.js evangelists who gish-gallop and provide (non)-responses to serious developer problems with Next.js convinced me that Vercel is building an elaborate cash grab, on the enterprise scale, and securing vendor lock-in for many years to come. Don't tell me that Next.js is easy to deploy in Docker either - it's not, I wrestled with that implementation for months and it was fragile/broken in a way that I suspect a native Vercel-deployment is not.
The current stack I'm using is Django/Python, HTMX, Alpine.js, and TailwindCSS. Yes I know the middle two use Javascript under the hood, there is no way around that for client interactivity. But they do support the HATEOAS principal (https://en.wikipedia.org/wiki/HATEOAS) which has been a breath of fresh air imo. The book "Hypermedia Systems" is also a great way to achieve the mental reset needed to abandon modern web frameworks and go back to things that actually work, in terms of web development.
I'd add, if feature A can't be shipped 10x faster, ask the same question about features B, C, and D and then redo your ROI calculations, before deciding to invest in feature A.
That keeps the team consistently delivering and motivated, and gives you more time to think about feature A. Some features are really important to get right and take the appropriate time, and some are just important to ship. Having that distinction explicit allows the team to maintain good shipping velocity without accruing "high interest" tech debt.
Also there's obviously no single correct ratio here. Newer companies, services, teams, products will probably lean toward shipping fast since architecture is still being defined (and too much architecture could be more detrimental than tech debt / too little architecture, if it doesn't match future requirements), whereas more mature ones will be more willing to sacrifice shipping velocity for better fit with the existing domain model.
This is a good writeup, but the VP learnings/mistakes (#3, 4 and 5) honestly felt pretty amateur mistakes for any leadership position ... even for just a junior managerial role. It's a good thing they were able to learn on the job, but the team could have used a more seasoned leader - or the author could have had more pre-training/coaching.
Only been on a handful of react projects at this point: gatsby, next.js, and remix, in that order.
Gatsby was fine for the time for our static marketing site. Not really good but not painful. Then we started converting our SPA to next.js and a deep seated rage for react began to fester in me.
After being forced to use react at my current job and convincing leadership to go with remix, it turns out I don't hate react THAT much, mostly just next.js. As far as I'm concerned, next.js and vercel are the same and they're both not great.
15 comments
[ 0.19 ms ] story [ 32.6 ms ] threadBut I liked it. Now I'm mad.
The current stack I'm using is Django/Python, HTMX, Alpine.js, and TailwindCSS. Yes I know the middle two use Javascript under the hood, there is no way around that for client interactivity. But they do support the HATEOAS principal (https://en.wikipedia.org/wiki/HATEOAS) which has been a breath of fresh air imo. The book "Hypermedia Systems" is also a great way to achieve the mental reset needed to abandon modern web frameworks and go back to things that actually work, in terms of web development.
That keeps the team consistently delivering and motivated, and gives you more time to think about feature A. Some features are really important to get right and take the appropriate time, and some are just important to ship. Having that distinction explicit allows the team to maintain good shipping velocity without accruing "high interest" tech debt.
Also there's obviously no single correct ratio here. Newer companies, services, teams, products will probably lean toward shipping fast since architecture is still being defined (and too much architecture could be more detrimental than tech debt / too little architecture, if it doesn't match future requirements), whereas more mature ones will be more willing to sacrifice shipping velocity for better fit with the existing domain model.
lol
Gatsby was fine for the time for our static marketing site. Not really good but not painful. Then we started converting our SPA to next.js and a deep seated rage for react began to fester in me.
After being forced to use react at my current job and convincing leadership to go with remix, it turns out I don't hate react THAT much, mostly just next.js. As far as I'm concerned, next.js and vercel are the same and they're both not great.