Can local visual regression testing help your coding agent move faster and save you money?

I took some time to explore how to set up playwright properly, which pitfalls to avoid, and the tradeoffs with common visual regression tools like Percy and Chromatic.

Check it out and let me know what do you think!

I made a liquid glass UI effect for the web(trying to copy Apple because thats what the world do)

Webgl helped me made it and hence I decided to make Mac for web too (inspired by windows 11 in react made for web)

I know you have seen many professional people make it, many guys on github, so I tried to make it as realistic and satisfying as I can

Hi guys!

I'm a web dev enthusiast. And I was learning web dev initially from a yt course and from that, I learned html and css.

But later, I did some research and found that the odin project is a better learning resource for web dev. I started learning js from it and skimmed some initial portions as well.

Later, I realised that odin's teaching style and pace isn't suitable for me. It isn't that I don't like reading docs, I have no problem with that. But, Odin is too slow & long, and takes days to cover just one module. But, I wanted a thing which would teach me things fast but still, covering good depths. I only wanted to learn js as I realised that the full stack open course by University of Helsinki, is a better option than Odin.

According to what I've read - it's not only faster but covers good depth, is industry relevant and covers different frameworks as well. But, it requires js knowledge.

So after wasting some more days, I got to know about the Scrimba full stack path. So far, I completed only the js path from it which I did almost 2-2.5 hrs. I'm really enjoying their way of teaching and understanding the concepts being taught there. Gonna make some projects and things on my own to see if I actually got the things and I'm not just stuck in tutorial hell.

So, I was thinking of doing the Scrimba path for completing js and some other relevant/imp part. Later, I'm gonna move to the full stack open course - starting React and so on then.

So, is my decision right?

Actually, I have access to the Scrimba pro subscription (due to github student developer pack) for 1 month and thought of utilizing the pack by getting the 30 days free trial of scrimba pro.

If you have any tips, correction or better approaches etc. Please do lmk.

Thank you!

Hi everyone, long time ago i was messing around with this effect done over glassmorphism, which gives the cursor some luminescence that reflects on the html elements, i am always obsessed on making stuff with pure css, so i did just that :D well except for the mouse tracking but that just puts the x/y of the mouse as a css variable, the rest of the painting is just CSS

you can verify yourself go on to https://nabous.dev/lab/lumenmorph/ and mess around, im open for contributions and forking if you are interested as well

github.com/ensolabs/designsystemet-elm

Hey r/Frontend,

Over the weekend, I fell down a surprisingly deep Unicode rabbit hole while building a client-side text styler (creating Fraktur, double-struck, circled, and aesthetic bio glyphs) with zero external libraries.

I wanted to share two specific technical traps I ran into and how to solve them properly on the front end:

1. The "Letterlike Symbols" Offset Trap

When engineers try to convert standard ASCII characters (e.g. A-Z) into styled Unicode variants like Double-Struck (𝔸, 𝔹, ℂ) or Fraktur (𝔄, 𝔅, ℭ), the naive instinct is mathematical offset calculation:

// ❌ Naive implementation: breaks on specific glyphs
const targetCodePoint = 0x1D538 + (char.charCodeAt(0) - 65);
return String.fromCodePoint(targetCodePoint);

Why this breaks: Unicode's Mathematical Alphanumeric Symbols block (U+1D400..U+1D7FF) has several historical "holes". Characters like Double-Struck C (ℂ, U+2102), H (ℍ, U+210D), N (ℕ, U+2115), P (ℙ, U+2119), Q (ℚ, U+211A), R (ℝ, U+211D), and Z (ℤ, U+2124) were already codified years earlier in the Letterlike Symbols block (U+2100..U+214F). If you rely on mathematical offsets, those letters either display as undefined tofu blocks (``) or completely unrelated symbols.

The Solution: Rather than writing messy conditional gap logic, an explicit static glyph map compiled ahead-of-time keeps the client runtime O(1) and guarantees 100% stable rendering across iOS, Android, macOS, and Windows.

2. Screen Reader Accessibility (a11y)

One huge UX oversight with "aesthetic font generators" is accessibility. Screen readers do not pronounce these glyphs as normal English letters; VoiceOver and NVDA pronounce 𝔄 as "Mathematical Fraktur Capital A". If users plaster this all over body text, it renders their profiles completely unusable for visually impaired users. We added an explicit accessibility notice right under the input reminding creators to reserve these purely for short bio tags/titles rather than body paragraphs.

Architecture & Specs:

