3 ms·

Thank you! looking into it. I'm actually employed writing C, just wanted to dab into web on the side :)

amalgamated_inc 4y ago
Oh, cool :) Let me maybe elaborate why I like Phoenix, especially with LiveView. Traditionally in web dev, everything is centered around the HTTP request/response cycle. Browser sends a request to server, which renders a response page in HTML (or e.g. JSON if it's an API endpoint). This is very simple but has a bunch of mental overhead, since you need to fit every user interaction into this schema. It's also not well-suited for interactive pages like games, it really feels like a "website" not a "web application." Because of this, over the last 10 years, most companies/stacks have migrated to a frontend/backend split where the frontend is a SPA (single page app) typically written in JavaScript, using a rendering framework such as React. This allows you to do very interactive stuff and has enabled what we know as "web 2.0" with web apps as we know them. The downside is that you're now maintaining 2 code bases, you're learning two languages (or, worse, you're writing Node.js :) ), and you have to keep these 2 in sync. You've gone into the distributed systems business. The innovation of Phoenix LiveView is that everything happens on the server, and the server sends a diff back to a thin browser JS frontend that you almost never need to touch. So it feels simple and productive like an old-school web 1.0 app, except you don't even have to fit everything into the request/response cycle. Instead, there is a much simpler and faster "events happen -> you react to them -> re-render" cycle that doesn't require a page reload on the user's end. This allows you to make very interactive-feeling websites without all the ballast and overhead and headaches of maintaining a distributed systems and, frankly, touching JavaScript. As an example, check out this site I made with LiveView: https://livetyper.com/ https://livetyper.com/ There are certain limitations to this, it won't ever be as fully interactive as a locally-running SPA. But for anything but real games or maybe the most performance-hungry apps (think Figma), LiveView is totally fine and 1/10th the effort.
- startingout 4y ago
  Thank you so much. Cool website btw.
- Scarbutt 4y ago
  Curious, what don't you like about JS/node.js? Don't see much difference to Python or Ruby, it's mostly the same for doing the server part of web apps but with JS you have the advantage of using only language since you are going to need need at least some JS for the browser.
  - dang 4y ago
    Sorry for the offtopicness, but would you mind emailing hn@ycombinator.com? I would like to send you a repost invite.

Oh, cool :) Let me maybe elaborate why I like Phoenix, especially with LiveView. Traditionally in web dev, everything is centered around the HTTP request/response cycle. Browser sends a request to server, which renders a response page in HTML (or e.g. JSON if it's an API endpoint). This is very simple but has a bunch of mental overhead, since you need to fit every user interaction into this schema. It's also not well-suited for interactive pages like games, it really feels like a "website" not a "web application." Because of this, over the last 10 years, most companies/stacks have migrated to a frontend/backend split where the frontend is a SPA (single page app) typically written in JavaScript, using a rendering framework such as React. This allows you to do very interactive stuff and has enabled what we know as "web 2.0" with web apps as we know them. The downside is that you're now maintaining 2 code bases, you're learning two languages (or, worse, you're writing Node.js :) ), and you have to keep these 2 in sync. You've gone into the distributed systems business. The innovation of Phoenix LiveView is that everything happens on the server, and the server sends a diff back to a thin browser JS frontend that you almost never need to touch. So it feels simple and productive like an old-school web 1.0 app, except you don't even have to fit everything into the request/response cycle. Instead, there is a much simpler and faster "events happen -> you react to them -> re-render" cycle that doesn't require a page reload on the user's end. This allows you to make very interactive-feeling websites without all the ballast and overhead and headaches of maintaining a distributed systems and, frankly, touching JavaScript. As an example, check out this site I made with LiveView: https://livetyper.com/ https://livetyper.com/ There are certain limitations to this, it won't ever be as fully interactive as a locally-running SPA. But for anything but real games or maybe the most performance-hungry apps (think Figma), LiveView is totally fine and 1/10th the effort.

startingout 4y ago
Thank you so much. Cool website btw.
Scarbutt 4y ago
Curious, what don't you like about JS/node.js? Don't see much difference to Python or Ruby, it's mostly the same for doing the server part of web apps but with JS you have the advantage of using only language since you are going to need need at least some JS for the browser.
- dang 4y ago
  Sorry for the offtopicness, but would you mind emailing hn@ycombinator.com? I would like to send you a repost invite.