Hi I’m mostly a Backend developer.
I want create redesign for local or small businesses with terrible looking websites.
Instead creating a whole new design I webscrape their old website and generate a new more aesthetic NextJS website with Replit.
I’m wondering how do I make sure the architecture is decent enough for production.
Can you recommend some practices to make sure it’s production ready.
Contrarian take from building one of these ai test tools: the generation half is the least valuable part. crawling an app and spitting out playwright specs is basically a commodity step now. The real cost lands a few sprints later when someone renames a button and a pile of specs go red, and a dev burns friday sorting real failures from noise.
we default our runner to claude haiku for exactly that reason, the gen step is cheap so paying top-model prices for it makes no sense. The budget should go to making the output survive a refactor: plain .spec.ts files you can grep and edit, selectors that don't hard-fail on a cosmetic change.
every tool that demos beautifully and dies by month two makes the same bet, that writing the test is the problem. It isn't. the suite quietly rotting until half of it is muted is the line item nobody scopes. written with ai
https://positive-intentions.com
This is intended to introduce a new paradigm in client-side managed secure cryptography. We can avoid registration of any sort. A fairly unique offering for a messaging app.
No need for things like phone numbers, email or registering to any app stores. There are no databases. Allowing users to send E2EE messages; no cloud, no trace.
Features:
I started off with an open source version here: https://github.com/positive-intentions/chat
MVP Demo: https://chat.positive-intentions.com
The open source version is largely created manually (without AI agents). I am a software developer and creating webapps is my profession. I created it open source because it helps to be able to discuss details online. I think the core-concepts around client-side managed cryptography is demonstrated, but unfortunately open source isnt sustainable. So its unfortunate i have to consider introducing close-source components into the project (, so that i can maintain a competative advantage).
Components now close source:
I still keep some components open source for its importance in transparancy.
The close-source version of the app isnt finished enough to compare to existing tools like Simplex, Signal and WhatsApp. The goal is for it to be at least as secure as the Signal messaging app with their Signal protocol.
Take a look at some of the technical docs which ive updated to answer questions i frequently recieve in previous posts.
Technical breakdown and roadmap: https://positive-intentions.com/docs/technical/p2p-messaging-technical-breakdown
The optimistic long-term goal (if its even possible), is to create the "worlds most secure messaging app". If you really want to see how to achieve that goal, you can take a look at the more comprehensive docs here: https://positive-intentions.com/docs/technical
Frequently asked questions: https://positive-intentions.com/docs/technical/p2p-messaging-technical-breakdown/#frequently-asked-questions
I got tired of maintaining giant mock objects every time an API response changed.
A typical workflow for me looked like:
I ended up building a small open-source tool called FixtureKit.
You paste a TypeScript interface or Zod schema and it generates:
It runs entirely in the browser, so no schema data leaves your machine.
Recently added support for:
I'm mostly looking for feedback from frontend developers.
What's everyone using today for Storybook / Playwright mock generation?
And if you have a schema that breaks FixtureKit, I'd love to see it.
Hi
Wondering if anyone has a list or something that tells you when something is AI designed
I'm working on redesigning my friends website
and tried my best to avoid any gradients and purple and blue and any rounded card like elements but still hard for me to tell at this point what else i should either remove or add to reduce any other signs of AI slop
Appreciate any insights
The shadcn registry directory is pretty stacked, but there isn't currently any depth in the gamification space. So I decided to build a library of 17 components across the major features you see in most consumer platforms. Things like streaks, achievements, leaderboards, points etc.
Trophy UI is fully open-source, and while it seamlessly integrates with Trophy itself, the UI components just accept regular props and so can be used with any backend.
Most interesting components:
Streak calendar - weekly, monthly or yearly (git-style) view of streak history, with support for streak freezes which are pretty common in consumer apps like Duolingo.
Leaderboard rankings - flat list of rankings each with support for avatars, bylines and change indicators. Also supports pagination and collapsed rows to focus rankings around a particular position i.e. show users to top three users above and below them.
Achievement badge - a simple badge with support for locked/unlocked states plus features like percentage completion and rarity (the share of users who have unlocked the badge).
Points levels timeline - progression path for points levels with support for sub-levels (Bronze I, II, III, Silver I, II, III etc) plus anchoring to a particular users current progress.
Every component is installable via shadcn CLI:
npx shadcn@latest add https://ui.trophy.so/<component>
Once installed you own the code, customize and modify as you see fit.
Also very happy to accept contributions for new components or features for existing components.
Would love to hear what people think, and would very much appreciate a star on GH if you think its valuable!
Hi all,
About three years ago I built a small library called Trig.js to expose scroll data to CSS via data‑attributes. It recently got highlighted as one of the “Enterprise Heavyweights” of scroll animation libraries by CSSAuthor, which made me revisit the idea.
I’d always planned to make a Cursor.js, so I built it and then I started wondering, what else could be exposed to CSS variables? That question spiralled into something bigger, and I’ve now ended up creating a full stack of small, browser‑native libraries that all share the same philosophy:
>Use the DOM as the application layer, keep JavaScript minimal, and let CSS be the rendering engine.
Once I reached Keys.js, something clicked. Keys aren’t animation, they’re input.
That led to the bigger question, could you build full applications or even games this way?
The answer turned out to be yes, and that’s when I came up with State.js.
For the first time, here’s the full stack together:
Trig-js - exposes scroll data to CSS
Cursor.js - exposes mouse/touch position
Motion.js - a global clock for CSS‑driven animation
Keys.js - exposes keyboard input
State.js - a reactive state layer for HTML
Gravity.js - a DOM‑element physics engine rendered in CSS
Together, these for a declarative application/game engine using the native browser without webGL, webGPU or canvas. Your HTML is your state graph, the CSS is your rendering engine and JS becomes the wiring that connects everything up.
These libraries all work independently or together. As every one of these open up capabilities that wasn't possible before that's why they are all individual so you can pick or choose or use them altogether for a complete stack.
A few months ago I wouldn’t have believed half of this was possible in the browser without heavy abstractions. It’s made me realise how much capability we’ve historically hidden behind frameworks instead of exposing directly.
I’m excited to share this approach and would love to hear your thoughts, ideas, or critiques.
If you’re curious about browser‑native reactivity or CSS‑driven rendering, I’m happy to dive deeper.
Thanks
Edit: I also have a subreddit for State.js here https://www.reddit.com/r/Statejs/ come and checkout demos, examples and articles to learn more about State.js or come and talk about the complete stack.
CTO here. My team is shipping frontend code faster than ever (mostly using Cursor/Copilot/Claude) but I'm noticing a lot of UI drift. AI coding assistants are great at writing functional code but they frequently ignore our design system, hardcode hex values, and subtly break layouts.
We want to put guardrails in place without slowing the team down. For those of you maintaining mid-to-large frontends:
Stack is [React, Tailwind, Shadcn, TanStack Router, Turborepo]. Would love to hear what is actually working in production for you not just marketing hype.
I'm working on a personal one-man project.
It's very simple: it's a static website generated from some data stored in a JSON file. I have a prototype written in TypeScript/TSX, consisting of fewer than ten files (views), each containing an average of less than fifty lines of code. Only two of the pages retrieve data from JSON; the rest are simple TSX files that describe the project (pages like "About" or the "Privacy" page).
Given how simple it is, I thought I'd go the extra mile and focus heavily on ensuring the entire code, from the build process to the distribution, is 1000% correct, stuff like:
I started exploring the various programming languages that allowed me to do all these things at once, and I found OCaml. It:
To be honest, I also looked into Elm, which seems to be even more lenient when it comes to error handling; however, its HTML generation library doesn't seem to have strict controls over attributes, not nearly as strict as tyxml.
Is there something even more powerful that allows me to achieve what I want (code safety and error free) or is OCaml already the best? If so, what has been your experience with it? Any advice?
I'll say it again: the project is so simple that you could rewrite it in any programming language in an hour, it's no problem for me. It's a chance to learn something new.
Thanks in advance.
Elemental is a personal library I’ve been using for a while. I really don’t like how much frontend frameworks require you to invest in them. You have to learn funky domain specific languages and magic render lifecycles just to debug anything. I mostly just want to create and append elements with better ergonomics.
el(document.body,
el('main',
el('h1', 'Hello World!'),
el('h2', (x) => { x.id = 'foo' }, () => 'returned text'),
el('div.note', ['this', 'is', 'an', 'array']),
el('p.greeting', ob(() => ('My name is ' + rx.name)))
)
)
The syntax lets you build the DOM declaratively with plain nested functions, so logic and views live together in one structure instead of being split across separate layout and behavior. Reactivity is handled by observers (the ob(...) call above): they automatically track whatever reactive properties they read and retrigger when it changes. No manual subscriptions and no dependency arrays. And because everything is just normal DOM elements and functions, you can adopt it one component at a time instead of overhauling a whole project.
It's about 3.3 KB gzipped with no third-party dependencies. The library is just under 300 lines of code so it's easy to understand.
Would love to get feedback from having fresh eyes on it.
We are mapping out our China launch and the internal debate has narrowed to whether we go native mobile app or build a WeChat Mini Program. The argument for the app is that we already have one for our other markets and porting it feels like the obvious move, but everyone I talk to who actually works in China keeps steering me toward the Mini Program because users apparently never download new apps and live almost entirely inside WeChat. The Mini Program looks lighter and cheaper but I worry about how much we are giving up in features and brand control by sitting inside someone else's ecosystem. For anyone who has launched both or chosen one over the other in China, which route actually paid off and what would you do differently?
I've spent the last year fixing accessibility issues in a large production web app, and one anti-pattern kept showing up everywhere:
Clickable containers.
Examples:
<div> pretending to be a button<tr> elements for row expansionrole="button" and tabindex="0"The pattern usually starts as a UX shortcut and ends with:
One example I see frequently is the clickable table row:
<tr (click)="toggleRow(row.id)">
At that point the row is trying to be both a data structure and an interactive control.
My conclusion after fixing a lot of these issues: accessibility problems are often design problems before they're implementation problems.
How does your team handle expandable tables and clickable cards?
I have been listening to a lot of rants on the internet that frontend development is dead as the AI is able to generate a lot better UI's and someone says go for full stack n all as frontend is dead. What's the case ? I see People are still working in full time frontend roles in top PBC's like Razorpay, Airbnb and many more and here I am losing interest in software development as a whole due to AI.
Btw backend developers are also saying that backend is dead. I am so confused where to head now.
I am stuck in this low growth environment and getting bad work or is this the kind of work that we get in MNC's and from scratch work we get in startups ?