4 ms·

I'm building a startup in my free hours using Phoenix Liveview. I can ship features in hours vs days thanks to the simplicity liveview gives me. ZERO react/JS n

I'm building a startup in my free hours using Phoenix Liveview. I can ship features in hours vs days thanks to the simplicity liveview gives me. ZERO react/JS nonsense. I back to writing server side rendered templates with for-free reactivity. Give it a try it's very productive

password4321 4y ago
The downside as I understand it is the extra work to manage UX for connections with high latency and/or going offline, correct?
- freedomben 4y ago
  Yes, the downside is basically offline. When offline the LiveView app doesn't work because it can't update it's DOM. A decent solution I've enjoyed is using Alpine.js. It fits very neatly into the LiveView philosophy and can do nearly all UI updating easily. It still minimizes the amount of JS you have to write but you get good client-side update behavior. High latency isn't an issue if you do it correctly by using the loading classes and what not so that the user knows they are waiting for some data to load. It's pretty much identical to a typical React SPA that has to show loading indicators while waiting for a JSON call to complete.
- a_bored_husky 4y ago
  You aren't suppossed to use LiveView for every interaction, only the ones that require the server to be involved somehow just like a regular SPA. For pure client-side interactions LiveView has some utilities like LiveView.JS or you can use a lib like AlpineJS.
- sergiotapia 4y ago
  To me that's a non-issue. How are you going to access a website without internet anyways? If you're talking about "slow" internet, then use Alpine JS to run truly client-side things in those very rare cases.
  - sph 4y ago
    Live View might still be applicable in some latency sensitive contexts: one of the first Live View demos was a server-side rendered animation hosted in US that played at a smooth 60 fps in Europe. There are very few problems Live View isn't good for, and conversely, there are very few problems client-side single-page application are necessary for.
  - password4321 4y ago
    These days the issue is mostly mobile clients, but even then offline support is unusual for sure.
- wstuartcl 4y ago
  Yes and no. It handles crappy connections ok -- it will auto reconnect as needed. As far as full offline -- it has interfaces to easily alert the user via UI that they are disconnected, however, just like 99.999% of non liveview apps when you are offline things start breaking (load just about any static page site and submit a form or navigate when offline).
benatkin 4y ago
You six months ago: "I hate Java. Can I use Kotlin without touching it whatsoever?" https://news.ycombinator.com/item?id=32037125 https://news.ycombinator.com/item?id=32037125 You realize that js and java are the native languages for the web and Android, right?
- anamexis 4y ago
  What is your point?
  - benatkin 4y ago
    Just to point out that "ZERO react/JS nonsense" is based on looking down on mainstream languages even after they've improved and even though the platforms use them.
    - buzzerbetrayed 4y ago
      It sounds like you’ve never used Liveview to me. There are many advantages to it besides just zero JS.
    - sergiotapia 4y ago
      I've used them enough to have my own informed opinion on the languages, frameworks and mentality in the ecosystems I talk about. We're both right -- because we both are sharing our opinions.
    - canadianfella 4y ago
      [dead]
    - 0x457 4y ago
      I mean... It's hard to find anyone who prefers Java to Kotlin for Android development. I know people who still have Java One backpack, and they would rather write Kotlin over Java any day. JavaScript...I didn't mind how quirky it is when it was SSR + a little jQuery for interactivity. nodejs, asset pipelines like webpack, React make me want to barf. They haven't improved at all. LiveView looks very interesting and I wish Phoenix/Elixir was an option for me.
cultofmetatron 4y ago
> ZERO react/JS nonsense. As someone who knows js really well, I love liveview's hooks system. the js interop is the bees knees and lets me save my js chops for where I really need it. Also, I can emit js events that get picked up server side and vice versa. ie: no having to write any ajax calls. My frontend can react to server events with very little boilerplate. Thats a WAY better proposition than merely zero js. PS: the frontend buildchain is esbuild so you get out of the box support for typescript.
- conradfr 4y ago
  But you don't get type checking as part of the build right?
  - sb8244 4y ago
    Correct. You could rig something up in probably 2-3 days if that was super important for you. I did manual typing at the edges and that sufficed for me.
    - conradfr 4y ago
      Well yes, not sure why I got downvoted, if I use a language called TypeScript it may be because I think type checking is important. Having to call tsc separately from my dev/watch process is not a good developer experience. Same as with ... dialyzer :) But for sure, that would decimate esbuild performances.
      - sb8244 4y ago
        I'm also not sure. I think it's an interesting point that you bring up. My comment on value is mainly one of "all or nothing". I think a manual typing at the edge is probably sufficient for most people. That said, you could implement all of your forms and events as structs or schemas and rig up a piece of the dev process to convert them into types. I think many in Elixir would view it as overkill so it hasn't been done afaik. But I also think it could be implemented very easily and then you'd have end to end typing.

