r/Frontend

I'm building an internal web app that will benefit from being available as a PWA on users' home screens, but the lack of native installation prompt support (via the beforeinstallprompt event) in iOS browsers is becoming a pain in the neck.

Obviously I can provide a popup with instructions for Safari, but Safari in iOS 26 has three different toolbar layouts that put the share button in different places.

So how do you handle it? Automatic prompts on Android/Chromium, then provide three different sets of instructions for Safari?

Hi I am experiencing a chrome related bug while developing a react app. In Firefox I am not having any issues. When I open a modal in chrome inside my app, the background of a modal looks a bit transparent but when I click at input element inside modal, the background stops being transparent. Modal background should not be transparent at all at any case. Does anyone know what is going on?

I’m curious about how other frontend developers use browser DevTools for CSS work.

Personally, I rely on it a lot. Not only when something is broken, but also while building the UI. I often tweak spacing, colours, font sizes, layout values, responsive behaviour, etc. directly in DevTools before moving the final values back into my code.

For me, it’s become a real part of the development process, not just a debugging tool.

So I’m curious:

Do you mainly use DevTools to debug CSS issues or do you also use it while designing/building the page?

What does your usual process look like when working on CSS in the browser?

Hello everyone,

Wanted to share a super cool project (IMO) we have been working on. It’s a zero-dependency React data grid, called LyteNyte Grid. Check it out, and hopefully, you will find it useful and save yourself a ton of time.

Some of the reasons to use LyteNyte Grid.

• Crazy Performance: LyteNyte Grid is super light at only 40kb (gzipped) and is extremely fast. It can handle millions of rows and 10,000+ updates/sec. Based on our internal benchmarks, it is one of the fastest grids available on the market.

