21 ms·

How Laravel Livewire works

116 points by clementmas 5y ago

montblanc 5y ago
Will we see a bit less SPAs and more of this? Rails has come up with Hotwire. ASP has something similar I think...only questions is what CTOs will make of this. And front end devs who are super used to doing SPAs won't like this change I fear.
- scns 5y ago
  Interesting the question you ask. I think neither matters. The users needs have priority IMHO.
- ckolkey 5y ago
  I hope so. We've been using Hotwire for a few months now, and I have only good things to say about it.
- kall 5y ago
  It took SPAs something like 5 years of popularity to get to a place where they are basically fine. I‘m thinking of things like routing, open new tab, back button working, back button state/scroll restoration, sane loading indicators, accessibility, keyboard interaction and feeling generally snappy+reliable. If a movie theater creates their website using next.js today, I probably won‘t notice or mind. A few years ago, when that kind of website went SPA, it made me shudder. If this style gains traction, are we in for the same range of teething issues for a few years?
  - mcintyre1994 5y ago
    This is definitely a good point. FWIW I think some of these became issues because SPAs were re-inventing a lot more than what these systems are. These are still server-rendered pages so they should feel more like that than they do an SPA, generally. On routing, I know Phoenix LiveView for instance does have a way to do navigation over the websocket but I don't know enough about it to know if it makes the same mistakes/introduces the same issues that SPAs did. Looking at this article though I'm guessing the Laravel Livewire one doesn't address routing at all (because what would you hydrate on the server?) and you'd be routing in a normal server-rendered way.
  - di4na 5y ago
    Phoenix liveview already handle most of these. 1) Routing is handled 2) open new tab is not handled maybe, i am not sure what the problem is 3) back button work on phoenix liveview, we just use the normal push 4) back button state restoration is easy, it is made for it 5) scroll restoration depends of what you did 6) Sane loading indicators are built in and introduced already 7) accessibility is a non problem, this is just normal HTML, not generated div that create a mess 8) keyboard interaction are better than default SPA but probably could be better ? Idk 9) Feeling snappy/reliable... well idk, i feel it is far better than SPA already, but we will see long term
    - mcintyre1994 5y ago
      > 2) open new tab is not handled maybe, i am not sure what the problem is If you middle click (or right click > Open in new tab) a link on HN then it'll open that link in a new tab. Loads of SPAs break this and it's really annoying if you're used to using it. I'm not sure if Phoenix live navigation helpers break it or not, do you know?
      - di4na 5y ago
        They would probably not break it, i would have to check, but it is just a `a` link under the hood. You may lose some of the state, depending of how much the url and backend store.
    - kall 5y ago
      That's good to hear. I did not mean to say these are actual problems, since I have never used these tools, only that a new approach needs some care. As long as you don't take over routing most problems fall away. Once you do, it becomes harder. Examples like multi-level routing with tabs/subtabs. If I "open in background tab" the "Performance" tab inside the "Mobile" tab, will it work (e.g. send me to myapp.com/admin/mobile/performance)? Just out of ignorant curiosity, if I "open in background tab" from a LiveView app, will I get the same server state session or a fresh one?
      - di4na 5y ago
- danjac 5y ago
  Probably too much sunk cost at this point, especially with bigger companies who are deeply invested in SPA and developers who have only ever worked with React or other SPA frameworks. Where I see it taking off are places which don't yet have a CTO you need to convince: early stage startups or small companies who need to move more quickly, reduce maintenance and bug overheads and don't have the cash for a multi-disciplined team.
