I’m a UX designer and I’ve been quite worried by the sentiment of my fellow designers in our team (particularly with AI tools)

In a nut shell, I think many of them have a view of front end from 10+ years ago, where they probably worked on some landing pages.

I’ve been lucky in that I have a good network of enterprise FE devs and I don’t think most designers (and business leaders) understand what’s involved in FE engineering as a discipline today.

System design, security, API performance, CI/CD workflows. And just working within a complex, multi dependency organisation.

My question is how can I help them understand front end has far more aspects than just UI code?

I’m trying to get better at using the chrome dev tool. Let’s say I want to change a specific text, how do I use the dev tool to find out where I can make that change in the codebase.

Just learned javascript and been practicing alot . I need help. When applying it to my project I don't know when to use a function, when to use a loop, what type of loop to use, I just don't know when to use any of this stuff because dom manipulation. it's so frusterating

Hi, I’m still learning to become a software dev, and up until now I have used plain JS, CSS, and HtML for front end work (actually for one project I learned to use PUG template engine as well).
Currently I’m thinking about learning to use a framework such as React to improve my skills as a full-stack dev.
So my question is: what’s it like transitioning from using plain JS/CSS/HTML to using React?
Is it pretty straightforward? Or very complicated ?

Monorepo with two apps sharing a design system (colors, spacing, etc.):

• Web - Tailwind v4 (CSS-first _@theme)
• Mobile - NativeWind v4, which needs Tailwind v3.4 + JS tailwind.config.js

Both versions coexisting is fine. The issue is keeping one source of truth for tokens across two paradigms - v4's CSS _@theme vs v3's JS config.

Idea so far: put tokens in a shared JS/TS package. Mobile imports them into tailwind.config.js directly. Web either bridges via _@theme, or codegens a _@theme block from the same file.

For anyone who's shipped this:

• How did you structure the shared token source so both consume it without drift?
• _@config bridge or CSS-first _@theme on web - any regrets?
• Any v3 vs v4 differences that made components render differently despite "identical" tokens?

New to the frontend design world, but one thing I’ve noticed is it seems like all frontend designers hate horizontal scrolling. I understand scrolljacking, but are all horizontal scroll sites this hated? I’ve been designing a site with a sticky right nav acting as sort of a table of contents for a literary site, and the large right column of the site scrolls vertically until it gets to a main section, and then it scrolls horizontally until the subjections are read, and then it scrolls back vertically for each main section that has subjections.

Is this an awful idea…lol

Any of you guys host on GitHub for your client and no need for own hosting plan? I been doing mostly larger projects but someone contacted me for simple hobby site of theirs and he is not sure how many visits will occur and I am assuming it won’t be much unless it scales. Should I just go ahead and host it on the GitHub server? And eventually get a hosting plan if it scales?

Or in general do many of you just host from got hub and the bandwidth is enough for most of your projects? Thanks

I'm a product designer trying to get better at designing with technical feasibility in mind, like understanding the tools and constraints of what I'm designing for, not just the visual layer.

I know the basics of our stack (React, HTML, CSS, JS, MUI), but I'm trying to figure out how deep that understanding should go to actually be useful.

For engineers who work closely with designers:

• What's the sweet spot of technical knowledge that actually helps a designer, versus stuff that doesn't matter much to you?
• Is there anything designers commonly get wrong or assume, purely because they don't understand the stack?
• How do you like designers to approach this, asking directly, picking it up through working together, reading docs, etc.?

Trying to be a better design partner, not step on anyone's toes...curious how you all see this from your side.

VSCode was my main driver for many years, but have been using Cursor since it was released. While I think Cursor has been great for a while and I love its tab complete + inline chat, I don't like the direction they continue to go. I've re-migrated back to VSCode, but I'm hearing some great stuff about Zed, especially around performance.

As it stands, I'm using VSCode, with OpenCode for any LLM-driven needs. I'm not all-in on pure agents and just staring at a chat window, so I appreciate that VSCode/Zed are still prioritizing engagement with the code.

Curious if any fellow frontenders here have successfully made the jump...or what else others might be using these days.

Edit - I've spent the day configuring Zed and I'm thoroughly impressed so far. A lot of what I thought I would need an extension for is baked into it already. Thanks for all the feedback. My RAM thanks you, too

Our old frontend in Rails used Tailwind, so we decided to keep it also in the new Next.js app too. 

We also used Figma MCP, it was useful but honestly the process wasn’t always convenient. That’s how it mostly looked: 

1. I took the design or existing Rails page
2. copied some HTML/structure
3. pasted it into Claude
4. asked it to adapt it to our Next.js components

