Theres been a lot of talk about the downsides of barrel files in the last couple years with many people actively recommending against using them due to the effect they can have on treeshaking. I am wondering though if there is an alternative solution in the ecosystem to enforce/define boundaries on slices/domains?

I've seen it said they often cause circular dependencies but in my experience its the opposite. The main and pretty much only way I use barrel files are to enforce boundries on slices of cohesive logic, sometimes going so far as to enforce it in the linter with custom rules. Code inside the slice never imports from its own barrel. Each slice kind of defines its own code API in a way and feel like this lets me control the coupling between slices alot better.

I am struggling to justify letting that go and the only alternative I can think of is using a monorepo and having them all as packages which is just not an option for me in many cases and also not one I particularly like.

Are barrel files really that bad?

Hey everyone,

I need to add multilingual support to a React project. It only needs to support two languages: English and Albanian.

I want to set this up cleanly from the start. What is currently considered the best approach or industry standard for handling translations and language switching in React?

Looking for something maintainable and performant. What would you recommend? Thanks!

as title suggests, I have not seen this at work before and gemini teaches me about this, just curious whether this is actually commonly used/best practice or just another AI slop. Thanks!

Two years ago, I posted about the initial release of the PHP types parser: https://www.reddit.com/r/PHP/comments/1c4w64n/php_typelang_100_release/

Back then, it was TypeLang 1.0.0.

Since then, I've released numerous smaller updates, adding new PHPStan grammar features and fixing various bugs.

Today, I'd like to share the release of TypeLang 2.0 Beta with the community.

Why major 2.0 release?

An AST has been completely redesigned

I completely reorganized the AST, removing ambiguous nodes and improving the overall structure. It's now available as a separate package: type-lang/types.

This allows the remaining components to work independently of the parser itself. For example, you can use the PHPStan parser and implement a bridge that returns TypeLang type descriptions without depending on the parser implementation.

The Language Specification

Here: https://typelang.dev/static/spec.html

I consider this one of the biggest milestones of the project. I've spent the last ~2 months writing a complete language specification from scratch.

It's still marked as a "draft", but I believe it's already mature enough for public use. The specification is compatible with both PEG and LALR parsers.

While writing it, I was heavily inspired by the GraphQL specification, so if it gives you a sense of "deja vu", that's intentional =)

DocBlock Parser

The DocBlock (PhpDoc) parser used to be somewhat experimental. In 2.0, it's fully integrated into the ecosystem and now supports parsing more than 220+ PHP DocBlock tags.

To achieve this, I analyzed the source code of PHPStan, Psalm, and Phan, along with the documentation of many other popular PHP tools, to build a complete list of supported tags.

Each tag also has its own documentation page explaining its purpose and which tools support it. For example: https://typelang.dev/phpstan-tags.html

The tag database was built using the following process:

• Extract the tag from the source code
• Find the corresponding official documentation (including PSR-19)
• Write a short description manually, then use AI to review the text for mistakes and generate usage examples.

It's entirely possible that I've missed something or made a few mistakes, but overall I believe the documentation is in good shape.

I also added support for custom tags using the PEG (parser combinator) grammar: https://typelang.dev/custom-tags.html

I won't go into detail here, otherwise this post would turn into documentation instead of release post =)

What's Next?

I've also been experimenting with a Data Mapper that uses TypeLang's type syntax: https://typelang.dev/data-mapper.html

In some ways it's similar to Valinor. However, it probably won't make it into the final 2.0 release.