Errancer 5y ago
How similar is this thing to the Phoenix.LiveView?
- cute_boi 5y ago
  i think livewire is just a port of Phoenix LiveView for laravel ecosystem.
  - ecmascript 5y ago
    Not really, Liveview uses websockets and Livewire uses http. So there is quite a big underlying difference
    - montblanc 5y ago
      Not sure what the OP is asking - if he's asking what kind of API or abilities they give you I would say pretty much equivalent things. If he's asking what the underlying architecture is then I yes they're different.
      - mcintyre1994 5y ago
        The server-side process in LiveView does enable some things that I don't think this does, like multiplayer games, collaborative apps and anything where you can have data/events made available to the client that doesn't originate from that client. One of the nice things with LiveView IMO is that it makes all of that work in the same programming model as the client sending things to the server and getting responses. It doesn't matter if the event originated from the client, some other client or eg. Phoenix Pub/Sub, it all looks and works the same.
- mcintyre1994 5y ago
  It's very different after the initial render. LiveView creates an Elixir process for each client which holds all of the necessary state, and then the client uses websockets to send requests and receive responses from that process. There's no rehydration done on the server-side, the state is kept in memory (by default. You can delete parts of it from memory but then you have to re-fetch it if you need it again). Requests and responses are absolutely tiny and you don't have to trust the client to send the current state, only the operation it wants to perform. It looks like the PHP version uses AJAX requests instead, but most importantly it doesn't persist any state on the server continuously. And then it looks like client requests send the current state, as well as checksums etc. to keep it secure. Then the server spins up a new instance of the class, hydrates it with the current state, runs the requested operation and returns the dom patch. It looks like LiveView has much smaller requests/responses and both client and server do much less work. But the tradeoff of that is that you have lots of Elixir processes, which I guess pretty much only works with something like the BEAM. And you have to be careful about memory because those processes all hold a client's state. If you want to display a page of database results then that's fine but you'll want to clear them from the state instead of keeping them in memory for as long as the user is on the page. And of course then you're going to lose some performance if you need that data again for a future operation by the client. The Livewire approach doesn't force you to think about that, you don't have the choice to hold the state in memory.
dncornholio 5y ago
As a Laravel user, I still avoid Livewire like the plague. Way too much 'magic' and it's not solving any of my real problems. I don't want to waste time learning Livewire because I really don't need to. Same goes for Laravel Breeze, Jetstream, Inertia, i'm sure they're great but I don't need any of it and they are becoming a thing that gets in the way more and more..
- moray 5y ago
  I totally agree and I hope they will remain external packages. My workflow does not use/require any of them and I am happy as it is. What it looks like Livewire is trying to solve is having a "reactive" way of doing things without touching javascript and by elimintating the need of implementing an API. I understand the need of consolidating the dev process to one single language and siplify it but there is a reason why we separate backend and frontend.
  - dgb23 5y ago
    I went down the rabbit hole of trying to minimize client side JS usage for web applications and interactions on websites with these kind of paradigms. I understand where it comes from and at first seems like a good idea. I tried prototypes, different libraries, tried to roll my own solutions etc. What I found is that this is a good idea in _some_ contexts, namely if you can and want to treat the browser as a rendering engine for state snapshots. If you break with that assumption, you want something else, or you'll be slowly creeping into an ad-hoc, complicated mess, where there is no clear abstraction boundary for the UI. You just end up smearing it all over your code. There are some fundamental reasons for this. A technical one is that HTML isn't just data representation. It also dominates the shape of your UI tree. Do we really want to complect these things? The separation between HTML, CSS and JS is extremely leaky and blurry. The more you try to pull them apart, the more painful it gets. It's also the ultimate de-normalization of your data. Meaning it's going to be a huge PITA to coordinate if its not done in one coherent place. Another issue is that you are breaking a separation of concerns and encapsulation. Does the server really have to know how I just toggled a menu, rearranged some widgets with drag-n-drop or switched a stylesheet? Trivially no. The server might care about some of that happening after the fact, but almost never about the details of how. But this gets even more pronounced when you implement features touching on security, consistency and reliability. With a clearer UI and server separation you have two distinct mental models or modes. On the front-end you only care about the user experience and optimize for that: Immediate feedback, guiding messages, visualization and transitions. You can treat the user as your best friend and fulfill all of their wishes. But on the server you treat them as an incompetent stranger and/or as and adversary. Because, you know, its the Web! With this separation you enable focus and avoid mental taxation mixing things up. It's ultimately a simplification in the pure sense of the word. With all that said, I don't doubt that many find this paradigm useful, especially because of what you said in your last sentence. And I'm sure that in many cases you can work around the problems I mentioned, or even model them well if you don't break with the assumption I mentioned at the start. But if you do anything interesting _in_ the browser you'll likely be forced to patch over the fact that you are now smearing your front-end logic all over places.
