floodfx

Understanding LiveViews as a concept could make it easier to commit to learning a new language. I am not saying one should but that one could and it would probably be easier since you don't have the additional overhead of also learning what is a LiveView.

I think it is more exciting and more innovative to think about LiveView as a new architectural approach to building reactive applications. Yes in Elixir land it is a Process and there are some amazing things about the BEAM. But LiveViews have the potential have an impact beyond just the Elixir ecosystem and folks should embrace that.

I’ve been a part of porting the Phoenix LiveView Protocol to both Javascript (https://LiveViewJS.com) and Go (https://github.com/canopyclimate/golive) backends and supported a friend that is porting it to Python.

Ironically I think taking LiveViews outside of Elixir could actually make it easier for folks to adopt Elixir-based LiveViews in the future.

There is a port of it to JavaScript/Typescript. https://LiveViewJS.com

It uses the same front end javascript from Phoenix and speaks the same protocol.

Note: am author

LiveViewJS[1] might be of interest. Same protocol as Phoenix LiveView with a JS/TS server implementation.

I was looking for something else after years in React ecosystem and came across Phoenix LiveView but I wanted to write in Typescript.

(Note: Am author)

[1] - https://LiveViewJS.com

Same. Aero press for last decade or so. Ethiopian light roast ftw.

Cool. We went with re-using/adopting Phoenix's because it is battle-tested and allowed us to not have to rebuild/find edge cases on browser event handling and DOM morphing and optimizing diffs. If you ever want a walk through lmk.

Great to see another language adopting LiveView! (Author of LiveViewJS[1] here).

Are you using Phoenix’s javascript client (and protocol) or rolling your own?

[1] - http://LiveViewJS.com

If you are looking for server-side rendering that enables rich, react-like user experiences, check out LiveViewJS (http://liveviewjs.com). Supports both Deno and Node runtimes.

(Full disclosure: am author)

I haven’t written Java or Kotlin in years but this makes me want to try it again. Nice work!

Curious how a string drive would perform on a mountain bike especially considering climbing advantages and easier shifting?

Check out https://liveviewjs.com

Hey thanks aloukissas!

> what would be the use for this

Ideally, to write LiveView applications in Typescript. :) This is early in development but as I mentioned above I think there are server technologies like DynamoDB and Redis that I plan to explore for scalable data stores.

I have not tried Deno and not my highest priority. I've added to the issues in Github. If you try it, would be great to update that issue with your results!

Well they did say "JS is ass". Happy to give them them the benefit of the doubt but I appreciate more obvious supportive commentary.

Very cool. I noticed you are writing your own client libraries? Curious if you've tried using the Phoenix client libraries? LiveViewJS uses the same libraries as a Phoenix LiveView app on the front-end.

I'll join your discord and we can chat more...

> (This video by Pragmatic Studio does an amazing job of explaining how LiveView works.)

I believe you are referencing this line from the README? FWIW - they have a free "starter course" which includes that video. I started on the free course and upgraded because I got a ton of value out of it and they are a small company doing great work.

To be clear, LiveViewJS has no affiliation with Pragmatic Studio. I am just a fan. :)

I'd highly recommend Pragmatic Studio's Phoenix LiveView Course - https://pragmaticstudio.com/phoenix-liveview

I wrote LiveViewJS while taking this course believe it or not.

Sounds like you've got some pretty good experience with both Typescript and Elixir. LiveViewJS could definitely benefit from that type of experience if you'd be interested in helping? I am definitely not an Elixir / Phoenix expert.

Hi flessner - I am a big Svelte fan myself! (And prefer JS/TS over Elixir.) Would love to see what you come up with in terms of fusing LiveViewJS / Svelte concepts. LMK if I can be helpful.

I can see you are angry and don't like JS. Perhaps you might be less angry if you look at the project and see that it is not an SPA architecture nor does it require or encourage client-side coding in general?

Maybe instead of shaking your fist, you might just celebrate the fact that we live in amazing times where even JS programmers can enjoy the LiveView programming paradigm! :)