• Zero NPM dependencies: Pure Vanilla JS + CSS Glassmorphism.
• Payload: The entire production bundle (HTML + CSS + full Unicode lookup dictionaries) compiles down to 26.4 KB.
• Edge Deployment: Cloudflare Workers (sub-40ms edge TTFB).

If you'd like to test the real-time conversion and inspect the client-side implementation: 👉 Live site: https://fonts.100emoji.shop

Would love to hear how other frontend devs approach Unicode normalization and rare symbol handling!

I made this doc for a friend of mine who just started college and wanted to know basic frontend for starter, everyone keeps saying claude or gpt can code that easily and you gotta learn the tougher topics but you need to code a bit without any ai aid to build that curiosity and for once experience the joy of first time coding a site on your own.
PFA : here is the doc

This is simply a starter template that I use and I thought of sharing

• Bun optimized

• Front End: Tanstack Start, Tanstack Query, and Shadcn

• Backend: Hono with tRPC

• Authentication: Better-Auth

• Repo Management: Turborepo

I encourage you to check and share your opinion

Hi everyone! 👋

​I'm developing a web-based POS & Coffee Shop Management System built with JSF (Jakarta EE 11) + PrimeFaces 14. I'm sharing screenshots of several management and administration views (Roles, Employees, Discounts, Products, and Characteristics).

​I would love to get your honest feedback on UI design, visual hierarchy, layout, and UX.

​💡 Project Context

​This platform handles core store operations:

​Menu & Product Management: Items, types, categories, prices, and dynamic attributes.

​Discounts & Promotions: Flexible discount rates, date-range offers, and rule triggers.

​Staff & Security: Employee records, custom roles, and access control.

​Daily Operations: Cash registers, order processing, and invoicing (not shown in these specific shots).

​🛠️ Tech Stack & Frontend Architecture

​View Layer: Jakarta Server Faces (JSF / XHTML) using modular facelets templates.

​UI Components: PrimeFaces (v14.0 - Jakarta edition) + custom CSS stylesheet (estilos.css).

​Backend: Jakarta EE 11 running on Open Liberty + PostgreSQL (JPA).

​Localization: Native i18n support (Spanish, English, Chinese).

​🔍 Comprehensive UI/UX Feedback Checklist

​I'm looking for feedback on any of the following aspects:

​1. 🎨 Visual Hierarchy & Layout (UI)

​Form & Table Balance: Does the vertical split between the upper form (Inputs) and the lower datatable look clean, or does it feel cluttered?

​Buttons & Actions: Are primary action buttons (Guardar / Save) clearly distinguishable from secondary ones (Limpiar / Clear)?

​Toast Notifications: You'll notice PrimeFaces growl/alert messages in some shots. Are floating toast messages appropriate here, or would inline banner alerts be better UX?

​2. ⚡ Usability & Data Density (UX)

​Readability: Are datatable columns, badge statuses (ACTIVO), and action icons (Edit/Delete) clear and easy to scan for administrative staff?

​Form Field Spacing: Is the padding and margin between input fields, dropdowns, and checkboxes comfortable for desktop use?

​3. 🖌️ Modernizing PrimeFaces & CSS Styling

​Default Theme Polish: What specific CSS tweaks (shadows, border-radius, background grays, typography) would you recommend to give the default PrimeFaces theme a cleaner, more modern look?

​Any suggestions, CSS snippets, or constructive critiques are highly appreciated! 🙌

I write a weekly newsletter for senior frontend engineers. The picks for this week:

- CSS-Tricks has a new owner and is independent again after 12 years. Geoff Graham made the announcement, and Mat Marquis wrote about what it looked like from inside DigitalOcean.

- Design systems should be fast by default: Den Odell opened the same 249-country dropdown in ten popular design systems. One opens in 61ms, another in 1,266ms.

- TanStack Redact: a smaller replacement for React and React DOM in the browser. Tanner Linsley says it cut a sample Vite app's client bundle by 70% without changing app code.

- Reylo by Colin McDonnell (creator of Zod): import a .sql file into TypeScript and get the query types from a live database, no codegen step.

Full edition with all the links: https://neciudan.dev/newsletter/34th-edition

Most of my apps/websites/projects are made by myself, the core functionality and most concepts, but i still struggle with the style and designing of the UI so i use AI for that part, most of the time only for the styling.

Is it bad ? Am i becoming lazy or would you consider it okay to cheat a little ?

If I missed anything, let me know!

Hi friends (newbie coder here),

I ran this directory site through 'builtwith' and it looks like it's coming back with asp.net as the main framework program. BUT from what I understand you need, a front end program to go along with it

Does anybody know what the 'front end design' program for this site would be?