clementmas 5y ago
I'm really into the idea of HTML over-the-wire, with Blade templates and PHPUnit tests. No need to split the logic between the backend and the frontend. However I still need SPA navigation and although there's a Turbo adapter [0], it looks like more of a prototype at the moment. [0] https://github.com/livewire/turbolinks https://github.com/livewire/turbolinks
submeta 5y ago
This is great. It inspired many frameworks to come up with similar solutions. Here is one for Python/Flask: https://pypi.org/project/Flask-Wire/ https://pypi.org/project/Flask-Wire/
- anaganisk 5y ago
  Didn’t Phoenix start this trend like years ahead?
mands 5y ago
For Django users, see https://www.django-unicorn.com/ https://www.django-unicorn.com/ - which is pretty much a port of LiveWire.
- decide1000 5y ago
  That's amazing!
- zurtri 5y ago
  I have used Livewire in the past and am building stuff in Unicorn these days. Unicorn is well on its way to being really good. It is easy to use and integrates with Django well.
Najtmare 5y ago
Is this comparable in any way to Hotwire/Turbo? Is anyone actively using it in production?
michaelanckaert 5y ago
I recently started using htmx (https://htmx.org/ https://htmx.org/) in combination with Django and have become a firm believer of sending HTML 'over the wire' instead of JSON structures that then get used client side.
- dzonga 5y ago
  yep and thanks to /u/recursivedoubts for delivering an excellent package. I use htmx then mithril for those pages that really need client side interactivity. and it's refreshing.
- SPBS 5y ago
  From https://htmx.org/ https://htmx.org/: > Why should only <a> and <form> be able to make HTTP requests? > Why should only click & submit events trigger them? > Why should only GET & POST be available? > Why should you only be able to replace the entire screen? I love their motivation points, but do you really need 11kb of gzipped js to do this? At that point it's almost like a frontend library itself (mithriljs is only 9.5kb gzipped).
  - recursivedoubts 5y ago
    You can tear out some of the stuff (sse support, web sockets) and shrink it ~2k. Do away with the events mechanism and extension points, knock down the configuration options, drop IE support and probably get it down to around 6 or 7k. It could certainly be smaller, but to support things like CSS transitions and so forth it takes some code. I've tried to keep the power-to-weight ratio high by creating a rich events model and extensions mechanism to take pressure off the core library. My goal was to keep it under 10k, but I couldn't do it (I may pull SSE and WebSocket support out to try to tuck it under 10k again.) On the other hand, compare it with the average image on a website, and 11k isn't bad.
- guggle 5y ago
  Looks like what we used to do more than 15 years ago with taconite. I guess I'm now old enough to see history repeating in web development tools.
jjdeveloper 5y ago
I feel that the simplicity of just building on the server and pushing the updates across the wire is where we are heading. So a lot less double up, with regards needing to write both for the server and client. Validation especially will just need to be written once. Although I do feel Phoenix Liveview is a better option because they implement sockets. Also saw this update today they will allow you to trigger javascript on the client without the sever round trip, it's one of the things people get a bit stuck understanding. Generally they think to pop open a modal or menu requires a round trip to the server but really you should be using Alpine.js or similar for such things. This new pending update remove the requirement of needing a framework like Alpine. https://github.com/phoenixframework/phoenix_live_view/pull/1663 https://github.com/phoenixframework/phoenix_live_view/pull/1...
- tdrdt 5y ago
  I write a lot of apps in Blazor. And I also think this is where we are heading. Just write code in C# and it works. Unfortunately Blazor feels a step back compared to something like VueJs but I really like that I don't have to write JavaScript anymore.
  - Rapzid 5y ago
    I really like the Blazor tech, but with all the activity around Blazor WASM I'm not sure this is really where things are heading. It's neat that both options work with the same underlying tech(even if converting an app between the two wouldn't be so simple). I've built frontends in React and feel I have a fairly high level of expertise in VueJS; I actually got the sense that Blazor borrows quite a few ideas from VueJS. A major missing component IMHO is a good reactive state store like MobX..
  - y4mi 5y ago
    The idea isnt new though, GWT has been around since 2006 (the ancient Java version of writing the frontend code in Java, which is then served as JS to the client) I dont think we're going to go back to that anytime soon, the performance hit is just too big compared to a well written js implementation. To be fair, Blazor uses wasm, which is significantly better then the cross-compilation of GWT back then. nonetheless, the performance (esp. time to first render) is just not good enough for a lot of consumer facing apps It definitely has its niche though. Especially if you're able to cache the .net runtime that gets executed through wasm locally (PWA style)
pluc 5y ago
Laravel abstracted the PHP language enough that there are "Laravel developers" who cannot work without a framework. Now, these gems are going to do the same thing with HTML and Javascript! These tools are contributing to the lowering of code quality standards, regardless of their intentions or the rigidity of their coding standards. They're good tools once you understand how they work, but most of its users use it precisely so they don't have to.
- zanellato19 5y ago
  If you need to understand deeply how all your tools work to use them, they are not good tools. They serve to abstract knowledge into them. Can you imagine if you needed to understand exactly how a computer does math in order to use Excel?
- sbarre 5y ago
  Productivity always has side effects, and usually that comes in the form of abstracting away the plumbing to "ship stuff". For lots of working developers out there, "ship stuff" is their job, and you can't expect every single dev to understand the stack they work in end-to-end and to build their own plumbing each time, just for the sake of some ideal of knowledge. It's a straw man to say that frameworks "lower code quality standards". I would argue in a lot of cases it's the opposite and they help codify best practices for the 80% of web applications that are the same, instead of everyone having their own custom implementations of templating, event handling, auth, caching, etc... Would you rather have journeyman programmers building crappy templates and inefficient controller logic, or crappy auth systems and slow storage layers? Frameworks provide guard rails and let less skilled developers be more productive as they get better over time. One can hope that some will dig in under the hood to learn more, but if they don't, so be it. At least they're not building your auth system or rolling their own hashing libraries.
stanmancan 5y ago
I use Livewire quite extensively in production and it’s great. As someone that never got into Vue/React it has allowed me to build some pretty awesome and interactive UI’s.
- fraktl 5y ago
  Source: "Trust me guys."
_kyran 5y ago
Has anyone used both Livewire and Hotwire/turbolinks and can compare their experiences?
aasasd 5y ago
That title is a mouthful even when just subvocalizing it.
ch4s3 5y ago
I’m sitting at ElixirConf listening to Chris McCord talking about new features in Phoenix LiveView.
- mcintyre1994 5y ago
  Anything cool you can share? I'm looking forward to seeing the talks when they come out!
  - ch4s3 5y ago
    New heex functionality for html attributes and surface inspired slots. There are some JS interop improvements too.
earthboundkid 5y ago
Alpine.js is great. It is my goto for JavaScript now. It really hits the sweet spot.
louissm_it 5y ago
Awesome. I’m noticing a ton of “alternative” front end development tools these days: Hotwire, Stimulus Reflex, LiveView, Livewire, etc. However I don’t think javascript is the fundamental blocker. When people say they dislike building SPAs, they probably mean they dislike APIs and the whole circus of double validations, error catching, form handling and cache invalidations that come with a React/Vue SPA. Inertiajs[1] is a really solid middle ground of MVC goodness and client side interactivity. [1] - https://inertiajs.com https://inertiajs.com
clementmas 5y ago
Github repo: https://github.com/livewire/livewire https://github.com/livewire/livewire Website: https://laravel-livewire.com https://laravel-livewire.com

116 points by clementmas 5y ago

Will we see a bit less SPAs and more of this? Rails has come up with Hotwire. ASP has something similar I think...only questions is what CTOs will make of this. And front end devs who are super used to doing SPAs won't like this change I fear.

scns 5y ago
Interesting the question you ask. I think neither matters. The users needs have priority IMHO.
ckolkey 5y ago
I hope so. We've been using Hotwire for a few months now, and I have only good things to say about it.
kall 5y ago
It took SPAs something like 5 years of popularity to get to a place where they are basically fine. I‘m thinking of things like routing, open new tab, back button working, back button state/scroll restoration, sane loading indicators, accessibility, keyboard interaction and feeling generally snappy+reliable. If a movie theater creates their website using next.js today, I probably won‘t notice or mind. A few years ago, when that kind of website went SPA, it made me shudder. If this style gains traction, are we in for the same range of teething issues for a few years?
- mcintyre1994 5y ago
  This is definitely a good point. FWIW I think some of these became issues because SPAs were re-inventing a lot more than what these systems are. These are still server-rendered pages so they should feel more like that than they do an SPA, generally. On routing, I know Phoenix LiveView for instance does have a way to do navigation over the websocket but I don't know enough about it to know if it makes the same mistakes/introduces the same issues that SPAs did. Looking at this article though I'm guessing the Laravel Livewire one doesn't address routing at all (because what would you hydrate on the server?) and you'd be routing in a normal server-rendered way.
- di4na 5y ago
  Phoenix liveview already handle most of these. 1) Routing is handled 2) open new tab is not handled maybe, i am not sure what the problem is 3) back button work on phoenix liveview, we just use the normal push 4) back button state restoration is easy, it is made for it 5) scroll restoration depends of what you did 6) Sane loading indicators are built in and introduced already 7) accessibility is a non problem, this is just normal HTML, not generated div that create a mess 8) keyboard interaction are better than default SPA but probably could be better ? Idk 9) Feeling snappy/reliable... well idk, i feel it is far better than SPA already, but we will see long term
  - mcintyre1994 5y ago
    > 2) open new tab is not handled maybe, i am not sure what the problem is If you middle click (or right click > Open in new tab) a link on HN then it'll open that link in a new tab. Loads of SPAs break this and it's really annoying if you're used to using it. I'm not sure if Phoenix live navigation helpers break it or not, do you know?
    - di4na 5y ago
      They would probably not break it, i would have to check, but it is just a `a` link under the hood. You may lose some of the state, depending of how much the url and backend store.
  - kall 5y ago
    That's good to hear. I did not mean to say these are actual problems, since I have never used these tools, only that a new approach needs some care. As long as you don't take over routing most problems fall away. Once you do, it becomes harder. Examples like multi-level routing with tabs/subtabs. If I "open in background tab" the "Performance" tab inside the "Mobile" tab, will it work (e.g. send me to myapp.com/admin/mobile/performance)? Just out of ignorant curiosity, if I "open in background tab" from a LiveView app, will I get the same server state session or a fresh one?
    - di4na 5y ago
