标签：#webdev

O&amp;#039; Billion dollar companies. It boggles the mind. Probably takes $500K in tokens for AI to figure it out. </rant> submitted by /u/centuryeyes [link] [留言]

I've had Claude make a few static website frameworks for me and I noticed some patterns. Rounded buttons, serif H1's that are soulful rather than descriptive, two contrasting buttons in the hero, loads of emdashes, "actually's", and hero "scroll down" directions. While this doesn't check all the boxes, it checks plenty of them. Reading the preview site text makes it seem like a joke. Is this for real??? On the other hand, it is missing the signature emphasis word in italics and a different color. submitted by /u/Adfarquhar [link] [留言]

I've been doing webdev for over a decade. Now I feel burnt out and worried about prospects. Mid-career and barely getting interviews. Not only do we have to compete on a global stage (I'm US based), but we have to deal with regular layoffs (and that's accelerated due to AI). What used to be reliable work with good pay, seems to have fallen off dramatically in both aspects. Do you agree? Would your recommend this field to a friend? submitted by /u/hypercosm_dot_net [link] [留言]

[ Removed by Reddit on account of violating the content policy . ] submitted by /u/Ok_Efficiency_1116 [link] [留言]

submitted by /u/cekrem [link] [留言]

Before a new template goes live, I like to crawl 10-20 rendered examples and check the boring stuff that tends to create SEO cleanup work later: Exactly one indexable canonical URL per page state Title and H1 are generated from different fields, not duplicated blindly No empty meta descriptions from missing CMS fields Pagination/filter URLs either have a clear index/noindex rule or are blocked from exploding into crawl traps Product/article schema is omitted when required fields are missing instead of outputting half-valid JSON-LD Internal links render server-side or at least appear in the initial HTML for important paths Most of this takes less time to catch in staging than it does to explain to a client after 5,000 thin URLs get indexed. The best SEO fixes are usually the ones that never make it to production. submitted by /u/VRTCLS [link] [留言]

Keyboard accessibility is one of the most important — and most neglected — aspects of web accessibility. An estimated 2.5 million Americans have motor disabilities that prevent mouse use. If your site can't be operated entirely by keyboard, you're excluding them completely. The Four Core Principles WCAG 2.2 Principle 2 (Operable) contains the keyboard requirements: 2.1.1 Keyboard (AA): All functionality must be operable via keyboard 2.1.2 No Keyboard Trap (AA): If focus moves into a component, it must be possible to move it out 2.4.3 Focus Order (AA): If page can be navigated sequentially, order must be logical and predictable 2.4.7 Focus Visible (AA): Any keyboard-operable UI must have a visible focus indicator 2.4.11 Focus Appearance (AA, new in 2.2): Focus indicator must meet size and contrast requirements Testing Without Automated Tools Start with the basic keyboard test: Unplug (or ignore) your mouse Press Tab to move forward through interactive elements Press Shift+Tab to move backward Use Enter/Space to activate buttons, links, checkboxes Use arrow keys for radio groups, menus, sliders Use Escape to close dialogs and menus Any element you can't reach or activate? That's a WCAG 2.1.1 failure. The Most Common Keyboard Failures Custom dropdowns and menus // ❌ Keyboard inaccessible function Dropdown ({ items }) { return ( < div onClick = { toggle } className = "dropdown" > { items . map ( item => ( < div onClick = { () => select ( item ) } > { item . label } </ div > )) } </ div > ); } // ✅ Fully keyboard accessible function Dropdown ({ items }) { return ( < div role = "combobox" aria-haspopup = "listbox" aria-expanded = { isOpen } tabIndex = { 0 } onKeyDown = { handleKeyDown } // handles Enter, Space, Arrows, Escape className = "dropdown" > < ul role = "listbox" > { items . map (( item , i ) => ( < li key = { item . id } role = "option" tabIndex = { - 1 } aria-selected = { i === activeIndex } onKeyDown = { e => e . key === ' Enter ' && select ( item ) } > { item

Hi, I'm Heet Sanghani, a Python Developer and AI/ML Engineer from Ahmedabad, Gujarat, India. I currently work at BrainerHub Solutions building backend systems and AI-powered applications. In this post, I want to share how I built BidXpert — a real-time auction platform using FastAPI. What is BidXpert? BidXpert is a real-time bidding platform where users can create auctions, place bids, and get instant updates using WebSockets. Tech Stack Backend: FastAPI + Python Database: PostgreSQL Real-time: WebSockets Auth: JWT Authentication Deployment: Docker What I Learned Building BidXpert taught me how to handle concurrent WebSocket connections efficiently in FastAPI and manage real-time state. About Me I'm Heet Sanghani — Python Developer & AI/ML Engineer based in Ahmedabad. Check out my portfolio and other projects at: 👉 https://heet-sanghani-portfolio.vercel.app/ python #fastapi #webdev #ai

Every inventory tool says real-time. Every single one. Open the settings. Find the sync frequency configuration. It says 15 minutes. Or 10. Or 30 on the cheaper plan. That's not real-time. That's a cron job. There's a meaningful architectural difference and the industry has collectively decided to pretend there isn't. I want to make the technical case for why this matters — and ask why so few tools have actually fixed it. What "real-time" actually means technically Real-time in distributed systems has a specific meaning. It means the system responds to events within a bounded, predictable latency — not on a schedule. javascript// This is NOT real-time — this is scheduled // Latency: up to 15 minutes (the full interval) setInterval(async () => { const stock = await getSourceOfTruth(); await syncToAllChannels(stock); }, 15 * 60 * 1000); // This IS real-time — event-driven // Latency: network round-trip (~milliseconds) orderEventBus.on('order.confirmed', async (event) => { const updated = await decrementStock(event.sku, event.qty); await propagateToAllChannels(updated); }); The first example responds to state changes on a schedule. The second responds to events as they happen. These are fundamentally different architectures with fundamentally different latency guarantees. Calling the first one "real-time" is technically incorrect. It's scheduled sync. The schedule is just short enough that most users don't notice — until they do. When users notice The failure mode is predictable and well documented: javascript// Flash sale scenario — 10x normal velocity const normalOrdersPerWindow = 500 / ((24 * 60) / 15); // ~5.2 const flashSaleOrdersPerWindow = normalOrdersPerWindow * 10; // ~52 // 52 orders processed against potentially stale stock // per 15-minute window // across multiple channels simultaneously // none of which know what the others have sold 52 orders per window. At 2% oversell rate — just over 1 oversell per window. Across 96 windows per day — nearly 100 oversel

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

Server-side tracking on Shopify Plus is no longer optional in 2026. Browser-side analytics tags now miss around 30-40% of conversion events on Safari, Firefox, and ad-blocked sessions when ITP, consent rejection, and ad-blockers combine, and the server-side fix — a GTM server container or an equivalent gateway — is the difference between a usable Meta CAPI feed and a reporting hole that quietly tanks your paid-media ROAS. Why browser-side pixels broke first The structural decay started years ago and accelerated through 2025. Safari's Intelligent Tracking Prevention caps JavaScript-set first-party cookies (anything set via document.cookie ) at 7 days, and 24 hours when the URL carries a tracking parameter like fbclid or gclid . Server-set first-party cookies sent via the HTTPS Set-Cookie header can still persist up to 400 days, unless the cookie's host resolves through a CNAME to a third-party — then ITP collapses that lifetime back to 7 days. Combine that with Firefox Enhanced Tracking Protection (around 5-8% of UK desktop traffic), ad-blockers (around 30-35% adoption on desktop), and consent-management platform rejection (typically 20-40% of EU sessions), and a typical Shopify Plus storefront ships measurable signal for only 60-70% of real purchase events. We have audited stores where a server-side migration recovered around 28% of attributed purchases inside the first 7 days of switchover — not because the conversions stopped happening, but because the browser layer stopped reliably reporting them. What a server-side gateway actually does A server-side tracking gateway intercepts the event between the storefront and the destination platform (Meta, Google Ads, TikTok, etc.) and re-emits it from your domain. The browser still fires a lightweight web-side ping, but the heavy payload — order ID, customer hash, line items, value — travels server-to-server. Cookies stay first-party because the request originates from your own subdomain. The destination platform sees a c

Stanford Just Published Rules for AI Coding Agents — What Devs Should Know Stanford dropped a document last week that every developer using AI coding tools should read. It's called CLAUDE.md , it's part of CS336 (Language Modeling from Scratch), and it's a brutally honest set of rules for how AI agents should — and shouldn't — help students write code. The document hit #1 on Hacker News for good reason. It doesn't just apply to students. If you use Claude Code, Cursor, Copilot, or any AI coding assistant, these rules expose the uncomfortable gap between what these tools can do and what they should do. GitHub just rolled out token-based billing for Copilot, and developers are furious. The tension is the same: when does AI assistance stop helping and start hurting? The Core Principle: Teaching Assistant, Not Solution Generator Stanford's position is unambiguous: "AI agents should function as teaching aids that help students learn through explanation, guidance, and feedback — not by completing assignments for them." This isn't academic hand-wringing. It's a design constraint that maps directly to professional development. The same agent that writes your PR in 30 seconds is also the one that leaves you unable to debug it when it breaks at 2 AM. The AI agent role framework from Stanford's CS336 guidelines: teaching assistant vs solution generator The document draws a hard line: What agents SHOULD do: Explain concepts by guiding toward understanding Review your code and point out areas for improvement Ask guiding questions instead of giving fixes Reference documentation, lectures, and debugging tools Suggest sanity checks, assertions, and profiler investigations What agents SHOULD NOT do: Write any Python or pseudocode Complete TODO sections in assignments Give solutions to problems Edit code in the student repo Convert requirements directly into working code Point to third-party implementations If you're a professional developer, the "SHOULD NOT" list probably looks extr

Stuck on Meta App Review and hoping someone here has cracked it. Setup: Instagram API with Instagram Login (graph.instagram.com, v25.0), Instagram User token (IGAA...), BUSINESS account. Trying to get Advanced Access for instagram_business_manage_comments. The blocker: the "make 1 successful API call" requirement stays at "0 of 1 API call(s)" for days (past Meta's 2-day logging window), so the Request Advanced Access button stays grayed out. What I've confirmed: - The token DOES hold the scope (granted permissions list includes it). - GET /{media-id}/comments?fields=id,username,timestamp returns HTTP 200. - Rate-limit usage increases per call, so the calls are landing. - It's not the endpoint: I also tried creating a comment + replying (POST /{media-id}/comments, POST /{comment-id}/replies) — all 200, none registered. On the SAME token/path, instagram_business_manage_messages registered fine (its requirement is complete) even though ITS call (GET /me/conversations) also returns an empty array (200, "data":[]). So an empty 200 counted for manage_messages but the comments call never counts for manage_comments — looks like a tracking bug specific to the manage_comments counter. Question: has anyone gotten instagram_business_manage_comments to flip 0 -> 1 on the Instagram-Login path? What exact call/step did it, or did Meta credit it via a Platform Bug Report? Anything that worked would save me. submitted by /u/Traditional-Lake3525 [link] [留言]

Frontend automation has been getting pretty wild lately. 🫠 A few months ago, this comparison would...

I've been building out embedded reporting for b2b clients (i use next.js), and as our user base grows, the P95 latency is becoming a nightmare. Every time a user changes a date filter, it triggers a fresh compute spin-up on the warehouse. I’m currently refactoring the stack to put a universal semantic layer (in my case, cube core) between the frontend and the database. and the goal is to move all the logic, like multi-tenant row-level security (RLS) and complex joins, out of the React code itself and into a declarative modeling layer since I started, the biggest win (so far) is using pre-aggregations. now, instead of hitting raw tables, the API hits a warmed caching tier which is in the 'cubestore'. it feels more like querying a structured API than a database for those of you here who do high-concurrency analytics in SaaS, a question! are you just throwing more money at warehouse compute, are you moving toward this kind of decoupled architecture, what other best practices do you have? now trying to figure out if I should stick with this or just move everything to a huge ClickHouse instance and hope for the best submitted by /u/sivyh [link] [留言]

Inspiration Build a simple and modular technical documentation and blog. Build the website without using node/npm or any external frameworks(CSS, JS, icon, font). Only GoHugo normal binary + pageFind binary needed. Features [x] Responsive and adaptive layouts. [x] Support for light and dark modes. [x] Support for multiple documentation sets. [x] Support for a blog. [x] Implement a menu via Hugo configs. [x] Customizable sidebars using Hugo data templates. [x] Plug-and-play/ repeatable home page blocks using separate partials/ css/ data templates. [x] Integrate a search via Pagefind. [x] Inline SVG icons based on Google's Material Symbols GitHub Repo: https://github.com/dumindu/E25DX Example Docs: https://github.com/dumindu/E25DX/tree/gh-pages/example Example Live: https://dumindu.github.io/E25DX/ submitted by /u/dumindunuwan [link] [留言]

submitted by /u/mightyme2 [link] [留言]

“Did We Already Watch This?” — Building KindaSeen with FastAPI and Next.js A few months ago, my friends and I kept running into the same question whenever we talked about movies, dramas, anime, or variety shows: “Did we already watch this before?” Sometimes we remembered the title but forgot whether we had finished it. Other times, we completely forgot we had already seen it at all. That simple problem inspired me to build KindaSeen, a full-stack personal media repository designed to help users track and organize the media they’ve consumed in one centralized platform. The goal of the project was not only to create a useful application, but also to gain hands-on experience building a real-world full-stack system with modern web technologies. What KindaSeen Currently Supports User authentication with Supabase CRUD operations for personal media records TMDB-powered search functionality Watchlist system Favorites system Persistent PostgreSQL storage Dockerized backend deployment Separate frontend/backend deployment workflow Tech Stack Frontend Next.js React Tailwind CSS Shadcn/ui Vercel deployment Backend FastAPI PostgreSQL Docker Render deployment External Services Supabase Authentication TMDB API integration One of the main goals of this project was to simulate a more realistic production workflow by using a decoupled frontend/backend architecture instead of building everything inside a single monolithic application. In this article, I’ll share: Why I chose this architecture How I integrated TMDB into the application Challenges I faced during deployment What I Learned From Building KindaSeen Why I Chose This Architecture Instead of building a monolith using Next.js API routes, I decided to decouple the application into a Next.js frontend and a FastAPI backend. This decision was driven by three main factors: AI Compatibility & Future Proofing : While researching the job market, I noticed that most companies building AI products heavily rely on Python. By choosing FastA

We talk about pagination as if it's purely a backend concern – the database does the heavy lifting, the API returns pages, and the frontend just renders them. But in 2026, that mental model is outdated. The frontend now owns more of the data-fetching lifecycle than ever: server components prefetch, client caches hydrate, optimistic updates mutate, and streaming responses trickle in chunk by chunk. The choice between cursor pagination and offset pagination has real consequences for how you write your React components, how your cache behaves, how scroll feels on the phone, and what happens when a user navigates back. This post is about those tradeoffs – from the frontend seat. The Landscape Has Changed A few things are different in 2026 that make this conversation more nuanced than it was three or four years ago: React Server Components are mainstream. Data fetching happens on the server in many apps, which shifts where pagination state lives and how navigation works. TanStack Query is the de-facto standard for client-side async state, with first-class infinite query support baked in. The "infinite scroll vs pagination" debate is mostly settled — infinite scroll wins for feeds and content-heavy apps; numbered pages win for dense data tables. Your pagination strategy should serve that decision, not fight it. LLM-powered search and filtering are becoming common, and those use cases have their own quirks around pagination stability. Edge caching and CDN-level pagination mean that certain offset-paginated responses can be cached by URL – a genuine advantage offset still holds. What Frontend Engineers Actually Care About When you strip away the SQL theory, here's what the pagination choice actually affects on the frontend: 1. Cache Key Design With offset pagination, the cache key is simple and predictable: posts?page=3&limit=20 . Every page is independently cacheable by URL — your CDN loves this. TanStack Query, SWR, and Apollo all handle this naturally. // Offset — clean,

You know that, right? The mobile web is completely unusable. Its garbage and it is garbage because you can't say "no" to stupid advertisers and keep putting more and more stupid popovers and sneaky links, and animations, and content obscuring crap, often not bothering to put the close box within the bounds of the screen. If you work on a mobile version of a website - shame on you. It doesn't work. I'm not kidding. I probably visited, and immediately noped out via the back button because it is just more trouble than the crappy click bait title implies it might be worth. RIP mobile web. submitted by /u/Small_Dog_8699 [link] [留言]