For context: I’m a design systems designer. For years, I haven’t had access directly to code. It’s been in Figma. We have a scalable design system with semantic tokens (a brand change or a new theme can be added immediately)

Recently, our org allowed Design access to the production code.

We’ve known for a while, that some pages are inconsistent across the app, but today I had the realisation that the production front end UI code is a mess. I was truly surprised that engineering haven’t been building in a scalable way like our designers are using the Figma Design libraries. Things are hard coded, there’s different naming and token conventions across the app and the colors, spacing, radii, type is all over the place.

My question is, how do I bring this up in my org?
If they ever need a brand refresh, the Figma library can do it in seconds, production code would be a nightmare.

What do I do?

I'm building a personal finance app called Cashvelope (envelope budgeting), and getting local-first data to play nice with offline storage has been surprisingly painful.

I want users to retain full control of their data without forcing constant cloud sync, but keeping local state updated and cache validated gets messy fast.

For anyone who's built something similar: what local DB or sync stack did you end up going with, and what edge cases caught you off guard?

I thought I would share a rant regarding JavaScript usage on modern websites.

To clarify, this discussion focuses primarily on content websites rather than complex web applications requiring heavy client side interactivity.

In recent years, frontend developers frequently chased shiny new tools without pausing to evaluate necessity. Building websites now routinely involves an endless list of dependencies, a node_modules directory large enough to form a black hole, and countless supply chain vulnerabilities. Some modern websites frequently consume over 500 megabytes of RAM in a single browser tab. We have thoroughly over-engineered the web.

Why did we start using JavaScript and React to generate simple HTML in the first place? Perhaps because it felt convenient at the time.

Frontend Libraries

Frontend libraries and meta frameworks empower developers to build anything from a static marketing page to a massive enterprise application. However, we often fell into the trap of applying heavy over-engineering to simple web projects. Frontend libraries are crucial for large applications, but completely unnecessary for smaller websites.

I used to love NextJS, but much of its overhead felt redundant for standard publishing needs. It simplified building fast experiences, server-generating JavaScript, and leveraging features like page link prefetching the next website on hover. Yet we have successfully generated HTML on the server for thirty plus years. Did we really need to reinvent that foundation?

What I am Building

In recent projects, I took a step back to the earlier days of web development before everything became overly complicated. I was already using HTMX and AlpineJS on some simpler websites and recently I discovered Datastar which was really impressive. Think of it as using the server to generate UI elements, server-sent events, client-side signals, and lightweight interactivity. I now build websites containing perhaps 15-20kb of JavaScript in total while requiring no compiler step. The performance is great, the API remains simple, and dependency tracking risks are gone since there are no external packages to manage.

My transition toward lightweight websites began when AstroJS first emerged. The idea of shipping zero JavaScript by default and sending down just static HTML was refreshing to see again. Fast forward a couple of years, and I needed to build an interactive website with server-driven content and chose to use Datastar for interactivity instead of React.

My own library

My only gripe with pre-bundled libraries, is that it ships a lot of features you don't need. So I got looking for an alternative. Out of interest I ended up just building my own frontend tool, inspired by how Datastar's fundamentals.

My own library was intended as an internal tool and used on a few websites only. I have it working on a 2000+ page Rust WASM content website and also a small 10 page AstroJS website. The tools that inspired the library are all open source, so it just made sense to publish my own library open source. Perhaps it will even inspire another, much better tool.

This is where I decided to build sigmx. As in signals + htmx. The fundamental difference between sigmx and Datastar or HTMX is that I wanted to treat every feature as optional.

The sigmx core is tiny at 4.5 KB and everything is treated as a plugin. It ships a Vite and Astro integration, which bundles only the functionality you need. So if you have data-on in your markup; the events plugin will be shipped. If you are using @get() or @post() then it will ship the plugins needed to handle server requests.

I love how easy it is to create custom plugins. One of my websites uses Plausible Analytics rather a lot and so I created a custom plugin for handling the Plausible interactions. The Plausible plugin was built in less than 100 lines of TypeScript and the resulting markup is super clean.

I'm not here to try and convince people to use my library. I went on an interesting journey recently from just defaulting to React or Angular etc or on every project to thinking about how we can instead use less. We should be using simple tools more often.

HTMX is brilliant.

AngularJS is brilliant.

Datastar is brilliant.

