Actually we do have some great PHP stuff coming up tomorrow! So stay tuned!
Yeah, killing PHP is like killing your grandpa! Come on man. Haha!
5 Likes
Any given Monday:
Wappler hires me as product manager.
The community that Thursday:
“I can’t choose PHP as server model. Where is it?”
Me:
6 Likes
NOTE TO WAPPLER CEO: DON’T HIRE JonL as product manager 
4 Likes
Mean while im lowkey hoping that happens so wappler staff ain’t spread so thin with everything they support haha
1 Like
Wait for the angry mob to appear.
Supporting multiple languages like ASP, .NET, PHP, and Node.js can make Wappler more versatile and accessible to a broader audience. For agencies/dev shops that work on projects for clients, this flexibility can be advantageous, as they can cater to diverse client requirements and technology stacks. However, this approach may not align with a developer-first mindset, as it introduces complexity in maintaining the tool and keeping up with updates in each language. Consequently, developers may be deterred from adopting Wappler due to the confusion and fragmentation caused by supporting different server models.
On the other hand, Wappler’s extensive choices can be overwhelming for users who simply want to build a web app and make it work. These users may not benefit from the support for multiple server models, as they are more likely to prefer a more streamlined, focused approach. The multitude of options might create a steep learning curve and hinder the adoption of the tool by those looking for a simpler solution.
All in all I think Wappler is still in the middle of identity crisis. Less than before as they have recently positioned themselves as a low-code tool instead of no-code which was the right choice IMO.
But still I think supporting different models just benefits agencies, not single users. The fact that some people find PHP easier is just due to familiarity and the myriad of CMS that were born in the PHP golden age.
But the fact that any other user other than dev shops would choose PHP over nodejs baffles me. If they love PHP so much and they are so familiar with it why not go the Laravel route and write PHP code? It makes no sense that they would choose PHP as server model if they are basically going to use an abstraction called Server Connect on top of it.
7 Likes
We’ve always used Windows servers since the 90s, they started of not so good but now they’re excellent (for us anyway…).
Leaving that massive debate aside I thought Id pitch in with our own example of what we do. We have specific applications that use ALL of the following on the same website: PHP, Classic ASP, a smattering of .NET and a bit of JavaScript thrown in - all easily configured through a PLESK CP.
Wappler allows us to not worry about whats going on with the server model. Now that were transitioning into NodeJS we can ditch the mix and match approach and have a much more integrated design, and no more updating nightmares we’ve seen in the past.
What happens if we fall out with NodeJS…? No problem, we switch over to PHP… or .NET … or GO (coming soon so I hear). Having Wappler in this equation means we no longer have to treat this as a concern. I suppose my ambling point is that it’s certainly nice to have that choice, it’s very potent to be empowered with the knowledge that whatever server model we choose will mean very little hassle once the initial Wappler learning curve has been dealt with - it’s a very worthy trade-off.
4 Likes
Indeed. Streamlining everything and choosing nodejs where possible makes a lot of sense. Being able to use the same language for the frontend and the backend is really a productivity boost. You also have 3rd party JS libraries that work on the browser and the server so once you learn it you can use it anywhere.
I can’t think of a lot of reasons in Wappler to fall out of nodejs given there is an abstraction on top of it. So it’s basically the same as choosing PHP but without all the cons.
I can only think of infrastructure reasons. Hosting cost/complexity has been brought up several times but I think that myth has been debunked the same amount of times that it’s been brought up.
But the identity crisis is still real. I guess with time it will all settle.
We’re on a dedicated server, however, our NodeJS is very easily managed through PLESK Obsidian, so I’m still always surprised when Io hear about hosting / pricing complaints. I think there’ll be greater take up once people realise how really straightforward it is.
2 Likes
At least we got App Connect 2.0!
4 Likes
If it only supported react and all recent gems like rsc(react server components) and rpc (remote procedure call, you write the function/method once and you call it from anywhere, be it backend or frontend), or type inference in trpc. Not to mention the rise of React Native with the upcoming rsc support and upcoming unified file-based router, so you write once react (native) and have it running on web and mobile (ios and android) with zero code rewriting.
Jon, do you want a hint in support of your words?
Change your Server Connect and bam get error notification on the frontend pages that use that API.
1 Like
Here is the hint - the PR on github count about 2 millions for TS/JS and only 100k for php https://twitter.com/orta/status/1572103371003408385
1 Like
Indeed. Those numbers tell a big story. Still you will find a bunch of people that will tell you that PHP is more popular than JS and bring up a chart of the percentage of public websites that use PHP.
Of course they leave out unknowingly or on purpose the fact that 40% of the public websites are wordpress blogs. So of course PHP runs the web. That doesn’t mean that it’s popular from a developer point of view.
Funny enough wordpress.com was completely rewritten in JS a few years ago 
So even Matt was aware of the shortcomings of PHP and jumped on the JS wagon. Even when 100% of Automattic devs were PHP experts…
3 Likes
But maybe the wappler auditoria is php focused, otherwise I can’t explain the php features in the last release and no js at all. If you were looking for graphql gems, g_qty on client and garph on server will give you the same features as trpc - type safety, type deferring, code completion, etc without needing schema and codegen https://twitter.com/ci_step/status/1630589041329545217
In the orm category, the https://twitter.com/DrizzleOrm is the hottest now with support to typesafe query building and automatic db migrations
1 Like
It’s called Flutter 
Why should I complicate myself with flutter, can you do SEO on flutter? Then, I would rather choose rust based tauri framework, at least you can compile for one more platform - desktop and even microsoft recently started to port some core feature in windows from c to rust. Have google, at least, ported some infrastructure/services to flutter?
That’s the same challenge as React, Angular, Svelte, Vue have… Can be solved on different ways, but that wasn’t my point, I was just joking around that Flutter (and other, e.g. Capacitor based) frameworks can run on Web and Mobile with zero code reqwriting.
1 Like
zero code rewriting was meant for non-native features