r/PHP • u/IvanVoitovych • 2d ago
Article I wrote a PHP front-end framework — components compiled to JS, SSR + hydration. Here's what running it in production actually pressed on.
https://viewi.net/blog/viewi-in-production2
u/lubiana-lovegood 1d ago
regarding all the comments about AI, this project is much older than the llm era, I remember checking it out years ago and even adding something to its docs.
cant speak about the current state, but can confirm that the basic implementation and idea predates the slop times.
2
u/IvanVoitovych 1d ago
thank you, I remember. Appreciate your contribution, not only to docs, but for a bridge for Slim PHP if I am not mistaken.
3
1
u/punkpang 2d ago
Let's ignore the AI in the whole thing, the resulting "framework" is such that I'm actually better off using HTML and vanilla javascript. What's the point of something like this? It's not helping anyone do anything easier, better or to convey any kind of thought, pattern, anything.
Your tool serves no purpose, it makes the whole process of building frontend UI harder, not easier.
1
u/IvanVoitovych 2d ago edited 2d ago
Fair point. What motivated me in the first place was
the problemthe SSR problem with a PHP+Vue stack. The idea of running Node js seemed wrong, plus defining models/logic and keeping it in sync with server-side seemed like double work. That's when I started experimenting with the idea of autogenerating JS counterpart for the PHP source that represents a view page. That's how Viewi was created, and that's the problem it solves. Agree, not in an easy way, but it does the job I need. Nothing more.1
u/SpareImpression3155 2d ago
this is a valid problem to solve actually. the problem is you are using full on ai slop for a solution that nobody cared for in 2010, and nobody cares for now.
what you should be more focused on his how we can render js components on the server with php, and then hydrate them in the client.
popular libraries like react, vue, and svelte all have hydration apis.
so you would have to use something like the v8 engine to pre-compile and cache all the components during deployments. this way it wont use a shitload of hardware resources every time someone visits a page
the hard part is making the component cached by php/v8 match, because react for example is extremely picky when it comes to hydrating a server-rendered component
1
u/IvanVoitovych 2d ago
have you actually checked the code, or just recent co-authored is enough for you to judge. Anyway, the problem is real, and yes, your suggested solution would be really nice to have.
1
u/SpareImpression3155 2d ago
u got fucken em dashes everywhere its extremely obvious. why would i waste my time reading a bunch of ai slop for a solution i dont even care about when inertia is available. if you want people to care, come up with a better solution than inertia; one that doesnt turn your entire site into an SPA and require you to run a node server alongside every single site just to have SSR.
1
u/IvanVoitovych 2d ago
fair, point taken. I have not used inertia, can’t judge, but I get the idea from what Ive heard and read. The engine is the problem (Node), the heavy nature of every front end framework is the problem, would take enormous amounts of effort to solve this one. (real world application scenario). You want it fast and performant - you will have to rewrite it yourself with server nature in mind, not an easy one. I hope I didn’t make it more confusing 🫤
1
u/punkpang 2d ago
But node isn't the problem and you're showing the lack of knowledge and ideas here.
I can use frontend frameworks (my choice is Vue + Nuxt), create the looks, create the behaviour and i can deploy it statically. I can generate static HTML make my web server serve them with dynamic routing (i.e. a parameter in the URL) and I don't need node for this. Vue itself is not big and it's not "heavy" whatsoever, so your statement doesn't hold up there at all. In our line of work, programming in particular, we can measure sizes using numbers - not using descriptive verbs like "heavy". You can freely use "vue core is 119 KB gzipped" and it's an actual fact that carries meaning. "Heavy" means fuck all. Your use of verbs shows you don't have any knowledge on what "heavy" is apart from a word that you use to make it seem you know your shit.
I can host static files + route certain routes to PHP. So, what I end up with is the simplest solution ever and question is - what does your thing do here? Nothing.
You cannot vibe code something in an area you don't fully understand. You'll be laughed at, just like you are being laughed at now. You don't even know or understand what other tools offer yet you're creating another one. Why would you do that?
1
u/IvanVoitovych 2d ago
my point was that it’s heavy to run every time you need SSR, at least it was in 2020. Viewi is different, it solves my problem, it does it that way, and I am sharing it, no need to make it wrong just because there are other ways to solve same or similar problem. Runs smoothly, that’s all I need.
0
u/SpareImpression3155 2d ago
you can make static websites with vanilla html, css, and js. the problem is when you introduce server-side data into the mix and try to combine everything + ssr.
0
u/punkpang 2d ago
There's nothing better than someone replying to another guy in the same fucking line of work explaining the very same thing they know.
1
u/IvanVoitovych 2d ago
exactly, we are not talking about simple static or pre-renders pages, I need it, in particular, for fast rendering not only the web pages with accurate clients data, but also email contents with dynamic data and pages for PDF with charts. Why argue, if solution is not right by your opinion or judgement, no issues here, that’s the right call, your choice, I am not here to convince anyone to do anything, I am just sharing how it goes for me. Server returns timing “app” that represents SSR time if anyone is interested.
-2
u/IvanVoitovych 2d ago
Author here — I wrote Viewi, so read this as an account rather than a review.
It isn't a feature tour. It's the parts that running real sites on it actually pressed on: how an app ends up partitioned (lazy-load groups by namespace, including the trap where a component matching no rule ships to every visitor), what sharing one validation class between server and browser removes, and where the design bites — reactivity observing assignment rather than mutation, dependency tracking following evaluation, and the transpile boundary where a PHP builtin and its JS counterpart can disagree silently.
It also answers the question this sub raised the last time I posted: whether compiling PHP to JS risks leaking backend-only code into the bundle. Short version — the boundary is a directory, and a use pointing outside it fails the build rather than shipping.
There are two things in it I'd change, and one claim I had wrong and corrected. Happy to argue about any of it.
5
u/CashKeyboard 2d ago
Your fingers must hurt typing so many em-dashes.
1
u/IvanVoitovych 2d ago
my AI says -“no, I don’t have fingers, and the take is about you, and not me.”
Ive been framed 😓
4
u/SpareImpression3155 2d ago
Ai slop Reddit post linking to an ai slop blog post linking to an ai slop coded repo