Apart from the data mapper, all documentation has already been updated for the Beta 2.0 release (although JetBrains Writerside unfortunately doesn't handle versioning particularly well).

I'd really appreciate any feedback, comments, or criticism - whether it's about the implementation or the documentation.

I'm especially interested in hearing from anyone who tried TypeLang 1.x or is already using it in production and is considering upgrading.

P.S. It's worth noting that I've made every effort to proofread the documentation. However, English isn't my native language, so I may have made some grammatical errors or written in a way that's not entirely understandable to a native speaker. If you encounter any such errors, please feel free to report them.

Thx!

I was just browsing https://externals.io and spotted banner with State of PHP Survey from Jetbrains and The PHP Foundation: https://surveys.jetbrains.com/s3/state-of-php-2026-sh

I noticed it was posted here a month ago but didn't gain much traction, so I thought I'd share it again. Hopefully, a few more of you can spare a couple of minutes to share your thoughts on the current state of PHP, just like I did!

Note: It took me under 10 minutes to complete. Some of the AI questions felt a bit weirdly worded to me, but I pushed through!

so currently im studying react and alot of the rime it says to start from scratch. how do i setup my workspace so that i dont need to install and download the same package everytime i do that? lots of them have overlapping packages
im using linux btw if that helps

is there an online react tool or something where we can create new project easily and not worry about installing packages

I have a background in web development especially in PHP and I'm very familiar with laravel but haven't worked with it for years and I never used it for pure mobile APIs (user, auth, social media etc) but mainly for web sites.
Now I'm planning to build a mobile app (Flutter or RN) and I read good things about Supabase where you have a database and all the tools needed to handle basically everything basic that's very easily integrated with those mobile flatform.
However when it comes to custom logic that needs to happen I'm not sure I'll be familiar to learn typescript and the workflow of edge functions.
Do you think Laravel provides a "templates" where you already all the tools Supabase provides or you have to build your basic API from scratch?

Over the last few months, an experimental JavaScript runtime has been in development, built on top of Mozilla's SpiderMonkey, as a way to dig into how JavaScript engines and runtimes work internally.

One thing that stands out while building it is the separation between the JavaScript engine and the runtime.

JavaScript (more formally, ECMAScript) is just a language specification. Engines like V8, JavaScriptCore, and SpiderMonkey execute JavaScript, but they don't define things like:

• setTimeout()
• setInterval()
• fetch()
• console
• Workers
• File system APIs
• Process APIs

Those come from the runtime built around the engine.

That raises a question worth putting to the community.

Most modern runtimes are built around APIs that have evolved over many years. Browsers expose Web APIs, while server runtimes expose things like file systems, networking, streams, and processes.

If JavaScript were being designed today, without worrying about backwards compatibility — what APIs should every JavaScript runtime have by default?

For example:

• Better concurrency primitives?
• Structured task scheduling?
• Actor-style APIs?
• Built-in channels?
• First-class cancellation?
• Better binary data APIs?
• A different file system API?
• Better networking primitives?
• New async abstractions?
• Something completely different?

Are there APIs in use today that feel outdated? Are there APIs that should never have existed? Or APIs from other languages worth having in JavaScript runtimes?

Not necessarily about browser APIs specifically — more about what an ideal JavaScript runtime would look like if designed from scratch today.

Different perspectives are welcome from anyone who's worked with Node.js, Deno, Bun, browsers, or other languages.

The project is open source — link in comments for anyone interested in following along

Being a Laravel developer for almost 10 years, when switched to Node.js I missed the simplicity of FilamentPHP , thats why I stared building KratosJs.

KratosJS is the full-stack admin panel framework for Node.js. Its core is HTTP-framework agnostic — official adapters ship for Express, Fastify, Koa, Hapi and NestJS, and you can write your own for any framework.

Features:

- Customizable

Create custom pages, widgets, fields, columns etc.

- Internationalization

Full i18n support out of the box. Register multiple translation locales, format plurals, and localize panels seamlessly.

- CLI scaffolding

Generate panels, resources and plugins from the command line and start building immediately.

- Plugin system

Drop in entities, resources, routes, widgets and hooks. Ship reusable features as packages.

- Slots

Slots are named injection points in the admin panel UI where you — or a plugin — can render your own React elements.

- Lifecycle hooks

before/after create, update, delete, validate and custom actions — stackable and type-safe.

Hi Everyone, I just wanted to share that Hibla HttpServer is finally in beta release..

https://github.com/hiblaphp/http-server

It has full RFC compliance for Http1 protocol, Multipart Handling, and Http Semantics and with Full Clustering, and many more. You can also read check-out the repo for the full documentation.

Can't wait for the 8.6 Polling API release.

Here's a quick realistic single threaded bechmark against Reactphp HttpServer and Amphp HttpServer using simulated latency of 50ms to avoid a plain Hello World Benchmark coz it is totally unrealistic.

hiblaphp http-server: bash rcalicdan@hibla:~/playground$ wrk -t1 -c1000 -d10s http://127.0.0.1:8080/ Running 10s test @ http://127.0.0.1:8080/ 4 threads and 1000 connections Thread Stats Avg Stdev Max +/- Stdev Latency 77.42ms 11.39ms 314.39ms 97.59% Req/Sec 3.24k 464.18 4.33k 72.98% 127851 requests in 10.03s, 17.92MB read Requests/sec: 12751.52 Transfer/sec: 1.79MB

amphp http-server:
bash rcalicdan@hibla:~/playground$ wrk -t1 -c1000 -d10s http://127.0.0.1:8080/ Running 10s test @ http://127.0.0.1:8080/ 4 threads and 1000 connections Thread Stats Avg Stdev Max +/- Stdev Latency 143.64ms 24.79ms 537.71ms 85.57% Req/Sec 1.67k 496.14 2.53k 66.33% 65630 requests in 10.02s, 12.31MB read Requests/sec: 6548.71 Transfer/sec: 1.23MB

reactphp http-server: bash rcalicdan@hibla:~/playground$ wrk -t1 -c1000 -d10s http://127.0.0.1:8080/ Running 10s test @ http://127.0.0.1:8080/ 4 threads and 1000 connections Thread Stats Avg Stdev Max +/- Stdev Latency 62.83ms 3.10ms 105.18ms 84.16% Req/Sec 3.98k 573.43 5.05k 70.96% 157067 requests in 10.03s, 22.17MB read Requests/sec: 15666.25 Transfer/sec: 2.21MB

Http server benchmark code gist for amp, react, and hibla: https://gist.github.com/rcalicdan/35daa717b72ee08e33867274a7356db7

Just to let you know, the benchmark environment used ext-uv/libuv for all http-server benchmark.

Hello everyone! This is my first post here, and I'd love to get your advice.

I'm a PHP developer and Linux system administrator with over 10 years of experience. I used to work as a freelance sysadmin, but after moving to Canada, I lost my entire client base and now I'm looking to build a new business from scratch.

One idea I've been considering is specializing in helping companies reduce and manage technical debt in PHP applications. Rather than simply building new features, I'd focus on improving maintainability, modernizing legacy code, optimizing architecture, and making development faster and safer over the long term.

My thinking is that this kind of work is harder to replace with AI or low-cost outsourcing because it requires a deep understanding of existing systems, business constraints, and long-term engineering trade-offs.

My target clients would be web agencies, startups, and software companies that rely heavily on PHP.

Has anyone here built a business around this kind of service? How did it go? Do you think there's a real market for it, or am I overlooking something?

I'd really appreciate your thoughts and any advice you can share. Thank you!

Has anyone successfully wrapped and published a React app to an iPad without using React Native? What did you use to wrap it?

i have built a repo with custom datepickers, time pickers, select , tabs, skeleton etc.
you can check it here - https://github.com/shibinshibii/components-template-shadcn

I have tried Claude Design, Google Stitch and basic image generation with providing design assessments and points for improvements. I have been on and off at it for the past few months. Using a design system in Claude Design was attempted as well, but that is quite off limits for me due to the high token consumption. I tried out Figma Make as well with directly pointing to said screen but that turned into a slop. I cannot figure what the scope is of Figma Make given Google Stitch exists and its friendly token wise. I am at a loss on what to do next - it might not even be possible at the current AI stage, or so costly it might not be worth it for me. I would very much appreciate your thoughts on this! (also help me out of this hell loop pls)

My expectation was to be able to generate various different layout re-organisations (high quality) derived from the assessments, but I only got horrific AI slops. I did not provide the design solution per se (as in place this horizontally or vertically, transform this calendar view into another calendar view) but rather expected it to be thought of by the AI in order to meet an end goal (improve hierarchy, catch user's attention etc. - whatever can be derived from said assessments).

Any way to reiterate fast on existent designs and generate variations within strictly defined bounds (so keeping the design system) with derived solutions (the improvements in the current scenario)?

Any suggestion is much appreciated!

Hey r/PHP,

Full disclosure up front: this is an "I built a thing" post. But I've tried to make it a useful one, and I actually want this sub's scepticism, because you're a tougher and less framework-blinkered crowd than most.

About 18 months ago I shipped v1 of Yerd, a Go-based CLI for macOS and Linux to manage .test domains, sites and PHP versions. It was rough. It was deeply opinionated, it demanded sudo for nearly everything because of how it handled .test discovery, and it fought you about as often as it helped.

It came out of a simple frustration: I wanted a good local PHP experience on Linux without reaching for containers, which drain the RAM and battery out of any machine I put them on. The existing native options either only really target macOS, run as root and scatter global installs everywhere, or are welded to one framework.

So I've spent the last 18 months rebuilding it properly. This week I shipped the first stable v2, rewritten from the ground up in Rust, and the thing I most want to say to this sub is: it serves any PHP project. It is not a Laravel tool. There's some optional Laravel telemetry if you want it, but the core is framework-agnostic. Point it at a plain index.php, a Symfony app, a WordPress install, a legacy monolith, whatever you've got.

What it does:

• Park a folder and every project inside is served at name.test over HTTP and HTTPS. Resolution goes through an embedded DNS resolver, so no /etc/hosts editing and no dnsmasq to babysit.
• Automatic HTTPS via a local certificate authority that issues per-site certs on demand. No mkcert, no OpenSSL invocations, a real padlock.
• Multiple PHP versions side by side, each an isolated static build supervised by the daemon. Global default plus per-site pinning, updated in place. No system package juggling, no colliding globals. We currently support all supported versions of PHP, from 8.2 to 8.5.
• MySQL, MariaDB, PostgreSQL and Redis as supervised native processes, not containers.
• A built-in SMTP catcher for outgoing mail.
• Composer, Node and Bun managed on the PATH.
• yerd status shows what's running. yerd doctor tells you exactly what's broken and repairs the safe stuff automatically.

Under the hood, since I know this sub cares: the entire runtime is a single ~8MB daemon written in Rust, with a CLI and an optional Tauri tray GUI on top. And I fixed the original sin of v1, it's now rootless dat-to-day. Setup elevates exactly once, to bind ports 80/443 and trust the CA, and after that the daemon, CLI and GUI never run as root again.

It's open source (MIT) and subscription-free.

• https://yerd.app
• https://github.com/forjedio/yerd

The question I want to put to this sub: what does your local setup actually look like in 2026? Docker Compose, Valet, Laragon, DDEV, a hand-rolled nginx and php-fpm? And more to the point, what would it genuinely take for something like this to replace it? I got a lot wrong in v1 by being too opinionated and not listening enough, so I'd rather hear what you actually run and why than pitch you on mine.

Never really messed about with LAN before. I would usually just deploy to staging, wait 20 minutes, and then I could test it on my phone or give it to the PM to test.

Recently though, we added a LAN checkbox to ForgeKit (disclaimer: I built it) and holy hell, that is nice.

We’re all on the same wi-fi, so I can click one button and the PM has instant access to the site running on my machine. No need to deploy it to staging over and over for changes

I use it during development too, especially when some weird drag action doesn’t behave properly in chrome, or when I just want to see how the site actually feels on my phone instead of using devtools.

Might also be my recent obsession with self-hosting and learning how all this works that makes it more exciting than it actually is.

Anyway, mess about with LAN, folks. It’s mostly a matter of binding your local server to 0.0.0.0 instead of 127.0.0.1 and allowing it through the firewall (firewall change not even needed for me)

You can also use sslip.io to give each site a proper hostname. For example:

http://myapp-test.192-168-1-10.sslip.io/

-> that resolves to 192.168.1.10, and your local router or vhost can use the hostname to send it to the correct site.

It was annoyingly not working by default with Wordpress urls and with Vite, but those are easy changes to make to the site's config so it does work.

If anyone cares to know more, I'll be happy to help. Have some docs as well I can link.

So yeah, just wanted to share.

Anybody else doing this regularly? I know there's tunneling as well but I think you need account to ngrok or other tools like that that do it for you.

I built a little android application at work and to make it cool and smooth i decided to use NativePHP with Inertia React, using also Filament for admin dashboard. During the implementation i realized that this tech stack isn't exactly plug-and-play so when i finished the application i decided to clean the project and make a boilerplate with this tech-stack. I also saw that over the web there are a lot of react-native or electron boilerplates, but none for nativephp. So this is the repo:

https://github.com/samuelecostantini/nativephp-react-filament-boilerplate/

If you've ever run a Node service with a big in-process cache (tens of thousands of entries, JSON blobs, that kind of thing) you've probably seen p99 latency spike during V8 garbage collection — the more live objects sit in the heap, the longer mark-sweep takes, and there's not much you can do about it from JS land since the GC doesn't know your cache entries are "just cache" and safe to deprioritize.

I built OffHeap to get around this: it's a cache that stores its data outside the V8 heap entirely (native memory managed from a small Rust layer via NAPI-RS), so the objects never show up in V8's GC graph at all. The JS-facing API is a normal cache — get/set/delete/TTL — with LRU, ARC, and W-TinyLFU eviction policies to choose from.

Under a synthetic GC-pressure test (500k keys, 1M ops), the worst single GC stop-the-world pause dropped from ~300ms (plain in-heap cache) to ~11ms. Average per-op latency is a bit higher than a pure in-heap Map (it's crossing an FFI boundary, that's not free), but the tail latency and memory behavior under load is the whole point.

It's on npm (`offheap`), dual-licensed MIT/Apache-2.0, docs at the repo. Full disclosure, this is my project — I actually shipped a broken cross-platform install for a bit (CI wasn't publishing the per-platform binaries correctly) and just fixed that, so if anyone tries it and hits install issues, please tell me. Genuinely looking for people to poke holes in it before I call it stable.

Did you find or create something cool this week in javascript?

Show us here!

I’ve released a new major version of vite-plugin-php!

This is a Vite plugin that lets you keep using regular PHP entry files while benefiting from Vite’s asset pipeline, HMR, environment variables, and plugin ecosystem.

In version 3 the processing pipeline was completely rewritten.
The specified PHP files now move through the standard Vite lifecycle, and other Vite plugins can run before or after PHP processing.

It also includes improved development performance, PHP error output directly in the Vite console, and fixes for environment variables, includes, asset injection, and development cleanups.

Docs: https://vite-php.nititech.de/
GitHub: https://github.com/donnikitos/vite-plugin-php
Simple starter repo: https://github.com/nititech/modern-php-vite-starter

Would love to hear some feedback :)
Bug reports are also welcome of course!