• Feature-rich: Brings 150+ features, most of which are free and open source. Features such as cell range selection, row master-detail, and row grouping are included for free with LyteNyte Grid. This is something we are quite proud of. There are paid libraries (I won't name them) that offer less.

• No Styling Tradeoffs: With LyteNyte Grid, you can choose whether to go headless or styled. There is basically no tradeoff when considering styling choices.

• Full Prop Driven: You can configure it declaratively from your state, whether it’s URL params, server state, Redux, or whatever else you can imagine, meaning zero sync headaches.

• Unique DX Experience: Our grid is built in React for React and has a clean declarative API, which eliminates awkward configuration workarounds.

We also recently dropped LyteNyte Grid AI Skills. This is a really nice feature if you’re using AI coding agents. It lets you describe an advanced data grid solution, and your AI agent codes it for you. We have been testing this with increasingly complex grid instances, and the results have been awesome.

All our code is publicly available on GitHub. Happy to answer any questions you may have.

If you find this helpful and like what we’re building, GitHub stars help. Feature suggestions and code contributions are always welcome.

• GitHub
• Live Demo

I’m new to frontend development. I’ve learned the fundamentals of GSAP and Three.js, and I’ve also tried working with shaders a bit.

Now I want to start building projects on my own, but I don’t know how to proceed. Whenever I try to think about what to build or how to break things down, I just can’t come up with anything.

Feels like I was too dependent in tutorials only while learning and ended up like this.

I feel like I might not be able to create projects on my own right now, and I’m feeling a bit lost.

Can someone help me out. What shall i do?

I'm building the front end for a little web app I'm developing. The backend has fully functional /token and /refresh routes which issue an access token (stored in localstorage) and add a refresh token to HTTP only cookies (rotating refresh tokens on every call to /refresh).

I'm using react for UI and axios for HTTP requests. I implemented an AuthProvider component and useAuth hook which exposes a context other components can use to get the access token or call auth functions (login, logout, etc.).

I'm wondering how I can call the /refresh endpoint whenever one of my authenticated routes returns a 401 error (and pass the new access token back to the AuthProvider) in a way that wraps every one of my API calls so I don't have to rewrite refresh logic in every component that calls an authenticated route.

I'm not great with react or familiar with everything axios has to offer so I'm sure there's some standard way of doing this.

Please let me know if you have any ideas or need more context.

Thanks!

A week ago I posted about ArchUnitTS, my library for enforcing architecture rules in TypeScript projects as unit tests.

A few of you specifically asked whether this could be used to enforce clean Angular feature/module boundaries in real projects: making sure feature modules don’t import directly from each other’s internal files, and instead communicate through public API barrel files like index.ts or public-api.ts.

So to that request I’ve added exactly that.

---

First a mini recap of what ArchUnitTS does:

• Most tools catch style issues, formatting issues, or generic smells.
• ArchUnitTS focuses on structural rules: wrong dependency directions, circular dependencies, naming convention drift, architecture/diagram mismatch, code metrics, and so on.
• You define those rules as tests, run them in Jest/Vitest/Jasmine/Mocha/etc., and they automatically become part of CI/CD.

In other words: ArchUnitTS allows you to enforce your architectural decisions by writing them as simple unit tests.

That matters more than ever in Claude Code / Codex times, because LLMs are great at generating code but they love to violate architectural boundaries, especially when they get stuck.

Repo: https://github.com/LukasNiessen/ArchUnitTS

---

Now what’s new

Exclusion-aware dependency rules for Angular public API boundaries

Before, ArchUnitTS could already enforce internal dependency rules like:

• “components must not depend on infrastructure”
• “core must not depend on shared”
• “feature A must not depend on feature B”
• “folders must be cycle-free”

But one common Angular case was still a bit annoying to express cleanly:

A component in one feature should not import directly from another feature’s internal files.

For example, this should usually be forbidden:

import { OrderService } from '../orders/internal/order.service';
import { OrderCardComponent } from '../orders/components/order-card.component';

But this should be allowed:

import { OrderSummary } from '../orders';
import { PUBLIC_ORDERS_TOKEN } from '../orders/public-api';

This is not technically always a circular dependency.
But it is still architectural coupling.

It means another feature now knows the internal folder structure of orders. If the orders feature reorganizes its components, services, hooks, facades, or models, unrelated features can suddenly break.

So ArchUnitTS now supports except in pattern matchers.

Example:

import { projectFiles } from 'archunit';

it('should consume orders only through its public API', async () => {
  const rule = projectFiles()
    .inPath('src/app/**/*.ts', {
      except: { inPath: 'src/app/orders/**' },
    })
    .shouldNot()
    .dependOnFiles()
    .inFolder('src/app/orders/**', {
      except: ['index.ts', 'public-api.ts'],
    });

  await expect(rule).toPassAsync();
});

This says:

• check all Angular app files
• exclude files inside orders itself, because a module may use its own internals
• forbid other features from depending on files inside orders
• but allow imports through orders/index.ts and orders/public-api.ts

So this fails:

import { OrderService } from '../orders/internal/order.service';

But this passes:

import { OrderSummary } from '../orders';

You can also make the exceptions explicit by target:

.inFolder('src/app/orders/**', {
  except: {
    withName: ['index.ts', 'public-api.ts'],
  },
});

This is especially useful in Angular projects because Angular feature modules often create natural architectural boundaries, but violations tend to accumulate silently over time.

And these imports are very hard to catch in code review because they look like normal TypeScript imports.

Now the boundary can be tested directly.

---

Very curious for any type of feedback! PRs are also highly welcome.

Seniors with extensive experience, in your early days, how did you build web projects in the absence of AI tools? How much time do you spend thinking about solutions of simple or moderate difficulty problems?

Sometimes i feel that traditional learning methods are more useful, cuz you have to spend time searching and learning, work hard until you find solutions، but the information sticks in memory.

Now, when you get stuck, you ask AI tools and get a quick answer, or sometimes even a solution to the problem, but when you encounter the same problem later on, you find yourself unable to remember how to solve it, so you have to ask the AI again, and it never sticks in your memory.

Personally, I started learning programming using JavaScript months ago, I'm trying to build some projects, I'd prefer to have a real mentor to guide and help me, but I didn't get one, so I used AI as a mentor. Sometimes I don't feel like I'm learning because it makes the process too quick for me. I don't feel stuck and forced to search, to achieve some proficiency in learning, is there any beginner here who is like me?

Hi all,

I need some advice on how to approach cleaning and splitting a massive 15,000 lines SCSS setup.

I’m working on a huge React app that has a single 15k line SCSS file built over years. It has everything mixed together -- page styles, shared styles, PrimeReact overrides, utility classes, old legacy code, tons of nested classes, duplicates etc. Some PrimeReact overrides are nested inside random parent classes while others are global.

The naming is also a mess now. Generic classes have been reused in completely unrelated places, so the class names themselves are no longer reliable and refactoring feels risky. I’m also pretty sure there’s a huge amount of dead CSS, but I have no idea how to safely identify it in an app this large.

The project is too big to suddenly rewrite or split into separate SCSS files for every component, so I’m trying to figure out a realistic cleanup strategy without breaking the UI. Splitting page by page doesn't seem a good idea for a huge web application and also is very difficult in this case.

Has anyone dealt with something like this before? How would you start handling it? Any pro please give a guidance for this and how to split and what to take out.

https://preview.redd.it/6bk4k7b22i1h1.jpg?width=1280&format=pjpg&auto=webp&s=ac7bd600340e3992c3298e369de5fbb828a1992b

I’ve been building a small experiment around analyzing websites/screenshots and converting them into structured design system style docs.

Instead of only looking at pixels, it tries to combine:

• visual hierarchy
• DOM inspection
• CSS behavior
• spacing systems
• typography patterns
• component structure

Originally started this while experimenting with browser agents and frontend audits because screenshots alone felt too limiting.

Still improving it daily, but I’d really value feedback from frontend engineers/design engineers here:
What parts would actually be useful?
What feels unnecessary?

here you go - https://designmd.adityaraj.info

Three years using AI tools for frontend development across two very different contexts. One greenfield TypeScript project and one five-year-old production codebase with a custom design system. The quality gap between the two experiences isn't about the AI model. It's about whether the tool knows your codebase.

On the greenfield project the AI tools are excellent. Clean architecture, no internal abstractions, standard libraries throughout. ChatGPT for reasoning through component design, Cursor for implementation. Both work well because there's nothing org-specific to miss.

On the mature codebase it's a different story. Custom design system nobody else uses, internal component abstractions, state management patterns that evolved over time, custom hooks that encode domain logic, naming conventions that reflect a specific product history. Every AI tool we tried suggests the popular public libraries. Material UI components when we have internal equivalents, standard React state patterns when we have established internal ones. The suggestions are correct for some version of TypeScript React. They're wrong for our version.

The AI tools making a real difference on the mature codebase are the ones that build persistent understanding of our specific frontend rather than just knowing frontend in general. That means indexing our component library, learning our hook conventions, understanding the design token system. It takes time to calibrate but the difference in suggestion quality after calibration is significant compared to tools that only see what's in the current context window.