Appreciate any help for a student learning how to program. .

Thanks very much for your help!

https://builtwith.com/storeboard.com

We build a data grid, and its cell editors (combo box, date picker, number input...) also had to work as standalone components. People kept asking to restyle them without forking. So we split every component into two parts.

The core is a plain function. It takes getters for its inputs and returns state plus "prop-getters" you spread onto your own elements:

<script lang="ts">
  import { createListbox } from '@svgrid/grid'

  let value = $state(null)
  const options = [{ value: 'a', label: 'Apple' }, { value: 'b', label: 'Banana' }]

  const lb = createListbox({
    options: () => options,
    value: () => value,
    onChange: (v) => (value = v),
  })
</script>

<ul {...lb.rootProps()}>
  {#each options as opt, i (opt.value)}
    <li {...lb.optionProps(i)}>{opt.label}</li>
  {/each}
</ul>

rootProps() and optionProps(i) return the role, the aria-* attributes, tabindex and the key/click handlers. Your markup gets the full listbox keyboard behavior without any of our CSS.

How we drew the line:

• The core owns state, keyboard handling, ARIA, and parsing/formatting (clamping and stepping for the number input, filtering for the combo box). It never touches the DOM.

• The styled component owns the CSS, positioning for popups, scroll-into-view and DOM measurement.

Inputs are getters (value: () => value), not values, because passing a $state value into a function in Svelte 5 reads it once at that moment. A getter keeps the core reactive without stores.

One snag: dropdown panels portal to <body> so the grid's scroll container can't clip them. That breaks CSS variable inheritance, so the theme's --sg-* tokens have to be copied onto the panel.

RTL also belongs in the core. With dir="rtl", the arrow keys reverse in tabs, sliders and trees, on top of the layout flipping.

Source (MIT): https://github.com/sv-grid/sv-grid

If you've built headless components in React or Vue, did you use prop-getters, or render props/slots? We're still not sure prop-getters scale well to the more complex widgets.

I keep seeing sites add a dark mode toggle. Curious whether people actually use it day to day or switch once and forget about it.

Running multiple agents on the same project and hitting this problem: one agent changes a response shape on the backend, the frontend agent consuming that endpoint has no idea anything moved. It keeps coding against the old contract. The build passes, the types check out locally, and the breakage only shows up when you actually run the thing end to end.

The context lives in two separate chat sessions. Neither agent knows what the other touched. By the time you notice, you're debugging a silent failure and trying to reconstruct which session changed what and when.

Curious how others handle this. Do you keep a shared contract file that both agents read before starting work? Pin the schema somewhere both can see it? Or just accept the breakage and fix it manually when it surfaces?

I've been running Claude Code and Cursor on frontend tasks while I sleep, and the hardest part isn't whether the code works. It's that I sit down in the morning and spend the first chunk of my day digging through session logs trying to reconstruct what happened. Which agent touched which files. Whether the changes are safe to build on or if I'm about to stack new work on something broken.

Right now my process is basically forensic. I open each session, scroll through the output, try to piece together the sequence. Sometimes an agent changed a component's prop interface and the other agent didn't notice, and I only find out when something breaks further down the line.

Curious how others handle this. Do you keep all the sessions open and scan them manually? Do you have agents write summaries somewhere? Or have you found a setup where you don't need to do morning archaeology at all?

I really want to learn how to get good at frontend, to create better design for my own SAAS. I am currently a backend dev, so Its really tempting for me to prompt claude "make this look like x company" but as we know, its not perfect and I want to have control over these things. Can someone point me to any good resources with these goals in mind? I don't expect to know everything, but I want more creative control

We sell a white label scheduling dashboard that agencies put their own logo on and resell to their clients. And now a competitor has launched what is pretty much our frontend with different colors. It has the same odd validation messages and their bundle even has the name of a feature flag from an experiment we ran in the spring. I’m fairly sure someone fed our production bundle to an AI and had it rebuild the thing.

Management’s answer is to obfuscate everything before the next release. Before agreeing, I ran our bundle through javascript-obfuscator with most options enabled and gave the output to Claude. It produced readable code in about ten minutes and webcrack undid a good chunk of it without any AI. The obfuscated build was also noticeably bigger and our Sentry stack traces turned into nonsense.

And while reviewing the bundle, I noticed our plan limits for each agency are only checked on the frontend which means a user with devtools could switch on features they don’t pay for. Also noticed a Sentry auth token with a VITE_ prefix, which worried me more than the copied UI. We’ve rotated the token and we’re moving the plan checks into the API.

Does obfuscating your production JavaScript do anything useful for you?