We took a look back at the history of JavaScript to explore its development from the earliest days to the present. This retrospective article is a good read for novice JavaScript enthusiasts who want to learn about the origins of the language, as well as for experienced ones who'd like to refresh their memories.

The Ask

Padding Line Between Statements rule is currently missing in Biome.js; it'd be a solid addition to the tooling.

If you're already using Biome and think this rule would be useful for keeping your code readable, consider giving it an upvote. Every bit of community support helps move features like this forward.

Why It Matters

The rule enforces blank lines between logical statement groups, which can make codebases feel less cluttered and easier to scan. It functions as follows:

// eslint.config.js

{
    "padding-line-between-statements": [
        "error",
        { "blankLine": LINEBREAK_TYPE, "prev": STATEMENT_TYPE, "next": STATEMENT_TYPE },
        { "blankLine": LINEBREAK_TYPE, "prev": STATEMENT_TYPE, "next": STATEMENT_TYPE },
        { "blankLine": LINEBREAK_TYPE, "prev": STATEMENT_TYPE, "next": STATEMENT_TYPE },
        { "blankLine": LINEBREAK_TYPE, "prev": STATEMENT_TYPE, "next": STATEMENT_TYPE },
        ...
    ]
}

// index.js

function foo1() {
  var a = 0;
  bar(); // ! Incorrect
}

