That’s all nice and cool, a sophisticated API wrapper for Electron. But should we do that? There so many better options for native apps then PHP. The biggest advantage of PHP, high concurrency, is not even a factor here. On top of that, Laravel is the most sluggish of all PHP frameworks. Stuffing your OS with apps like this does not sound reasonable to me and as engineers we should not write stuff like that.
Should "WE" do that? Its all depends on the contexts, I dun think there is any right or wrong is this matter. Cuz in the of the day: 1. Client does not care the technical as long as its work as intended 2. Business or dev team can be more manageable across many front especially small biz & startup 3. More or less it share the same motivation on how JS world try to do everything too BUT, technical wise, it is bloated & not efficient if you are building high performance desktop app. Again, its all depend on the contexts of who is "WE" in the conversation
@@simplisimp Although, you are of course right, I still partly disagree: About 1) All the more do us engineers have the responsibility to select proper technology. About 2) The pain of introducing new frameworks/languages is much less then the pain of sticking with only one. AND your team will thank you for the change - those that will not are better seen leaving the team anyways. About 3) I'm not a follower of the cult of JS, but node.js, esp. bun.js is superiour to PHP for most server related tasks.
@mrk131324 I would say my previous response main takeaway is the context of "WE." If the "we" is a well-fed team with generous amounts of time to work on, your statement of 1&2 is definitely the best choice. But, in the real world, there are a lot of configurations to define "we." Project such as NativePHP would be another option for other type of "we" out there to work on their project/product within their constraints budget, manpower, time, etc... 3. I never intend to compare PHP vs JS per say, cuz in the end of the day, each have their own use cases where they shine better than the other... again, the contexts are the key. But I believe we can agree JS FE scene is especially a big mess that gonna hunt dev back in the future (it already is tbh)
![9 UI Frameworks for .NET Desktop App Development [2024]](http://i.ytimg.com/vi/ze8o-Qa3v7Y/mqdefault.jpg)
Awesome video Bert 👏👏👏
Thanks 👍
Less stacks to use = more productivity 👏👏👏
This looks cool.
Thanks for watching, and yes it's kinda cool.
cant wait for this windows!
It’s Electron, so Windows is already supported.
@@mrk131324 oh really?!! is it available now for windows?
Livewire is love
Nice!
Thanks!
thanks a lot man!
You're welcome!
Wow
possible used nativePHP in windows ?
Currently only Linux/MacOS
nice
Thanks
Very interesting! How to build for use without execute php artisan...? Like a executable, opening with double click, its possible?
NativePHP is still in alpha. It’s not ready for production application yet. But I’m sure we’ll get there soon!
@@CodewithBurt Hello! Yes! Im found this command "php artisan native:build", but its not work on ubuntu.
Does it support raw Laravel project
Yes, it does. Livewire isn't that much different.
Please share the compiled file 😁
It will be outdated by now.
That’s all nice and cool, a sophisticated API wrapper for Electron. But should we do that? There so many better options for native apps then PHP. The biggest advantage of PHP, high concurrency, is not even a factor here. On top of that, Laravel is the most sluggish of all PHP frameworks. Stuffing your OS with apps like this does not sound reasonable to me and as engineers we should not write stuff like that.
It's cool, but I too don't have a use for it now, at this time.
On the other side, I think Laravel is one of the "go to" path out there.
Should "WE" do that? Its all depends on the contexts, I dun think there is any right or wrong is this matter. Cuz in the of the day:
1. Client does not care the technical as long as its work as intended
2. Business or dev team can be more manageable across many front especially small biz & startup
3. More or less it share the same motivation on how JS world try to do everything too
BUT, technical wise, it is bloated & not efficient if you are building high performance desktop app.
Again, its all depend on the contexts of who is "WE" in the conversation
@@simplisimp Although, you are of course right, I still partly disagree:
About 1) All the more do us engineers have the responsibility to select proper technology.
About 2) The pain of introducing new frameworks/languages is much less then the pain of sticking with only one. AND your team will thank you for the change - those that will not are better seen leaving the team anyways.
About 3) I'm not a follower of the cult of JS, but node.js, esp. bun.js is superiour to PHP for most server related tasks.
@mrk131324 I would say my previous response main takeaway is the context of "WE." If the "we" is a well-fed team with generous amounts of time to work on, your statement of 1&2 is definitely the best choice. But, in the real world, there are a lot of configurations to define "we." Project such as NativePHP would be another option for other type of "we" out there to work on their project/product within their constraints budget, manpower, time, etc...
3. I never intend to compare PHP vs JS per say, cuz in the end of the day, each have their own use cases where they shine better than the other... again, the contexts are the key.
But I believe we can agree JS FE scene is especially a big mess that gonna hunt dev back in the future (it already is tbh)
Okay smart guy. You don't like php. Whatever.