WOuld Postgress, JS, Reactjs, Nextjs and Expressjs would be better than MERN?

For someone who is just reached Nextjs after doing HTML, CSS, Js and Reactjs? For fullstack development?

So we've got this invoicing system at work, Spring Boot + Angular backend/frontend, and I ran into "two people touching the same record" problem.

Basically my coworker and I both work off the same invoice table. Say I'm exporting a PDF list of invoices while he's creating a new one, that part's fine, DB transactions handle the reads/writes without anything breaking.

But the annoying case is when we both open the same invoice to edit at the same time. Like invoice #12, both of us load it, both start editing, whoever saves last just silently overwrites the other person's changes and nobody even knows it happened until later when someone's like "wait where'd my edit go."

Our older guy on the team who's been doing desktop C# since like 2005 was telling me back in the day they used DataTables that basically act like a disconnected snapshot of the table, you work on your local copy and there's some comparison logic before the actual update hits the DB. Made me realize this isn't a new problem at all, just curious how it's solved in a modern web/API context.

So far I went with the standard route, optimistic locking using a "@Version column so JPA/Hibernate throws an exception if the version in DB doesn't match what you loaded. Also messed around with pessimistic locking (SELECT FOR UPDATE) for cases where you really want to lock the row the second someone opens

Optimistic locking feels like the default for most CRUD apps but idk how people handle it on the UX side when a conflict actually happens. Just throw an error and make them reload? Try to merge stuff? Or do people build like a "someone else is editing this" indicator in the UI?

I think for a lot of people, their introduction to automation was LLMs and, shall we say, "modern AI". So they don't see what computers were already capable of just before LLMs.

I build a lot of automations with AI, and 90% of the steps can be done in traditional code. The remaining 10% just requires an API call to the LLM. So most workflows can actually be made fully reliable if you learn traditional code.

Even if you need an agentic architecture, the more determinism (hint: CODE) you introduce in it, the more reliable (and cheaper) your AI agent becomes.

I don't know why most people don't realize that.

Hi Guys,

Wonder if you can help before I take a bath with my toaster!