Agreed on both fronts! I think there could be any number of different back-ends for Phoenix apps not just Elixir (Phoenix) and Typescript (LiveViewJS). One insight I had as I was building this is that Phoenix apps are actually based on a wire protocol and if that protocol was well-documented, you could see lots of different implementations across any number of languages. Would love to chat with Phoenix folks about that if interested...

hey tbranyen - happy to chat. my discord account is same as my handle here. :)

Nice work on diffhtml!

Agree that BEAM is great and very scalable. I guess I disagree with the notion that Redis and DynamoDB are "centralized" and "brittle". Rather both are distributed, robust, and, I would add, battle-tested.

I do like the idea of a Typescript to BEAM compiler but that is beyond my capabilities and interests. Maybe someone lurking here could do that?

Gotcha. I read the README and it wasn't clear to me that this is how Caldera works. Sorry about that.

I'll add that the API for implementing components in LiveViewJS follows the Phoenix API (mount => handleParams => handleEvent => render) rather than the React API.

Thanks for checking it out searchableguy. Tbh, I haven't run any performance/scaling tests just yet. :) I certainly don't expect it to be as performant or scale as well as BEAM right now and agree with your point that BEAM is particularly well suited for this paradigm.

That said, I think there are other server technologies to back LiveViewJS apps that may be able to scale out and perform just as well as BEAM including: Redis and DynamoDB. I plan to experiment with these in the near future.

Additionally, a big motivation for me was that I wanted to write apps in a language that I am very productive in (namely Typescript) which also has a large ecosystem and larger population of developers.

Lastly, in terms of other languages that I think could be well suited for this paradigm, Golang stands out (with channels and goroutines) but I haven't experimented with that yet.

Cool. LiveViewJS (and Phoenix LiveView) renders the initial HTML over HTTP but then connect to the server via a persistent web socket connection. Client events (clicks, form updates, blur/focus events, key events, etc) are then sent over the socket which kicks off a server-side state updates and rendering with only the diffs sent back over the web socket. These diffs are then merged with the existing dom. (Maybe TMI here but wanted to be clear this isn't just server-side rendering over HTTP.)

Hey hartator. I don't have deployed but there is a `npm run examples` that starts up a local server with nine different examples of various complexity (code in `src/examples`). Also there is a separate repo using LiveViewJS to implement a TodoMVC application - https://github.com/floodfx/todomvc-liveviewjs.

Yes but more than that you don't write any Elixir / Phoenix code. Check out the examples in the repo to see some code.

Homebound | Senior Front-end / Full-Stack Engineers | Full-time | Denver or Remote (US-only)

Homebound’s mission is to create a more delightful and efficient home building experience and we’re already delivering on that mission on places that need it the most: communities impacted by devastating natural disasters. We were founded after the Tubbs Fire [2] which destroyed thousands of homes in Sonoma, Napa, and Lake County, and threatened our CEO's home [3], and are deeply connected to the mission. We are also expanding into markets that are non-disaster markets.

Recognized by Forbes as #2 Great Startup Employer in Real Estate[4], Homebound is a "full-stack startup"[1] and the technology org builds software to make the home building process more modern, transparent, affordable, and rapid. The challenge and opportunity for engineers at Homebound is to build delightful experiences for a range of different types of users -- from homeowners to construction professionals. We are still a small (<25) tech org and are looking for key contributors who have both strong skills and also a passion for establishing best practices for our future Homebound teammates. We are dedicated to building a team based around three principals: community, craftsmanship, and communication.

We'd love to connect with mission-driven, quality-oriented engineers and engineering managers with strong written and verbal skills. . Email joinengineering@homebound.com or direct to me at donnie@homebound.com.

(Tech Stack: GraphQL, React, TypeScript, Postgres, AWS, SalesForce)

[1] - https://a16z.com/2015/01/22/the-full-stack-startup/

[2] - https://en.wikipedia.org/wiki/Tubbs_Fire

[3] - https://www.forbes.com/sites/samanthasharf/2020/01/16/she-al...

[4] - https://www.linkedin.com/feed/update/urn:li:activity:6775792...