5 ms·

Oh, holy crap, I'm stoked, as someone who has just started using LiveView after like too many years of single page apps... all I can say, is "oh fuck, did we ge

Oh, holy crap, I'm stoked, as someone who has just started using LiveView after like too many years of single page apps... all I can say, is "oh fuck, did we get it wrong." The experience is truly great. Also, LiveComponents are pretty awesome since they don't have their own process, just mount in existing LiveView, it makes 'em really easy to reuse and performant (at least from my experience so far). Writing UI code, in a language/environment that has first class support of pattern matching is like a dream for me. Seriously, pattern matching is sooo good when you don't have fucking classes and objects and bullshit "abstractions" in the way of your data. Also, if you took a stab at it before 1.5, try it again. This release has all the goodies to make it nice and documentation to go with it... I'm stoked to delete the phx.live generators I copy-pasta'd into my repo from phx master a couple weeks ago trying to get my bearings. Truly awesome work on this! Thank you so much. Also, pro-tip, use the generators at least once, even if you have already used live view without 'em, because now there's more or less an official pattern for how to organize yer live code and it really helps.

czbond 7y ago
I feel your pain on SPA's.... I feel like code velocity drops on small teams. What about LiveView/Phoenix made the process more enjoyable - let's call it 'less painful'?
- rubyn00bie 7y ago
  Oh, yeah, here we go: 1. Tooling, yeah, you gotta have node installed, but that's pretty much the last time you have to touch it. I'm not anti-node or anti-js by any means, but the tooling around them often turns me off. Getting to do front-end work without _having_ to think about 'em is a breath of fresh air. 2. Less duplication of effort. I don't need to define schemas twice... once in the "backend" and once in the "frontend" application. You don't think this is bad until you spend two hours adding a adding, removing, or changing a simple property to your application because you have to update the backend, the backend's api docs, its tests. Then on the frontend, adjust the schema, adjust the frontend tests, and finally see if it's working. 3. Faster iteration. I prepare a new context, and can immediately consume it in a view. Views are reloaded instantly when changes are made during development reducing the time it takes to get feedback and increasing how fast I get shit done. Also less duplication of effort REALLY helps here... 4. We (at least me) got S(F)PA idea totally fucking backwards. The idea isn't to make you're entire web site a Single Fucking Page Application, but to make individual (single) pages which NEED TO function like applications do so... Quintessential examples that do _NOT_ need an SPA: a fucking FAQ, about, or contact pages. In fact, having an "application" on top of them is more burden than not. 5. CSS is really powerful these days and provides a lot of what the 2008-2012 JS movement was trying to do. If I combine that, with being able to re-render only part of the page, I've got almost the entire flexibility of what SPAs offer with almost none of the complexity. 6. Going to a new page, and causing a page refresh, but totally knowing the next page isn't going to be broken because of the previous page's state. Page refreshes are awesome. Growing up on 28.8k that wasn't the case, but ever since I got above 10Mbps its really not something I ever even notice (though I do notice when pages are broken that shouldn't be because they're SPAs and not just fucking content). I could probably keep rambling but I'll stop here...
  - theonething 7y ago
    For point #2, it gets even worse if you're doing GraphQL. Another layer of data abstraction on the backend to update and worry about and another layer on the frontend as well (using Apollo, etc)

czbond 7y ago

I feel your pain on SPA's.... I feel like code velocity drops on small teams. What about LiveView/Phoenix made the process more enjoyable - let's call it 'less painful'?

rubyn00bie 7y ago
Oh, yeah, here we go: 1. Tooling, yeah, you gotta have node installed, but that's pretty much the last time you have to touch it. I'm not anti-node or anti-js by any means, but the tooling around them often turns me off. Getting to do front-end work without _having_ to think about 'em is a breath of fresh air. 2. Less duplication of effort. I don't need to define schemas twice... once in the "backend" and once in the "frontend" application. You don't think this is bad until you spend two hours adding a adding, removing, or changing a simple property to your application because you have to update the backend, the backend's api docs, its tests. Then on the frontend, adjust the schema, adjust the frontend tests, and finally see if it's working. 3. Faster iteration. I prepare a new context, and can immediately consume it in a view. Views are reloaded instantly when changes are made during development reducing the time it takes to get feedback and increasing how fast I get shit done. Also less duplication of effort REALLY helps here... 4. We (at least me) got S(F)PA idea totally fucking backwards. The idea isn't to make you're entire web site a Single Fucking Page Application, but to make individual (single) pages which NEED TO function like applications do so... Quintessential examples that do _NOT_ need an SPA: a fucking FAQ, about, or contact pages. In fact, having an "application" on top of them is more burden than not. 5. CSS is really powerful these days and provides a lot of what the 2008-2012 JS movement was trying to do. If I combine that, with being able to re-render only part of the page, I've got almost the entire flexibility of what SPAs offer with almost none of the complexity. 6. Going to a new page, and causing a page refresh, but totally knowing the next page isn't going to be broken because of the previous page's state. Page refreshes are awesome. Growing up on 28.8k that wasn't the case, but ever since I got above 10Mbps its really not something I ever even notice (though I do notice when pages are broken that shouldn't be because they're SPAs and not just fucking content). I could probably keep rambling but I'll stop here...
- theonething 7y ago
  For point #2, it gets even worse if you're doing GraphQL. Another layer of data abstraction on the backend to update and worry about and another layer on the frontend as well (using Apollo, etc)