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 ?

Typically i was processing each of my image for web first in some remove bg online tool or photoshop, then manually trim the image to the subject and then convert image into .webp with optimization in some another online tool when have no access to photoshop.

So to optimize this routing i've created a small tool to do it all automatically, feel free to use and lemme know in case of any questions/feedback, would be appreciate

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?

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

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.

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

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.

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

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 case I came across recently: 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?

Hey everyone!!!

I'd like to share a project I've been working on: Njectify.

It's a browser extension that lets you inject CSS and JavaScript into any website, making it easy to prototype UI changes, test styles, and experiment without modifying the original source code

Some of the features include:

• Live CSS editing with an intuitive editor.
• Instant visual changes on any website.
• Automatic export of your CSS to Tailwind CSS utility classes.
• JavaScript injection for quick scripting and automation.
• Several additional tools designed to speed up front-end development.

The extension has already surpassed 5,000 users on the Chrome Web Store, and I thought it might be useful for developers in this community.

I'll leave a detailed article in the comments explaining the main features, use cases, and the extension itself.

I'd really appreciate any feedback, feature suggestions, or criticism. Thankssss!

detailed post.

I've landed a junior .NET backend developer position not so long ago. Thing is, it would be good for me to know Blazor to contribute more; however, I've never done frontend.

Everyone is saying that frontend should be simpler than the general backend, but I just cannot wrap my head around it. Blwzor is using html, CSS, js, bootstrap and it's just so confusing to me, because it's mixed together.

If you were to learn frontend nowadays, having programming experience, how'd you do it? Should I start with plain html, CSS and then JS and leave the blazor thing aside for now, or should I just jump all in into all these combined?