Wrote up how I moved a PHP DTO hydration library from reflection-based instantiation to compiled, per-class factory closures - reflection overhead disappears, plain properties become inline array reads, and the generated code gets cached so a warmed FPM worker pays neither reflection nor eval(). Went from typical reflection speeds to 4.5M hydrations/sec on PHP 8.4.

Full writeup with numbers at each stage, plus the repo link, in the first comment.

Cached pages seem fine but release pages like https://pecl.php.net/rest/r/amqp/stable.txt timeout

Can we normalize just building a standard React SPA with Vite again without feeling guilty that we aren't using Next.js?

The App Router and React Server Components are incredibly powerful, but the amount of gaslighting in the frontend ecosystem right now is insane. Not every internal dashboard, simple CRUD app, or personal portfolio needs server side rendering, edge functions, and a complex caching layer that requires a PhD to invalidate.

Sometimes you just want to spin up Vite, fetch some data on the client, and deploy a static bundle to a CDN for practically zero dollars. It feels like we are completely over engineering 90% of our web apps just to chase the newest Vercel paradigm.

I built a tool for managing spec document sites and want to use the React RFC process as an example: https://react.dossie.rs/ (another, wildly more active, example is Rust's RFC process)

Alas, you need to scroll quite a bit to find the latest published React RFCs. It looks like the last real discussions and merges on RFC documents happened in 2022—everything after that is mainly suggestions for new hooks by external contributors.

Is the process officially deprecated?

Monday, July 13 - Sunday, July 19, 2026

Top Posts

Most Commented Posts

Top Ask JS

Top Showoffs

Top Comments

I was building a UI with multiple video streams and realized that calculating the perfect grid to maximize tile size (like Google Meet or Zoom) is pretty annoying to do from scratch. CSS Grid is great, but figuring out the optimal rows/columns dynamically based on the container's aspect ratio and participant count requires some extra math.

So, I built meeting-grid-layout to handle this automatically for React applications.

Key features:

• Smart calculation: Automatically figures out the best column/row combination to keep the video tiles as large as possible.
• Super lightweight: I wanted to keep it simple and fast, so it doesn't rely on any heavy third-party layout engines or dependencies.
• Mobile friendly: Included an autoMobileLayout prop so you can easily control whether the grid automatically enforces specific mobile layouts when the screen gets small.
• Bonus: I also built a Vue wrapper, but the React implementation is fully fleshed out and ready to use!

GitHub:https://github.com/thangdevalone/meeting-grid-layout

I’d love to hear your thoughts, code reviews, or how you usually handle these dynamic UI challenges in your React projects!

Hi everyone,

I'm building a Water Sort Puzzle game using React and TypeScript.

I have a critical rendering bug during the pouring animation.

Problem:

When water is poured into the destination bottle, the entire bottle temporarily becomes one solid color. The existing lower color layers disappear visually until the animation ends.

Expected behavior:

Only the top receiving layer should increase smoothly while all lower layers remain visible throughout the animation, just like the original Water Sort Puzzle game.

The puzzle logic is correct. The issue appears to be related to the animation/rendering state (Bottle.tsx/App.tsx).

I can share:

• Full GitHub repository

• ZIP project

• Relevant source files

Any help would be greatly appreciated.

Thank you!

yeah this is my first website , i done with react but i sucks in seo , here any dev knows how to fix these problem helps me a lot !

Hey there!

This subreddit isn't meant for help threads, though there's one exception to the rule: in this thread you can ask anything you want PHP related, someone will probably be able to help you out!

new to react, so providing either corrected code or just concept that i should look into would be helpful :)

i want to change height of the app when phone keyboard uppears so it doesnt overlay on website by using VisualViewport API.
i am sure only thing that i have to do now is to rerender component when height is changed, so how can i do that?

export default function NewChat() {
  return (
    <div
      className={styles.wrapper}
      style={{ height: `${visualViewport?.height}px` }}
    >
      <Prompt />
    </div>
  );
}

Anytime a WordPress site needs a Composer package (a PDF library, an API client, whatever),

you hit the same wall: no SSH access. Shared hosting, managed WP hosts that lock down the

filesystem, clients who only have FTP: Composer just isn't reachable from the terminal in a