password4321 4y ago

The downside as I understand it is the extra work to manage UX for connections with high latency and/or going offline, correct?

freedomben 4y ago
Yes, the downside is basically offline. When offline the LiveView app doesn't work because it can't update it's DOM. A decent solution I've enjoyed is using Alpine.js. It fits very neatly into the LiveView philosophy and can do nearly all UI updating easily. It still minimizes the amount of JS you have to write but you get good client-side update behavior. High latency isn't an issue if you do it correctly by using the loading classes and what not so that the user knows they are waiting for some data to load. It's pretty much identical to a typical React SPA that has to show loading indicators while waiting for a JSON call to complete.
a_bored_husky 4y ago
You aren't suppossed to use LiveView for every interaction, only the ones that require the server to be involved somehow just like a regular SPA. For pure client-side interactions LiveView has some utilities like LiveView.JS or you can use a lib like AlpineJS.
sergiotapia 4y ago
To me that's a non-issue. How are you going to access a website without internet anyways? If you're talking about "slow" internet, then use Alpine JS to run truly client-side things in those very rare cases.
- sph 4y ago
  Live View might still be applicable in some latency sensitive contexts: one of the first Live View demos was a server-side rendered animation hosted in US that played at a smooth 60 fps in Europe. There are very few problems Live View isn't good for, and conversely, there are very few problems client-side single-page application are necessary for.
- password4321 4y ago
  These days the issue is mostly mobile clients, but even then offline support is unusual for sure.
wstuartcl 4y ago
Yes and no. It handles crappy connections ok -- it will auto reconnect as needed. As far as full offline -- it has interfaces to easily alert the user via UI that they are disconnected, however, just like 99.999% of non liveview apps when you are offline things start breaking (load just about any static page site and submit a form or navigate when offline).

benatkin 4y ago

You six months ago: "I hate Java. Can I use Kotlin without touching it whatsoever?" https://news.ycombinator.com/item?id=32037125 https://news.ycombinator.com/item?id=32037125 You realize that js and java are the native languages for the web and Android, right?

anamexis 4y ago
What is your point?
- benatkin 4y ago
  Just to point out that "ZERO react/JS nonsense" is based on looking down on mainstream languages even after they've improved and even though the platforms use them.
  - buzzerbetrayed 4y ago
    It sounds like you’ve never used Liveview to me. There are many advantages to it besides just zero JS.
  - sergiotapia 4y ago
    I've used them enough to have my own informed opinion on the languages, frameworks and mentality in the ecosystems I talk about. We're both right -- because we both are sharing our opinions.
  - canadianfella 4y ago
    [dead]
  - 0x457 4y ago
    I mean... It's hard to find anyone who prefers Java to Kotlin for Android development. I know people who still have Java One backpack, and they would rather write Kotlin over Java any day. JavaScript...I didn't mind how quirky it is when it was SSR + a little jQuery for interactivity. nodejs, asset pipelines like webpack, React make me want to barf. They haven't improved at all. LiveView looks very interesting and I wish Phoenix/Elixir was an option for me.

cultofmetatron 4y ago

> ZERO react/JS nonsense. As someone who knows js really well, I love liveview's hooks system. the js interop is the bees knees and lets me save my js chops for where I really need it. Also, I can emit js events that get picked up server side and vice versa. ie: no having to write any ajax calls. My frontend can react to server events with very little boilerplate. Thats a WAY better proposition than merely zero js. PS: the frontend buildchain is esbuild so you get out of the box support for typescript.

conradfr 4y ago
But you don't get type checking as part of the build right?
- sb8244 4y ago
  Correct. You could rig something up in probably 2-3 days if that was super important for you. I did manual typing at the edges and that sufficed for me.
  - conradfr 4y ago
    Well yes, not sure why I got downvoted, if I use a language called TypeScript it may be because I think type checking is important. Having to call tsc separately from my dev/watch process is not a good developer experience. Same as with ... dialyzer :) But for sure, that would decimate esbuild performances.
    - sb8244 4y ago
      I'm also not sure. I think it's an interesting point that you bring up. My comment on value is mainly one of "all or nothing". I think a manual typing at the edge is probably sufficient for most people. That said, you could implement all of your forms and events as structs or schemas and rig up a piece of the dev process to convert them into types. I think many in Elixir would view it as overkill so it hasn't been done afaik. But I also think it could be implemented very easily and then you'd have end to end typing.