danjac 5y ago
Probably too much sunk cost at this point, especially with bigger companies who are deeply invested in SPA and developers who have only ever worked with React or other SPA frameworks. Where I see it taking off are places which don't yet have a CTO you need to convince: early stage startups or small companies who need to move more quickly, reduce maintenance and bug overheads and don't have the cash for a multi-disciplined team.

Errancer 5y ago

How similar is this thing to the Phoenix.LiveView?

cute_boi 5y ago
i think livewire is just a port of Phoenix LiveView for laravel ecosystem.
- ecmascript 5y ago
  Not really, Liveview uses websockets and Livewire uses http. So there is quite a big underlying difference
  - montblanc 5y ago
    Not sure what the OP is asking - if he's asking what kind of API or abilities they give you I would say pretty much equivalent things. If he's asking what the underlying architecture is then I yes they're different.
    - mcintyre1994 5y ago
      The server-side process in LiveView does enable some things that I don't think this does, like multiplayer games, collaborative apps and anything where you can have data/events made available to the client that doesn't originate from that client. One of the nice things with LiveView IMO is that it makes all of that work in the same programming model as the client sending things to the server and getting responses. It doesn't matter if the event originated from the client, some other client or eg. Phoenix Pub/Sub, it all looks and works the same.
mcintyre1994 5y ago
It's very different after the initial render. LiveView creates an Elixir process for each client which holds all of the necessary state, and then the client uses websockets to send requests and receive responses from that process. There's no rehydration done on the server-side, the state is kept in memory (by default. You can delete parts of it from memory but then you have to re-fetch it if you need it again). Requests and responses are absolutely tiny and you don't have to trust the client to send the current state, only the operation it wants to perform. It looks like the PHP version uses AJAX requests instead, but most importantly it doesn't persist any state on the server continuously. And then it looks like client requests send the current state, as well as checksums etc. to keep it secure. Then the server spins up a new instance of the class, hydrates it with the current state, runs the requested operation and returns the dom patch. It looks like LiveView has much smaller requests/responses and both client and server do much less work. But the tradeoff of that is that you have lots of Elixir processes, which I guess pretty much only works with something like the BEAM. And you have to be careful about memory because those processes all hold a client's state. If you want to display a page of database results then that's fine but you'll want to clear them from the state instead of keeping them in memory for as long as the user is on the page. And of course then you're going to lose some performance if you need that data again for a future operation by the client. The Livewire approach doesn't force you to think about that, you don't have the choice to hold the state in memory.