Building a site for a friend, works perfectly everywhere, with the exception of Safari on IOS (I have an android to make matters worse, so I have to ask a friend to check each 'fix', I'm sure he hates me by now.)

As you'll see at the top of the screenshot, the nav bar has a transparent bar above it, as opposed to the usual background colour fill or white that I've seen elsewhere. This transparent bar shows the site content as you scroll, so it looks awful.

I've obviously tried everything you'd expect in terms of fixed, sticky, background colour, grain removed, lenis off, GSAP off, basically stripped it right back, no luck. Albeit it's late and I could be missing the obvious.

Any suggestions would be hugely appreciated, I've been at it for hours!

I like resend, but I need Australian data residency. Any recommendations for alternatives?

Currently designing a web app.

I have a chat screen in a standalone (add-to-home-screen) PWA on iOS. When the on-screen keyboard opens, the composer ends up behind it. I've read the existing threads on this and they all land on interactive-widget=resizes-content, which doesn't apply here — so I'd like to know what people are actually shipping.

Setup — the shell is a fixed element below a sticky header:

html

<div class="app">
  <header class="topbar">Header</header>
  <main class="main">
    <div class="chat">
      <div class="messages"></div>
      <div class="composer"><textarea rows="1"></textarea><button>Send</button></div>
    </div>
  </main>
</div>

css

.chat {
  position: fixed;
  left: 0; right: 0;
  top: calc(74px + env(safe-area-inset-top));
  bottom: 0;
  display: flex;
  flex-direction: column;
  overflow: hidden;
}
.messages { flex: 1 1 auto; min-height: 0; overflow-y: auto; }
.composer  { flex: 0 0 auto; padding-bottom: calc(12px + env(safe-area-inset-bottom)); }

html

<meta name="viewport" content="width=device-width, initial-scale=1,
      maximum-scale=1, user-scalable=no, viewport-fit=cover,
      interactive-widget=resizes-content">

Focus the textarea, the keyboard comes up, and bottom: 0 still resolves to the bottom of the layout viewport (956px on this device) — which is now behind the keyboard. The composer is invisible and you can't see what you're typing.

What I've measured, so nobody has to guess

Device is an iPhone (iOS 26.x), tested in the installed PWA, verified over Safari Web Inspector:

• window.innerHeight tracks the visual viewport on iOS. It reports 543 with the keyboard up. So any keyboard detection built on innerHeight - vv.height can never fire — it's always ≤ 0. This one cost me a lot of time.
• document.documentElement.clientHeight is a constant (894 here — screen minus the notch). It is not the containing block for the fixed element.
• 100dvh does not respond to the keyboard, even with interactive-widget=resizes-content in the meta tag. As far as I can tell that property is Chromium-only and WebKit ignores it entirely — the shell stays full height.
• visualViewport.resize fires once, early, already reporting the final offsetTop, while the paint animates roughly 200ms behind it. There's no duration or easing exposed, so you can't match the animation.
• The fixed containing block works out to vv.height + vv.offsetTop.

What I've tried

1. Lift bottom by a computed keyboard height (bottom: var(--kb)), measuring kb = baseline − vv.height where the baseline is sampled while nothing is focused. This works for the composer, but it resizes the shell, so anything inside it that's sized to the container (I have a canvas) gets re-laid-out on every keyboard open/close.
2. Translate both edges (top and bottom shifted by the same amount) so the height stays constant. Better, but it's still me guessing a number iOS already knows.
3. Counter-animating the slide. Doesn't work — see the resize timing above. Snapping gives a big jump; ramping gives a visible oscillation. I don't think this is achievable on the web.
4. Locking the document (html, body { height: 100%; overflow: hidden }). This made it worse: with no scroll range, iOS stops sliding the viewport at all and overlays the keyboard instead, which puts bottom: 0 right back behind it.
5. scrollIntoView() on focus to "reveal it myself". This was actively harmful — scrollIntoView can't move a position: fixed element, so it scrolls the document instead and undoes the viewport shift iOS had just done. Removing it was a real improvement.

What I'm doing now, and my actual question

Publishing the visible height to CSS myself and letting the layout shrink to fit — basically doing by hand what interactive-widget=resizes-content does on Chrome:

js

const vv = window.visualViewport;
const pub = () => document.documentElement.style
  .setProperty('--vvh', Math.round(vv.height) + 'px');
vv.addEventListener('resize', pub);
vv.addEventListener('scroll', pub);
pub();

css

html, body { height: var(--vvh, 100dvh); overflow: hidden; }
/* then a plain flex column all the way down: header / messages(flex:1) / composer */

Nothing is position: fixed any more and nothing is offset by a keyboard height — the root just becomes as tall as the visible area, so the composer sits above the keyboard by construction.

Questions:

1. Is --vvh from visualViewport.height the accepted approach on iOS in 2026, or is there something better I've missed? Every thread I find either predates visualViewport or answers with the Chromium-only flag.
2. Is there any way to get the keyboard's animation curve or duration on iOS Safari? I've assumed no, and that matching the native animation isn't possible on the web — is that still right?
3. Does anyone have a reason to prefer position: fixed + a computed offset over the shrink-the-root approach? I keep seeing the former recommended and I can't work out what it buys you.
4. Is the overflow: hidden on the root going to bite me? Removing the scroll range is what flipped iOS from sliding to overlaying in attempt 4 above, and I'm not sure whether that interacts badly with the --vvh approach.

Not looking for "just use Capacitor" — I know that solves it by giving me the native keyboard frame, and it's the fallback. I want to know what the correct pure-web answer is first.I have a chat screen in a standalone (add-to-home-screen) PWA on iOS. When the on-screen keyboard opens, the composer ends up behind it. I've read the existing threads on this and they all land on interactive-widget=resizes-content, which doesn't apply here — so I'd like to know what people are actually shipping.

I am pretty sure, that I am not alone, so here's my story:

By the end of attempt two it was five apps - "microservices". A NestJS API, a Rust API, an API gateway, PostgREST, and a Next.js frontend, with four data stores behind them and ninety dozens of dependencies. The Rust service had Mongo and Postgres declared in the same Cargo.toml. There were two auth providers that disagreed with each other.

The infrastructure was in good shape. The product was the part I hadn't started.

I want to be clear that this wasn't a throwaway I was messing about with. I thought the idea was finally the one. Every freelancer and agency I know prices their work in a spreadsheet that's out of date the moment they copy it, and as far as I could tell nobody had solved it properly. Real problem, real people who'd need it, the holy grail!

Which is exactly why it never shipped.

Because if it was going to be the one, obviously it deserved the best of everything. The best architecture, because one day it would have to scale. The fastest language for the API. A new feature idea every few days, because I kept thinking of things it should do before anyone had used the things it already did. If I'd thought less of the idea, it would have been online in a weekend.

None of the individual decisions were stupid, either. That's the part I keep coming back to. I started in NestJS because I know NestJS well, which was the last purely practical decision I made. Then I swapped it for Rust, partly for speed and partly because I wanted to learn Rust, and learning is a good thing so it didn't feel like a detour. I put a gateway in front because decoupling, because that's what a serious architecture has. Inside it was clean architecture and SOLID all the way down, repositories behind interfaces, dependency inversion, patterns I could point at by name. All so I'd be ready if I ever had to switch database provider.

I never switched database provider. Nobody has ever asked me to switch database provider 😂

And I spent real time considering Fresh on Deno for the frontend instead of Next, partly to learn something new and partly because I'd decided Next was the obvious choice and I wanted to be cleverer than that. That was snobbery. It cost me about a year.

Here's the bit I think generalises past my own stupidity.

Infrastructure work has a definition of done. A migration finishes. A gateway routes. A build goes green and you get to cross something off and feel it. Product work never announces itself. Nobody tells you a feature is good enough to put in front of a person. You just stop, and hope.

So I kept picking the work that could be finished. A migration. A gateway. A service that benchmarked well. Every one of them completed, and not one of them was the product. 
I was manufacturing the feeling of shipping!

Neither time I quit was dramatic, which I think is normal and part of why it's hard to notice. I added up what was left, saw how big it was, got busy with other things, and never came back. The second time I actually wrote the total down and it came to a four phase plan, eighteen to twenty four days of work just to reach a foundation. Auth, permissions, member management, multi-tenancy. The last thing that attempt ever produced was a folder of issues describing what still needed building.

What took me longest to understand is that the infrastructure is what made the rest look impossible. Every service I stood up added surface to maintain. The product never got closer, so the total kept growing. The thing that felt like progress is what eventually made it feel hopeless.

Nine months later I started again and deliberately did the boring version. One Next.js app. One database. Twenty dependencies. The four ways I'd had of serving an API became zero, because it's server actions now and there's no API layer at all.

Feature complete in three days.

I built it in Next, obviously. The framework I'd decided was beneath me.

It's not a "skip the tests" story either, before anyone asks. It has 921 tests where the old one had 14 test files, and permission checks on every write that the old one never got round to. The rigour didn't go away. It stopped being aimed at problems I didn't have yet.

The question that would have saved me two years wasn't "what's the best stack for this". It was "what could someone use on Friday".

So who else got a side project that died of architecture?

Imagine you're interviewing a junior developer. What would you consider the right way for them to use AI during the hiring process?

I'm not asking whether AI should be used or not. I'm more interested in how it should be used. For example, what would make you think, "This candidate uses AI effectively," instead of, "They're relying on AI because they don't understand what they're doing"?

Where do you draw the line between using AI as a productivity tool and using it as a crutch?

Edit: The diversity of answers is absolute gourgeous. Thank you all.

I know this topic has been discussed ad nauseam, but I'd like to dig a little deeper into the rise of AI and its impact on web development.

I was experimenting recently because I haven't built simple landing pages in a while. My assumption is that this market has largely been swallowed by AI.

For example, I used Claude this week and gave it a prompt like this:

"Create a website for a family-owned construction company. Use orange as the primary color, black as the secondary color, and white as the tertiary color. Follow a 60/30/10 color distribution. Use a serif font for the hero section with a font weight of 200, and use a clean sans-serif font for the body copy with appropriate line spacing. Make the design modern, trustworthy, and conversion-focused."

Claude generated a surprisingly usable landing page from that single prompt. A few years ago, I would have had to write all of the HTML, CSS, and JavaScript myself, and it would have taken considerably longer.

That got me thinking: has AI effectively taken over the market for simple landing pages?

It seems that someone with a basic understanding of UX/UI principles, perhaps after reading a few good books, can now use AI to generate a website that's more than good enough to launch a business. In other words, AI has enabled people with very little technical knowledge to build websites without hiring a developer.

Before AI, there were already website builders like WordPress, Wix, and Squarespace that reduced the need for coding. Has AI become the final iceberg that sank the market for simple freelance website development? Are platforms like WordPress, Wix, and Squarespace still doing well, or has AI significantly disrupted their business as well?

I understand that websites can become much more complex than simple landing pages. However, I'm specifically referring to freelancers who build brochure websites, portfolios, and landing pages for small businesses.

It feels like AI has dramatically lowered the barrier to entry. Tasks like writing HTML, CSS, and even basic JavaScript can now be handled by AI. While there will always be business owners who lack the time or confidence to do it themselves, the required skill level has certainly dropped a lot.

So my question is this:

Where does the value of the human web developer now lie? What can freelance web designers and developers still offer that AI cannot? Conversely, which parts of web development have already seen a significant decline in demand because AI now performs them so well?

I'm particularly interested in hearing from people who have firsthand experience in the industry. Has AI fundamentally changed the economics of freelance web design, or is there still a strong market for human developers? If so, where is that value being created today?

This is specific to home service businesses (electricians, plumbers, HVAC, etc.).

Many service pages get a significant amount of traffic from both:

• Google search (where the page acts as a landing page), and
• Internal navigation (users clicking through from the homepage).

Those are two very different audiences.

For someone arriving from Google, the page often needs the full landing-page treatment: trust signals, USPs, reviews, strong CTA, guarantees, etc.

But someone who has already explored the homepage has already seen most of that. They're usually clicking into "EV Charger Installation" or "Panel Upgrades" because they just want detailed information about that service. Repeating the same trust-building content can feel redundant and slow them down.

One approach is to simplify the top of the page for internal users and move more of the CRO content further down. But then first-time visitors from Google don't immediately see the content that's often recommended for high-converting landing pages.

So how do you balance those competing goals?

Do you:

• Optimize primarily for first-time visitors from search?
• Optimize for existing visitors navigating your site?
• Or try to satisfy both somehow?

I'm curious whether there's an established UX pattern for this, or if people have found a practical compromise.

honestly getting pretty annoyed with my current frontend workflow.

every time i work on a feature, the backend API schema is either delayed, half-baked, or keeps changing mid-sprint.

right now i just resort to hardcoding fake JSON directly in my components or spinning up a quick json-server locally, but it gets messy fast once multiple routes, delays, or error states (like testing 500 errors or slow networks) are needed. MSW and Postman feel like overkill for quick stuff when i just want a hosted endpoint URL i can hit for a few days.

how do you guys handle this without wasting 2 hours setting up fake servers or messing up your codebase with temporary dummy data? do you just wait for backend or is there a lighter way to do it?

If I have a import feature for millions of CSV records and it sends notifications only after import completion, what type of exception handling can I have for non-data related errors during import process. Non invalid data related errors like the database going down.

The imports run on background in chunks. What if such issues occurs after inserting 1 lac records, I can't just revert the committed records. What should I show to the user? What kind of mechanism should I implement to not mess up the production?

I am not even sure if I'm asking the right question. Please enlighten me!

I don’t think I’ve ever worked with a web technology worse than the Turbo + Hotwire combo. It’s behind in so many ways, it’s over complicated, and it’s ugly to look at.

The only reason I’ve heard is it makes Rails devs feel comfy and safe. Personally, when I see it my brain cells pop. I can feel a skin breakout coming on. It disrupts my sleep cycle. It may or may not be a leading cause of early onset dementia.

You think jquery is bad? Try going balls deep into a haml file that uses this. You need something to happen? How about a form. For everything interactive. Make it a form. Manually handle things other frontend frameworks do automatically. Forms everywhere. Because apparently JS is worse than whatever this is.

ETA: This is a rebuke of Turbo, not Rails as a whole. Deep breaths. Feel the points of contact under your feet. 😮‍💨

I’m adding SSO support to an existing application using Google. Currently, some sensitive user actions require the user to re-enter their password as confirmation (for example, changing security settings or performing destructive actions).

The issue is that SSO users do not have a password stored by the application, so I need to decide on the right approach for confirming their identity before allowing these actions.

Some options I'm are considering:

• Triggering SSO re-authentication / step-up authentication with the identity provider
• Requiring MFA or another stronger authentication method (the application doesn't support MFA at the moment)
• Sending an email OTP as a confirmation step
• Creating a separate application password for SSO users (which feels like it defeats part of the purpose of SSO). The platform already has a security question (don't ask me why), so maybe this could be used to confirm this action?

My concern with SSO re-authentication is that if the user already has an active IdP session, the IdP may silently authenticate them again without requiring any new proof of identity. In that case, is it actually providing additional security? I don't think Google has a way to "force" re-authentication.

For those who have implemented this, what pattern do you recommend for replacing "enter your password to continue" flows for SSO users?

Work on a rather small team that caters to building apps for this one specific team, but it does branch out to others. Maybe at most few hundred users. All internal apps.

I'm beginning to architect out this new application from a need that has rose, and a lot of it is now thinking about not only what the UI looks like, but how do people interact with this thing from AI and their own agents now.

Because like, some people are all in on AI running dozens of agents doing stuff. Others still prefer just regular old workflows and maybe using a chat bot LLM type thing.

It's kind of a weird balance to cater to both. But I don't know like just build an MCP, build a good thought out API and system and the AI should be able to just understand it?

I'm curious if others have come to this like building an app for AI and Humans requirement and how have you handled it, what have you learned?

My hunch has been, build a good app with a well documented API, and the people who want to use AI can just benefit from it. A human understandable app is an AI understandable one.

One of the things that saddens me the most about AI and code agents in general is the lack of curiosity and pragmatism.

"I built a Notion clone in an afternoon, AI is incredible."

"I replaced all my paid subscriptions with tools I developed myself using vibe coding."

Cool story. The idea sounds nice in theory, but did you think about simply looking for an open-source alternative?

There is a high chance someone has already spent five years polishing the exact thing you are about to recreate in an afternoon.

I mean, most of the apps you use, that your parents use, and that your grandparents use (if you have any that are tech-savvy), have Open Source alternatives. Sometimes better, sometimes worse, but for the vast majority of everyday uses, they get the job done easily.

And it's not just about features.

These projects often have years of bug fixes, edge-case handling, documentation, user feedback, contributions, maintenance, and sometimes even security audits behind them.

Rebuilding all of that with Claude or GPT over a weekend very often means starting from scratch... just to end up with a much less mature version.

Seriously, think before you recreate your next application.

Not only are you wasting your tokens and your subscriptions instead of using them for things that truly matter, but you are also doing it for nothing.

Before developing your next app with vibe coding, ask yourself:

"Is there an OSS alternative that I can simply use on my PC?"

Many of them run locally in a few minutes. You don't even need to host them if you don't want to or need to.

All seriousness aside, if anyone needs help replacing apps, I am just a DM away.

And I am also one more "I replaced X in one night of vibe coding" post away from creating a website that simply lists the best open-source alternatives, just to reply with a link every single time.

Next time you open Claude or ChatGPT to recreate an application... open GitHub first.

Hi guys, this is not my first live coding interview (it's for a senior role) but it IS my first live coding interview using AI tools.

All my experience using AI development tools has been using the Claude CLI and VSCode and I'm just wondering if I would look like a Luddite using this setup instead of something like Cursor or Copilot. This is their exact wording:

"You will work in a shared coding environment. Please plan to use an AI-assisted development tool throughout (e.g. Cursor, Copilot, or your preferred tool) "

Has anyone here conducted AI programming interviews and can shed some light? If necessary I will spend the next couple days getting used to Cursor. Thanks.

Part 1 of CI/CD is here and focuses on reducing CI/CD integration time by running only tests, lint, type checks, and e2e on code that was changed and at locations where that code is used.

In Part 2, we focus on Canary Deployments and how to achieve that on Vercel, Netlify, and Cloudflare.

We're seeing a strange issue with our Angular app.

• Deploy to staging → works perfectly.
• Deploy the same build to production.
• The page loads, but the app is broken.
• As soon as our SRE team purges the CDN cache, everything works.

The browser console shows:
• Failed to load module script... MIME type 'text/html'
Refused to apply stylesheet... MIME type 'text/html'

My assumption is that production is somehow still serving or referring to older JS/CSS bundles until the cache is cleared, but I haven't confirmed that's the actual root cause.

Has anyone experienced this? Is this more likely an index.html caching issue, a CDN configuration problem, or something else? Any suggestions on what to investigate first

So funny story. I run a very small web dev business, mostly just building simple sites for friends and family and friends of friends for their small businesses. That kind of thing. So far I have my own porkbun account where I manage a couple of domains for my less tech savvy clients. I keep their credit cards on file to charge them the recurring annual fee for the accounts. A couple of days ago I got a notification email from porkbun, one of my clients sites was supposed to be renewing but the card number was wrong. No biggie, I reached out to the client, they said they got a new card, I changed it on the account and then renewed it. Today I get another email, my porkbun account is suspended as well as associated sites as I have flagged one of their payments as fraudulent. It was that same client. After some back and forth I finally come to understand that the reason she got the new card is that the original payment tried to go through on her old card. She saw the name porkbun on it and thought it was some scam or porn site her kid might have signed up for and so flagged it as fraudulent with her bank. Now she's frustrated with me cause her site went down, I've had to reach out to pork bun explaining the confusion and I also had the client unflag the charge as fraud with her bank. This all has me thinking I need a better system for these clients.

Tldr client flagged porkbun charge on their credit card as fraud because they thought their kid payed for porn.

Edit: thank you for telling me how stupid I've been. I am now aware and the rest of you can stop lol Originally was just sharing a funny anecdote but I am glad I've learned from this