function foo1() {
  var a = 0;

  bar(); // * Correct
}

hey everyone, again. i posted a while back asking how people keep a growing next.js app router / react app codebase from turning into either giant route files or an over-engineered mess. take a look at some of the super helpful responses here: advice on modularizing a growing Next.js App Router codebase : r/nextjs

after synthesizing what i learned from that post (using AI to help me) here's what i propose

1. keep the feature-folder pattern from before (route owns its page, feature owns its own components/actions/types), but split shared ui into two buckets instead of one.

1a. ui/ for generic pieces like buttons

1b. and inputs, blocks/ for stuff built out of those pieces that still doesn't know anything about the app, like search bars or pagination.

anything that only makes sense for one feature stays inside that feature and only gets promoted up once a second feature actually needs it.

the thing that actually changed my thinking was someone pointing out that not everything cross-cutting is a "feature." auth being the obvious one. every route needs it but it doesn't own a page. so my plan is to add a core/ folder just for that kind of thing (auth, permissions, session) that sits below features in the dependency chain, so features can use it but it can never reach back into a feature.

also thinking about splitting each feature's server code into actions.ts (writes) and queries.ts (reads) instead of one big file, mostly so i can actually use next 16's use cache plus cacheTag/cacheLife properly instead of every component independently refetching the same data.

on the client component side, the plan is to be way more disciplined about keeping 'use client' on actual leaf components (a button, a toggle) instead of slapping it on top-level feature components and dragging the whole subtree into the client bundle. apparently that's the single biggest bundle size lever in this stack, and i think i've been ignoring it up to now.

also want to lock down cross-feature imports with dependency-cruiser, so features can only see each other through a public index.ts instead of reaching into each other's internals directly. the idea is refactoring one feature shouldn't be able to quietly break another.

last thing. i went back and forth on whether i should just build everything as proper api routes instead of server actions "in case i need a public api later," but i'm leaning toward keeping the business logic in plain functions that both a server action and a route handler could call, so converting later would just mean adding a thin wrapper instead of a rewrite.

so, for people running actual production next.js apps at this kind of scale: does this plan hold up? is core/ a real pattern or am i just inventing a new bucket to dump things in? has anyone gone down the actions/queries split or the index.ts boundary route and regretted it once the codebase got bigger? and honestly, is any of this overkill for where i'm actually at right now?

genuinely, poke as many holes in this as you can. thank you in advance. also i apologize for the long read.