dncornholio 5y ago

As a Laravel user, I still avoid Livewire like the plague. Way too much 'magic' and it's not solving any of my real problems. I don't want to waste time learning Livewire because I really don't need to. Same goes for Laravel Breeze, Jetstream, Inertia, i'm sure they're great but I don't need any of it and they are becoming a thing that gets in the way more and more..

moray 5y ago
I totally agree and I hope they will remain external packages. My workflow does not use/require any of them and I am happy as it is. What it looks like Livewire is trying to solve is having a "reactive" way of doing things without touching javascript and by elimintating the need of implementing an API. I understand the need of consolidating the dev process to one single language and siplify it but there is a reason why we separate backend and frontend.
- dgb23 5y ago
  I went down the rabbit hole of trying to minimize client side JS usage for web applications and interactions on websites with these kind of paradigms. I understand where it comes from and at first seems like a good idea. I tried prototypes, different libraries, tried to roll my own solutions etc. What I found is that this is a good idea in _some_ contexts, namely if you can and want to treat the browser as a rendering engine for state snapshots. If you break with that assumption, you want something else, or you'll be slowly creeping into an ad-hoc, complicated mess, where there is no clear abstraction boundary for the UI. You just end up smearing it all over your code. There are some fundamental reasons for this. A technical one is that HTML isn't just data representation. It also dominates the shape of your UI tree. Do we really want to complect these things? The separation between HTML, CSS and JS is extremely leaky and blurry. The more you try to pull them apart, the more painful it gets. It's also the ultimate de-normalization of your data. Meaning it's going to be a huge PITA to coordinate if its not done in one coherent place. Another issue is that you are breaking a separation of concerns and encapsulation. Does the server really have to know how I just toggled a menu, rearranged some widgets with drag-n-drop or switched a stylesheet? Trivially no. The server might care about some of that happening after the fact, but almost never about the details of how. But this gets even more pronounced when you implement features touching on security, consistency and reliability. With a clearer UI and server separation you have two distinct mental models or modes. On the front-end you only care about the user experience and optimize for that: Immediate feedback, guiding messages, visualization and transitions. You can treat the user as your best friend and fulfill all of their wishes. But on the server you treat them as an incompetent stranger and/or as and adversary. Because, you know, its the Web! With this separation you enable focus and avoid mental taxation mixing things up. It's ultimately a simplification in the pure sense of the word. With all that said, I don't doubt that many find this paradigm useful, especially because of what you said in your last sentence. And I'm sure that in many cases you can work around the problems I mentioned, or even model them well if you don't break with the assumption I mentioned at the start. But if you do anything interesting _in_ the browser you'll likely be forced to patch over the fact that you are now smearing your front-end logic all over places.

