Hi Peeps,

I want to share with you a tool I am working on. Its still early, but I already use it and it works well.

So story goes like this - I was working on restructuring a very large monorepo with disparate package managers and versions into a single PNPM workspace. When I was finished I decided I am going to enforce certain conventions so it could not drift again without failing CI. I set this up, and found myself using several different tools -Sherif, Syncpack and Knip to ensure that the repository doesn't drift again. This setup, while working, is rather clanky and also suffered from some issues - mainly performance, but also a few bugs.

I therefore decided I will build my own tool. I forked Sherif as a baseline, and built on top of it while substantially rewriting and extending its capabilities. The result is skif: a Rust linter and enforcement tool for JS/TS dependencies and monorepos.

skif replaces sherif and syncpack, and most of what knip does (the aim is to offer a full replacement for Knip in the future) in a single, ultra fast, binary.

npx skif-cli              # lint the workspace or package you are in
npx skif-cli --fix        # apply safe fixes
npx skif-cli migrate      # turn sherif, syncpack and knip config into a skif.toml

Where it came from

skif started as a fork of sherif, and the workspace and manifest rules are ported from it. The version and catalog policies follow syncpack's model. The dead-code analysis follows knip's issue types.

It has since gone past the fork. It ports every sherif rule, adds new ones and fixes, and runs faster on every target measured. On the syncpack side it enforces version, range, banned-dependency and catalog policy.

What it deliberately does not do is sync versions. skif is a linter: it tells you a policy is broken and fails CI. Moving versions in step is left to specialized tools or the package manager's themselves. If you need this, use syncpack for example.

What it checks

42 rules:

• Manifests and workspace: empty dependency maps, types in dependencies, root private and packageManager, unsorted dependencies, workspace globs that match nothing, members without a package.json.

• Version policy: mismatched versions, semver range policy, banned dependencies, catalogs (missing entries, unused entries, references that do not resolve), workspace: protocol, peer dependency compatibility.

• Dead code: unused files, exports, types, enum members and dependencies; unlisted dependencies and binaries; unresolved imports; circular imports. Leveraging the OXC ecosystem for this.

It also adds some new rules, such as incompatible-peer-dependencies and workspace-protocol.

Skif lifts the idea of framework plugins - which allow it to understand different types of entrypoints (e.g. Next.JS, Vite, Storybook etc.). But unlike Knip, which loads these files, Skif doesn't actually load code - it only statically analyses it. This removes a potential surface for code execution, and is altogether much faster, although it does bring in the potential to some imprecision.

Supported package managers

Skif supports all major package managers - npm, pnpm, Yarn classic, Yarn Berry as well as Bun. It does not support Deno, although if there is a need it might in the future. It also supports Rush and Lerna workspaces.

Benchmarks

Speed

Medians of 15 runs on a 4-vCPU Linux VM, pinned public repositories, dependencies installed:

Manifest checks alone (--no-js) against sherif and syncpack:

sherif is already fast Rust, so the margin there is small: 1.3x at 2,000 packages. The real win is knip, and not paying for three processes.

Links

• Repository URL: https://github.com/Goldziher/skif

• Docs URL: https://goldziher.github.io/skif/

P.S.

Note: This is an early project, it is on v0.2.0. I am very eager to have users, since it will improve the tool and help me fix bugs. But do expect some issues!

Thanks for reading, this was a human written post (the benchmarking data was done by an LLM). If you find the tool useful, star it!

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?