This is 2021 and I actually was afraid of look into that new "Livewire" thing because I thought it was just ANOTHER Javascript framework, but OMG I was wrong. Thank you Caleb for that, you just save my life ♥
I remember one of the first web apps I made used heavily the jquery load function to load whole sections of content without refreshing, this is like seeing that but on steroids. Such a dope approach and with the blade syntax to rely upon makes is even better. Under 10kbs to make it all happen, incredibly impressive.
The use case, to start, is to quickly throw together secondary views so they appear dynamic. eg. Account, Profile, Billing, etc. and spare the Vue stuff for complex needs.
I like this idea very much. But I'm thinking that while using livewire I cannot share/re-use the same code for web and mobile app (because of separate class and blade file) which I can do using Vue.js for web-app. Most of the time we also write API endpoints for mobile apps and same code is shared to them which is being used for web-app in Vue.js. If I am taking it wrong please correct me. If we are only going to create a website then I will definitely like to try it.
@@kiiyaerick Well yea, i wonder if it would behave on init like a normal blade file so the parser will index a listing and after that go to js mode or something like that. How Nuxtjs does it with vue components. This would be a big plus for simple application to use livewire. (still have a modern feeling of having real time data changing with php but SEO friendly)
@@caspersrensen8693 Yeah depends! Managing WebSocket connections to perform view updates is good for todo apps, but I prefer writing Javascript (using the entire ecosystem built around JS) vs adding new machines to manage persistent socket connections.
@@ProgrammingwithPeter isn't that same? i like to keep the traffic on the backend low coz a simple apps don't need a backend server usually for most tasks
Sad? I am using it extensively on most of my new projects and it's plain awesome. Instant onboarding if you know Laravel and extremely powerful tool with very little limitations.
@@JethroYSCao its essentially developers giving up and settling for inefficiency. ever heard of gwt... was this build web apps in java thing. reminds me of it livewire is essentially developers saying, javascript is... something to learn. but we are tired of learning. so lets stick to what we know. instead of sending json like we do today in ajax requests they deal with html because thats easier to implement even though its inefficient. it is a functional product but in any serious projects, once it gets big enough sooner or later you will need to do javascript somewhere, so... they are essentially lying to themselves to put it off and hide away. In serious web development, Javascript is inevitable finally the laravel js intergration could have easily been accomplished with a little more effort. for example livewire sends all its requests to a single url end point and so you dont have to write routes. also you don't have to register components yourself and you can create components in terminal. and for some reason this is amazing to people. with a little effort you could get the same done with a js framework and developers lives would have been easier with the benefits of js. .... anyways enough rambling. livewire is an okay product. usable even. easy for newbies to misuse it as a javascript replacement instead of a tool to make ajax requests easier and end up making their apps extremely slow. but should be fine. hoping similar effort is made for laravel intergration with Vue
@@JoshuaKisb That's a missunderstanding, the point of the library is not to replace all JS with Blade, you still have to use JS in high interaction cases and the author talks about that in the presentation itself. The library is for low interaction components only.
@@JoshuaKisb You're wrong. Livewire has been nothing but exceptional. Your code remains in a single stack; no longer do you have to manage both, JavaScript and PHP. Livewire is used at a component level and can be nested. Livewire test suite follows those of PHPUnit. Each of your statements are repeating yourself and you are essentially saying javascript is good, Livewire is bad with no actual examples of pros/cons.
He eliminated 50% of front-end developers jobs.
Yeah now we can be 50% more sure the site'll work :P
Great talk! Livewire is THE thing that blow my mind this year
This is 2021 and I actually was afraid of look into that new "Livewire" thing because I thought it was just ANOTHER Javascript framework, but OMG I was wrong. Thank you Caleb for that, you just save my life ♥
One of the best talk I ever seen. Such an amazing work!
I remember one of the first web apps I made used heavily the jquery load function to load whole sections of content without refreshing, this is like seeing that but on steroids. Such a dope approach and with the blade syntax to rely upon makes is even better. Under 10kbs to make it all happen, incredibly impressive.
This is Insane man! Thank you!
I loved it... and I'm already studying. Tanks Caleb to share this with us.
Caleb is such a beast!
The use case, to start, is to quickly throw together secondary views so they appear dynamic. eg. Account, Profile, Billing, etc. and spare the Vue stuff for complex needs.
i really like this guy
What font was he using on the editor?
operator mono i guess
That`s a really nice idea!....
I like this idea very much. But I'm thinking that while using livewire I cannot share/re-use the same code for web and mobile app (because of separate class and blade file) which I can do using Vue.js for web-app.
Most of the time we also write API endpoints for mobile apps and same code is shared to them which is being used for web-app in Vue.js.
If I am taking it wrong please correct me.
If we are only going to create a website then I will definitely like to try it.
what code can you share to webapp when using vue?
I did like live wire but still thinking where i could put this on my projects.
More me replacing things like Datatables with this would be amazing. I hate the JS datatables.
@@kiiyaerick Well yea, i wonder if it would behave on init like a normal blade file so the parser will index a listing and after that go to js mode or something like that. How Nuxtjs does it with vue components. This would be a big plus for simple application to use livewire. (still have a modern feeling of having real time data changing with php but SEO friendly)
You can use livewire when you need some ajax interaction, but you don't want to bring vue/react to your stack
He explains at 5:23 when you can use livewire
3:54 liar! Your MacBook Time says it's 10:32pm
haha, nice idea, so fun :D
this is illegal. Im calling the authorities
Why did people laugh when the "embrace the backend" slide was shown? I am naive ;-)
The fruit looks like a human butt.
wow, i just know this
So basically webforms.
Classic case of over engineering.
In fact this is quite the opposite if you think about it :)
@@caspersrensen8693 Yeah depends!
Managing WebSocket connections to perform view updates is good for todo apps, but I prefer writing Javascript (using the entire ecosystem built around JS) vs adding new machines to manage persistent socket connections.
@@amanvirk it's not using websockets, they are sending requests for every update
@@ProgrammingwithPeter isn't that same? i like to keep the traffic on the backend low coz a simple apps don't need a backend server usually for most tasks
@@officialAXVin it's not the same, but you know, if github does it, it's not that bad
He's a good presenter but livewire is sad. So sad
Sad? I am using it extensively on most of my new projects and it's plain awesome. Instant onboarding if you know Laravel and extremely powerful tool with very little limitations.
Care to elaborate on why you say it's sad? I'm new to Laravel and PHP in general, so genuinely curious.
@@JethroYSCao its essentially developers giving up and settling for inefficiency.
ever heard of gwt... was this build web apps in java thing. reminds me of it
livewire is essentially developers saying, javascript is... something to learn. but we are tired of learning. so lets stick to what we know.
instead of sending json like we do today in ajax requests they deal with html because thats easier to implement even though its inefficient.
it is a functional product but in any serious projects, once it gets big enough sooner or later you will need to do javascript somewhere, so... they are essentially lying to themselves to put it off and hide away.
In serious web development, Javascript is inevitable
finally the laravel js intergration could have easily been accomplished with a little more effort. for example livewire sends all its requests to a single url end point and so you dont have to write routes. also you don't have to register components yourself and you can create components in terminal.
and for some reason this is amazing to people. with a little effort you could get the same done with a js framework and developers lives would have been easier with the benefits of js.
....
anyways enough rambling. livewire is an okay product. usable even. easy for newbies to misuse it as a javascript replacement instead of a tool to make ajax requests easier and end up making their apps extremely slow. but should be fine.
hoping similar effort is made for laravel intergration with Vue
@@JoshuaKisb That's a missunderstanding, the point of the library is not to replace all JS with Blade, you still have to use JS in high interaction cases and the author talks about that in the presentation itself. The library is for low interaction components only.
@@JoshuaKisb You're wrong. Livewire has been nothing but exceptional. Your code remains in a single stack; no longer do you have to manage both, JavaScript and PHP. Livewire is used at a component level and can be nested. Livewire test suite follows those of PHPUnit. Each of your statements are repeating yourself and you are essentially saying javascript is good, Livewire is bad with no actual examples of pros/cons.