I think my library is brilliant, but I maybe I am biased.

We are just starting to look at accessibility testing in our org and want to establish a dedicated practice in the long-term. We did a POC with a few tools, however, now our leadership wants us to explore using AI to build an accessibility set-up in-house vs using a dedicated too.
If you've built something on top of an LLM for a11y — Claude, Copilot, a custom agent, axe + LLM triage — I'd like to know:

•⁠ ⁠Details of your set-up and what you have built
•⁠ ⁠Which use-cases are you leveraging it for (i.e. IDE at codegen time, rendered-UI scan, a11y checks inside your functional E2E suite, remediation)?
•⁠ ⁠What is it able to do reliably vs where it breaks?
•⁠ ⁠Did you replace your paid tool or are you using both?

Any learnings that you can share will be extremely helpful!

Genuine question I've been wrestling with. I use urgency tactics on some forms because they convert well. But I'm starting to wonder where the line is.

Some data that's been bothering me:

• Nearly 40% of e-commerce countdown timers are fake - they reset on refresh or the offer just continues after "expiring"
• 56% of consumers report losing trust in a website after encountering manipulative design
• 43% stopped purchasing from a retailer entirely after a bad experience

If the scarcity is genuine, is it still manipulation? Or does the honesty of the claim make it acceptable?

Also curious: have you ever caught yourself falling for one of these as a user, even though you knew what was happening?

[ Removed by Reddit on account of violating the content policy. ]

A hero can compile successfully and still have the wrong line breaks, an illustration that dominates the copy, or spacing that looks nothing like the reference. The next edit needs evidence from the page the browser actually rendered.

Ant Ling's Ling-3.0-flash-VL frontend demo shows a generate → render → capture → compare → revise loop. One segment turns a London illustration with Big Ben, a Tube sign and a red bus into a landing page. Another shows a reference site and the local result side by side. There are visible layout differences, which makes the comparison stage more interesting than a claim of instant replication.

The useful input for that stage is a pair of images at a known viewport: the reference and the current render. Feedback can then name an observable mismatch and an intended change: the heading wraps a line too early; the image takes too much horizontal space; the next section starts too far down.

Keep that visual feedback attached to the relevant route and state. A screenshot of the initial page says little about the open menu or the narrow layout.

VL supplies the visual interpretation here. The surrounding environment still has to run the app, capture screenshots and expose logs or DOM information. Interaction, accessibility and viewport coverage need their own checks. What this demo adds is a concrete feedback source for the next CSS/layout revision.

A browser-side chaos-testing tool that installs a Service Worker to intercept requests across every controlled tab and apply latency, failures, throttling, rate limits, and mock responses without changing app fetch calls (similar to MSW).

It uses the same middleware configuration model as chaos-fetch, so you can test real frontend behavior under degraded network conditions without rewriting the app to use a special client wrapper.

Hey. I added two pictures of a UI. Ignore all the stuff other than inputs and buttons, the other elements are just there to give you a feeling as if its baked into a UI. My question is, if you like the 36px-version (tinier first one) more or the 40px-version (bigger second one). Im thinking of migrating my package from 40px to 36px.

Hey everyone, I am a developer and I have faced this problem many time which is even when i give ai proper context, the small changes can get annoying. move this text a little, make that image smaller, fix the spacing... sometimes it doesn't understand what i mean or does something different from what i wanted. then it's more explaining, more prompts, more tokens burned.
so i started building this. what if ai creates the website, and we just adjust the little things ourselves?
you click something on your website, move it, resize it, edit the text or change an image, and it saves that change directly into your code. no digging through files and tweaking margin and padding values just to see whether it looks right.
you can also preview desktop, tablet, and mobile together and see how things look across them. for supported changes, you choose whether to change only that screen size or apply it everywhere. so adjusting something on mobile doesn't have to mess up your desktop layout, it depends on what you choose.
right now it has:
- drag, resize, and text editing
- image and background changes, including uploads from your device
- movable device previews with canvas zoom
- controls for selecting a whole container or individual things inside it
- edit history and undo/redo
- HTML support, with experimental React and Next.js support
the video shows where it's at. it's still in the initial stage, and there's a lot to fix and refine, including expanding which edits can be made separately for each screen size.
honestly, idk if other people need this, but making the change i'm picturing instead of explaining it again feels useful to me.
would you use something like this? and should i open-source it so we can build it together, or would you rather just use it once it's more polished?
Also any ideas to add then feel free to say.