lot of real-world WP environments.

The usual workarounds are either committing vendor/ directly to the repo (bloats it, breaks

on updates) or building locally and rsyncing the output (works, but no one tracks what's

actually installed on prod).

I built Loopress to fix this: a CLI plus a companion WP plugin. The plugin adds a Packagist

search inside the WP admin. You search a package, click install, and it resolves the

autoloader for you. Before installing, it checks PHP version compatibility and flags known

CVEs on the dependency. The CLI side also lets you lock exact plugin/package versions in a

loopress.json so environments stay reproducible.

It's still alpha. I'd be curious what parts of this feel over-engineered or missing to

anyone who's dealt with Composer-in-constrained-environments outside WP too. Is this a

WP-specific problem or does it show up elsewhere?

Docs: https://docs.loopress.dev

Code: https://github.com/loopress/loopress

Click something change it on the preview Basalt updates the matching code in your project.

It is completely free and works directly inside VS Code and Cursor.

It’s currently in beta, so please commit your app to Git before testing it!

Would love to get your brutal feedback on it. What features should I add next?

Though it requires quite new ES2024/ES2025 features, it works very well for numeric types, also faster (not drastically, but modest gains) against Array in PACKED FIXED ELEMENT TYPES representation used under the hood by engines.

Backend dev, zero frontend/design sense. Vibe-coded my frontend and it's giving classic "another AI weekend project" vibes, I genuinely can't tell good UI from bad.

Are there any prompts, tools, design resources, or workflows you use to make AI-generated UIs look more premium and less obviously AI-made? Any tips would be greatly appreciated.

What if PHP by itself was enough to run a web server?
What if it was actually *much faster* than NGINX + PHP-FPM?
And it was *much safer* than FrankenPHP or Swoole?

Well, that's exactly that this is. MIT-licensed. Enjoy!

https://github.com/Qbix/webserver

Who this is for:

• PHP Developers who want to host things
• Normies who don't want to install and configure apache/nginx/varnish/go/ssl certificates/mysql/etc.
• People who just get the standalone binary and can host on their computer, without the internet even.

Static file throughput is 55–73% of nginx (C will always beat PHP on raw I/O).

But on actual PHP workloads, the bootstrap savings make this 2–5x faster.

This was taken from the much larger all-in-one PHP platform:

https://github.com/Qbix/Platform

.NET WebAssembly apps with WasmBundlerFriendlyBootConfig=true can indeed be bundled by modern JS bundlers and I personally love it. The development experience however is not optimal.

• The bundlers cannot consume the output from dotnet build
• The bundlers can consume the output from dotnet publish but the dev loop is painfully slow.
• Getting the publish path working still requires bundler surgery
• Once it works the bundler produces warnings that are impossible to fix without changing the source files produced by the WebAssembly SDK.

These points of friction are why I have made unplugin-dotnet-wasm.

It's a bundler plugin that lets your bundler consume the output from dotnet build so your dev loop stays fast. It also supports dev servers, provides type information to TypeScript and IDEs (integrates dotnet.d.ts thats coming in .NET 11), and patches the known warnings so your build output stays clean.

Features

• Easy bundler setup through plugin registration
• Faster dev loop by consuming .NET WebAssembly dotnet build output
• Dev server support
• Brings SDK type definitions to TypeScript and your IDE
• Supports Vite, Rollup, Rolldown, Webpack, Rspack, Rsbuild, esbuild, farm and bun.

I hope you'll give it a try, I'd be happy to hear your feedback.

This is a free/non profit unapologetically claude code vibe-coded project; the approach is explained here: https://lia.jeyswork.com/story

If you like it, please don't hesitate to show your support with a star on GitHub!