clementmas 5y ago

I'm really into the idea of HTML over-the-wire, with Blade templates and PHPUnit tests. No need to split the logic between the backend and the frontend. However I still need SPA navigation and although there's a Turbo adapter [0], it looks like more of a prototype at the moment. [0] https://github.com/livewire/turbolinks https://github.com/livewire/turbolinks

submeta 5y ago

This is great. It inspired many frameworks to come up with similar solutions. Here is one for Python/Flask: https://pypi.org/project/Flask-Wire/ https://pypi.org/project/Flask-Wire/

anaganisk 5y ago
Didn’t Phoenix start this trend like years ahead?

mands 5y ago

For Django users, see https://www.django-unicorn.com/ https://www.django-unicorn.com/ - which is pretty much a port of LiveWire.

decide1000 5y ago
That's amazing!
zurtri 5y ago
I have used Livewire in the past and am building stuff in Unicorn these days. Unicorn is well on its way to being really good. It is easy to use and integrates with Django well.

Najtmare 5y ago

Is this comparable in any way to Hotwire/Turbo? Is anyone actively using it in production?

michaelanckaert 5y ago

I recently started using htmx (https://htmx.org/ https://htmx.org/) in combination with Django and have become a firm believer of sending HTML 'over the wire' instead of JSON structures that then get used client side.

dzonga 5y ago
yep and thanks to /u/recursivedoubts for delivering an excellent package. I use htmx then mithril for those pages that really need client side interactivity. and it's refreshing.
SPBS 5y ago
From https://htmx.org/ https://htmx.org/: > Why should only <a> and <form> be able to make HTTP requests? > Why should only click & submit events trigger them? > Why should only GET & POST be available? > Why should you only be able to replace the entire screen? I love their motivation points, but do you really need 11kb of gzipped js to do this? At that point it's almost like a frontend library itself (mithriljs is only 9.5kb gzipped).
- recursivedoubts 5y ago
  You can tear out some of the stuff (sse support, web sockets) and shrink it ~2k. Do away with the events mechanism and extension points, knock down the configuration options, drop IE support and probably get it down to around 6 or 7k. It could certainly be smaller, but to support things like CSS transitions and so forth it takes some code. I've tried to keep the power-to-weight ratio high by creating a rich events model and extensions mechanism to take pressure off the core library. My goal was to keep it under 10k, but I couldn't do it (I may pull SSE and WebSocket support out to try to tuck it under 10k again.) On the other hand, compare it with the average image on a website, and 11k isn't bad.
guggle 5y ago
Looks like what we used to do more than 15 years ago with taconite. I guess I'm now old enough to see history repeating in web development tools.

jjdeveloper 5y ago

I feel that the simplicity of just building on the server and pushing the updates across the wire is where we are heading. So a lot less double up, with regards needing to write both for the server and client. Validation especially will just need to be written once. Although I do feel Phoenix Liveview is a better option because they implement sockets. Also saw this update today they will allow you to trigger javascript on the client without the sever round trip, it's one of the things people get a bit stuck understanding. Generally they think to pop open a modal or menu requires a round trip to the server but really you should be using Alpine.js or similar for such things. This new pending update remove the requirement of needing a framework like Alpine. https://github.com/phoenixframework/phoenix_live_view/pull/1663 https://github.com/phoenixframework/phoenix_live_view/pull/1...

tdrdt 5y ago
I write a lot of apps in Blazor. And I also think this is where we are heading. Just write code in C# and it works. Unfortunately Blazor feels a step back compared to something like VueJs but I really like that I don't have to write JavaScript anymore.
- Rapzid 5y ago
  I really like the Blazor tech, but with all the activity around Blazor WASM I'm not sure this is really where things are heading. It's neat that both options work with the same underlying tech(even if converting an app between the two wouldn't be so simple). I've built frontends in React and feel I have a fairly high level of expertise in VueJS; I actually got the sense that Blazor borrows quite a few ideas from VueJS. A major missing component IMHO is a good reactive state store like MobX..
- y4mi 5y ago
  The idea isnt new though, GWT has been around since 2006 (the ancient Java version of writing the frontend code in Java, which is then served as JS to the client) I dont think we're going to go back to that anytime soon, the performance hit is just too big compared to a well written js implementation. To be fair, Blazor uses wasm, which is significantly better then the cross-compilation of GWT back then. nonetheless, the performance (esp. time to first render) is just not good enough for a lot of consumer facing apps It definitely has its niche though. Especially if you're able to cache the .net runtime that gets executed through wasm locally (PWA style)

pluc 5y ago

Laravel abstracted the PHP language enough that there are "Laravel developers" who cannot work without a framework. Now, these gems are going to do the same thing with HTML and Javascript! These tools are contributing to the lowering of code quality standards, regardless of their intentions or the rigidity of their coding standards. They're good tools once you understand how they work, but most of its users use it precisely so they don't have to.

zanellato19 5y ago
If you need to understand deeply how all your tools work to use them, they are not good tools. They serve to abstract knowledge into them. Can you imagine if you needed to understand exactly how a computer does math in order to use Excel?
sbarre 5y ago
Productivity always has side effects, and usually that comes in the form of abstracting away the plumbing to "ship stuff". For lots of working developers out there, "ship stuff" is their job, and you can't expect every single dev to understand the stack they work in end-to-end and to build their own plumbing each time, just for the sake of some ideal of knowledge. It's a straw man to say that frameworks "lower code quality standards". I would argue in a lot of cases it's the opposite and they help codify best practices for the 80% of web applications that are the same, instead of everyone having their own custom implementations of templating, event handling, auth, caching, etc... Would you rather have journeyman programmers building crappy templates and inefficient controller logic, or crappy auth systems and slow storage layers? Frameworks provide guard rails and let less skilled developers be more productive as they get better over time. One can hope that some will dig in under the hood to learn more, but if they don't, so be it. At least they're not building your auth system or rolling their own hashing libraries.

stanmancan 5y ago

I use Livewire quite extensively in production and it’s great. As someone that never got into Vue/React it has allowed me to build some pretty awesome and interactive UI’s.

fraktl 5y ago
Source: "Trust me guys."

_kyran 5y ago

Has anyone used both Livewire and Hotwire/turbolinks and can compare their experiences?

aasasd 5y ago

That title is a mouthful even when just subvocalizing it.

ch4s3 5y ago

I’m sitting at ElixirConf listening to Chris McCord talking about new features in Phoenix LiveView.

mcintyre1994 5y ago
Anything cool you can share? I'm looking forward to seeing the talks when they come out!
- ch4s3 5y ago
  New heex functionality for html attributes and surface inspired slots. There are some JS interop improvements too.

earthboundkid 5y ago

Alpine.js is great. It is my goto for JavaScript now. It really hits the sweet spot.

louissm_it 5y ago

Awesome. I’m noticing a ton of “alternative” front end development tools these days: Hotwire, Stimulus Reflex, LiveView, Livewire, etc. However I don’t think javascript is the fundamental blocker. When people say they dislike building SPAs, they probably mean they dislike APIs and the whole circus of double validations, error catching, form handling and cache invalidations that come with a React/Vue SPA. Inertiajs[1] is a really solid middle ground of MVC goodness and client side interactivity. [1] - https://inertiajs.com https://inertiajs.com

clementmas 5y ago

Github repo: https://github.com/livewire/livewire https://github.com/livewire/livewire Website: https://laravel-livewire.com https://laravel-livewire.com