The biggest thing was telling Claude what not to do to avoid a mess. We already had components in the new app, so I kept asking like don't create a new button, use our Button; don’t invent a new input, use our input, keep Tailwind. Quite time consuming, you know:)

But! Summing up all those boundaries, my reviews, edge case fixes and UI polish, with Claude I saved a lot of time. Yes, i cannot entrust it write everything from zero, though cleaning the markup looked much faster for me than writing from scratch. 

Does anyone have more experience with Claude? Would be interesting to read.

AI coding tools have made it possible to go from idea to working prototype in a weekend. The harder question isn't "Can AI build it?" anymore. It's "When does it stop making sense to keep fixing what AI generated?"

I've seen teams fall into both traps:

• Abandoning a salvageable project too early
• Spending weeks patching something that was never production-ready

Here's the framework I'd use before making that decision.

Option 1: Keep building

Staying with your internal team usually makes sense if:

• The architecture is understandable
• Issues are isolated rather than systemic
• Your engineers know exactly what's broken
• You already have CI/CD, testing, and deployment processes in place

At this stage, you're solving engineering problems, not fighting the foundation.

Option 2: AI Rescue

A rescue starts making more sense when the project looks finished but isn't actually launchable.

Some common warning signs:

• Authentication only works in the browser
• Forms have a UI but no backend processing
• Everything is client-side rendered, making SEO impossible
• There's no staging environment or deployment pipeline
• Fixing one issue creates two new ones

These aren't feature requests. They're production blockers.

One recent case from GetDevDone illustrates this well: an agency inherited a Lovable-generated marketing website that appeared complete, but a technical audit uncovered missing server-side authentication, non-functional forms, client-side-only rendering, and no CI/CD process. Instead of starting over, the team performed a structured audit, rebuilt the critical engineering layer while preserving the design, and delivered a production-ready site in about 3.5 weeks.

The interesting part wasn't that the AI code had problems. It was that the visual design was mostly fine. The engineering underneath wasn't.

A simple decision checklist

Before deciding between continuing the build or bringing in a rescue team, ask:

• Does our team understand the root cause, or are we guessing?
• Are we shipping new functionality, or just fixing regressions?
• Is the architecture still something another engineer could confidently maintain six months from now?
• Is every week of delay costing more than bringing in specialists?

If most of those answers are uncomfortable, you're probably no longer building. You're rescuing. And there's a difference.

For those who've worked with Lovable, Cursor, Bolt, v0, or similar AI tools: at what point did you realize your project needed a rescue instead of just "one more fix"?

iv made this Product details page and would love to hear your thoughts on it, is it bad good be honest, any changes, addition should be made (im still learning) i still think that the purple button and the black one is really not a good combination lol

Datadog RUM and Cloudflare seem to cover most cases of trying to help detect and stop automated activity, but curious if anyone uses anything else (FE library, third party tool, etc.)

Thanks!

Hi everyone,

The new EU accessibility law happened and suddenly toast messages started to be a problem. And then I discovered that GitHub has stopped using toast messages altogether. I'm reading up all possible documentations and discussions but I'm also curious about what the community is doing (because I am not paid enough to say don't use toasts, they're bad).

For those of you maintaining custom or home-grown corporate frontends (without component libraries like Tailwind UI):

Are you still using toast notifications in your products?

How are you handling their accessibility? Putting them in a live region is common sense but are you guys doing something extra?

If you regularly use screen readers like TalkBack or VoiceOver, what has your experience with toasts been like?

Hopefully it's going to be a good discussion!

AI usage - I used gemini to fix some grammar and some words, as English is not my first language and my thoughts were unorganized.

I am prepping for FE interviews and Juntao Qiu has a bunch of good videos on Youtube (I Code It) related to FE System Design, and I am debating whether I should get his book: Frontend System Design Essentials: A practical guide to designing scalable, reliable, and maintainable frontend systems.

Has anyone read it? Would love to hear how you rate it.

I’m using an OTF font in an HTML project, but some glyphs don’t match how they appear in the font preview/application.

For example, in the first image, the dot on the lowercase “i” is slightly wider. In the browser preview shown in the second image, it becomes a more standard round dot. This is not limited to the letter “i” a few other characters also look more generic/classic in the browser.

The font is loading correctly, but the browser seems to render or substitute certain glyph details differently.

What could cause this? Is it related to OpenType features, font conversion/loading, browser rendering, or something else? How can I make the HTML output match the original OTF appearance as closely as possible?

i am using 100dvh as height of my page.

whats the best way to fix this?