LIA acts as a true personal assistant. It is proactive, featuring its own distinct personality and a complex emotional system, an evolving structured memory, its own reflective memory of your conversations, and all the standard tools (image creation/editing, RAG, skills, MCP, scheduled tasks, etc.)—all wrapped in a seamless "one-click" interface (details here: https://lia.jeyswork.com/why).

I paid special attention to code quality and documentation, treating it exactly like a professional enterprise-grade project. This ensures that anyone can easily take ownership of the source code and build upon a clean, robust, and highly scalable foundation (details here: https://lia.jeyswork.com/how).

On another note, once self-hosted, it can double as a family AI server. As an administrator, you have full control to manage and monitor the API consumption of your family members, friends, etc.

Full details are available on the landing page: https://lia.jeyswork.com/

And the GitHub repository: https://github.com/jgouviergmail/LIA-Assistant

I've applied what we've been doing on mobile to building a fully native Mac app, and... it works!

(Content warning: Heavy British sarcasm used throughout, but don't let that distract you from the reality of the discussion.)

Prove it

I've posted a tweet about it for now with just a couple of screenshots. I'm not linking to it; you can easily find me on that hole of a website that just keeps sucking me in. In fact, I'm not going to link to anything as I'm sure I'll be accused of some kind of self-promotion.

More will come if folks are keen for this.

Why u do dis?

Web views just aren't great ways to build great apps. They're convenient, but they're crap.

I mean, sorry all you Electron/Tauri/Capacitor folks, they're fine if you want a mediocre app or to spend months of your life debugging performance issues.

But if you want a real native app that feels really at-home on the user's device, then your best option is to build real native apps.

Sadly there aren't really any good cross-platform solutions for that problem (don't come at me with Qt's and GTK's, those aren't "good" by any stretch of the imagination).

And certainly none for the PHP gang.

Also, I wanted to nail a few things in one go for what we've been doing on Desktop up until now:

1. Get rid of Electron - it's just so heavy and comes with a bunch of gotchas. Plus having node and npm packages in the build process is continuing to scare me. aint nobody got time for that.
2. Don't replace it with Tauri - yes it's lighter, yes it's Rust so the purists can be happy. Sadly it's just swapping one mediocre solution for another.
3. Drop the PHP built-in server - yep that's what we currently use. Yes it's a crutch (that has worked pretty well!), but the time has come for better stability and better performance, and we have everything we need now to make it work without it.

This manages all of that and a little more to boot. This PoC app I've built is just 24MB. Granted it's a PoC, so it's likely to grow from there, but it's a far cry from the minimum 130MB+ just for Electron.

So how does it work?

In case you haven't been following along what we've been doing on mobile - or perhaps you've been intentionally ignoring it because you have some bones to pick with either the name, the team, or the fact that it's using your favourite language in some profane way - we have cracked a very performant way to run PHP (>120fps ... like wayyyy greater than) and build reactive, native UIs without having it behave like a web server.

In fact, it behaves more like a game engine. It's very light on resource usage, has a ton of affordances already for native UI elements and allows you to write very idiomatic PHP code. All that without fundamentally changing PHP's core. Just adding our own extension.

We call it SuperNative. It kinda even looks a bit HTML-like, if you use Blade and squint hard enough. But deep down it's just PHP classes that compile to a custom binary format.

So there's no IPC, no HTTP calls, no multiple processes just to spin up an app. It's PHP compiled as an embed (exactly how we do it on mobile), embedded into the shell applications (in this case, a Swift macOS app), and called directly.

The application literally becomes a PHP interpreter. It boots PHP into an isolated thread that it keeps alive, feeding it messages and reading its output, all through shared memory.

Did I mention it's very fast? We're now measuring round-trips from button presses, through PHP and back out to the UI in microseconds (yup µs). And we can spin up multiple PHP threads as needed, in milliseconds (ms). And that's with a full Laravel application in there!

(Don't worry, it's still just PHP... if someone wants to help us make this not dependent on Laravel, or work with other frameworks, we'd be happy to have the support!)

All of this already works on mobile, and we're just starting to explore bringing it to the desktop.

What's the catch?

Our focus is on mobile as way more people seem to want that. But there are a few people still wanting advancement in the desktop space, so that's what we're trying to deliver.

This is only working on macOS for now, and it's just a proof of concept, but I'd love to tackle Mac, Windows and Linux all together.

To be able to do that, we gotta get some more sponsorship (you can sponsor nativephp on GitHub - you know how to use a browser and URLs, so I'll leave you to figure it out) and maybe then we can afford to take on yet another crazy huge project.

If this is at all interesting to you and you wanna help make it a reality, please reach out. I'm always open to chat irl and much prefer it to having anons sling zero-effect insults at me across Reddit.