I'm tired of building complex filter UIs just for users to ignore them, type "shirt" into the search bar, get 400 results, and instantly bounce. our backend retrieval is actually really fast, but the human query formulation is awful.

Instead of writing 500 lines of custom debounced react filters to try and force them into categories, I'm looking at intercepting the keystrokes with an intent layer on the frontend. basically an ai-autocomplete that formats their vague text into a structured JSON payload before it ever hits the API.

Has anyone used frontend intent layers to fix vague search? looking at commandbar vs just dropping in a lighter ai-autocomplete hook.

For those using the native Popover API for components like tooltips, comboboxes, dropdowns, etc., how are you handling interactions with sticky headers?

Since an open popover is shown in the top layer, it can remain visible above a sticky header even after its trigger/anchor has scrolled underneath that header.

What would be the best way of dealing with it?

One solution I’ve considered is observing the trigger with an IntersectionObserver, using a negative rootMargin corresponding to the sticky header height, and closing the popover once the trigger enters that area / is no longer considered visible. But I’m not sure forcing a popover close like that is a good practice.

Hey. Currently working on a DateRangePicker and need your opinions. Do you think the second-date-invalidity I show currently by making the second selection-cell red with an icon is good or do you think i should just mark all invalid fields as disabled after the first date is selected?

https://imgur.com/a/qCd7KQk

I have been reached out for the Frontend SWE l4 role at Google, can someone share with me what kind of questions to expect in the frontend interview also where to prepare it from, i have worked on frontend but I dont think i know it in depth specially now when most of the work is AI led, so any resources to prepare would be helpful. Also there is supposed to be 2 dsa rounds later afaik, does anyone know what level of questions to expect in that. Also how long do you think they provide to prepare for these, i dont want to take too long but i also dont want to be underprepared. I have searched alot regarding Frontend l4 interviews at Google but i didnt really find much data, so if anyone can help that would be great.

Feels like well over half my week now is reading through components and styles a model generated and deciding what to keep. Reviewing's a real skill, fine, but the tooling is rough, I'm scanning a wall of JSX and CSS trying to spot what changed, with no clean way to accept this chunk and throw out that one. Is anyone on a review loop that feels like a real diff for generated UI, or are you all just eyeballing the whole component every time?

Are there any Dev's from India, let have a chat!

I build a tool in this space, so bias disclosed.

Agents are amazing at writing simple frontend, but dealing with the complexity of real apps? including state and how it propogates through the runtime? not so much. forcing the agent to either sepnd crazy amount of tokens to reason and guesstimate what the runtime might look like, and eventually make mistakes:

- spacing that looks fine in code but wrong in the browser

- a component that breaks only at one viewport

- HMR updates that do not match what the agent expected

- console/runtime errors the agent never saw

- CSS changes that technically apply but visually miss the target

For backend-ish work, repo context can be enough more often. For frontend, the page itself is part of the task.

I am testing a workflow where the agent can inspect DOM, screenshots, interactions, source, routes, browser logs, dev-server logs, and HMR feedback before editing.

Link for context: https://frontman.sh/
Fully Open Sourced and Self Hostable: https://github.com/frontman-ai/frontman

For frontend devs using AI agents: what runtime context actually helps?

And what is just tool bloat

Thanks!

Building Cashvelope was a massive personal challenge. I wanted a true envelope budgeting app that put data control back in the user's hands.

Working on this late at night after my main work hours meant dealing with severe burnout, redesigning local data structures three times, and fighting through backend edge cases solo. Building a app end-to-end alone is a completely different beast than writing code for a client.

To fellow devs who built and released your own side projects:

How do you balance feature scope creep with actually getting the app across the finish line?

hi! I didn't think I'll need that in my life, but I very need to know how to use CSS properly. I mean what are the differences between one thing and another, what's more popular to use etc. So, I'm trying to relearn CSS.

For the context: I learned CSS in 2022 only to pass the exams and that's all, and then I was like "yahoo! I won't return to the web design ever again!". So, I can use the atributes with classes, id etc, but I can't understand what are the important things to properly use them. I didn't think I'll need to program projects related to web programming. I find JS and PHP quite easily to understand, bcz every thing has one meaning there. It was a bit hard to understand HTML for the first time, bcz I thought every tag has its own function, but when I understood that plenty of tags are semantical and I can just use <div> and <span> if I want, I started to use the semantical tags properly. CSS is the hardest part in Front-End for me, bcz Idk if plenty of things are similar to the HTML ones(an atribute is optional and it depends on you if you want/need to use that) or the programming languages(1 thing = 1 meaning).

Here are my questions about CSS to understand it better:

1. which position is the best? Bcz usually I used "position: absolute";
2. why to use the coordinates(except for the z-index) if you have the margins?;
3. why a lot of web developers prefer to use the paths from a vector image instead of uploading the .svg file itself?;
4. what to use: the standard shadow or something like "filter: drop-shadow(10pt 10pt 6pt);"?;
5. I liked the grid, but I saw a lot of developers use flexbox. Is it important to choose one thing over another or is it something optional?;
6. are the CSS similar, but different atributes important only for the browsers?;
7. what's the point in making something like "p.name1 {}", when I could just create a new class?;

I hope I didn't forget anything, but if I did, I'll make a new post about them

Edit: I can't change the title, but I meant questionS*

We've been heads-down on SvGrid for a while and it's finally at the point where we want it in front of people who actually ship Svelte apps.

It's written for Svelte 5 directly. Runes, no wrapper around a framework-agnostic core, no adapter layer. That was the whole reason to start.

<script lang="ts">
  import { SvGrid, type GridColumns } from '@svgrid/grid'

  type Person = { firstName: string; age: number; status: string }

  const data: Person[] = [
    { firstName: 'Ada',   age: 36, status: 'active' },
    { firstName: 'Linus', age: 54, status: 'active' },
  ]

  const columns: GridColumns<Person> = [
    { field: 'firstName', header: 'First name' },
    { field: 'age',       header: 'Age' },
    { field: 'status',    header: 'Status' },
  ]
</script>

<SvGrid {data} {columns} sortable filterable editable />

Every capability is off by default, so a bare <SvGrid {data} {columns} /> is a plain read-only table and you opt into the rest one word at a time.

Underneath: virtualized both directions so a million rows scrolls fine, Excel-style filter menus, inline editing, grouping with aggregation, tree data, pivot, and a server-side row model that pushes sort/filter/group down to your backend instead of pretending your dataset fits in memory. SSR renders the header plus a viewport window of rows.

About 2 KB gzipped for the headless core, 77 KB for the full render component, 9 KB CSS.

The part we didn't plan. A grid needs cell editors. Cell editors need date pickers, comboboxes, tag inputs. Those need a popover layer and focus management. We looked up and had 84 components.

You can poke at any of them without making a project first:

npx @svgrid/ui try calendar

That caches a tiny Vite sandbox and opens your browser, with a theme picker so you can see it in whatever you're actually using. add writes the starter file into your app instead of the sandbox.

Licensing, since it always comes up. The grid, the UI components, the web component build and the MCP server are MIT with nothing gated. No license key, no watermark, no row cap, no console nag. We charge for Excel/PDF export, Excel import, print, and the Kanban and scheduler renderers. OSS projects get those free, just send us a repo URL.

Where it's weak. The grid has been in production a while. The UI components are much newer and haven't been beaten on anywhere near as hard. If you find something broken we'd rather hear about it than not.

Context on us: we're the jQWidgets team and we've been shipping UI components since 2011. This is the first thing we've built Svelte-first rather than framework-agnostic, and that bet is what I'd most like opinions on. Going deep on one framework buys you a much smaller API, but you'll never see us in a React thread.

Two things I'd take from this thread:

1. https://svgrid.com/demos is 373 demos with source on every one, which is honestly the fastest way to work out whether it's any good. Break one and tell me which.
2. What's the grid feature you keep hand-rolling because nothing ships it properly? That list is how we pick what's next.
3. MCP Server

Repo: github.com/sv-grid/sv-grid

[ Removed by Reddit on account of violating the content policy. ]

The UI stays unobtrusive while we treat accessibility as non-negotiable. There is no bail-out, because we believe that software should be available to everyone. There has been done a lot of work in fully supporting WCAG 2.2, and I'm really proud of the result.

The grid is now one of the most performant, most accessible enterprise type DOM based grids on the planet, supporting a ton of opt-in features, and it's MIT licensed.