[HN Gopher] Show HN: LiveViewJS - TypeScript back end for LiveVi...
___________________________________________________________________
Show HN: LiveViewJS - TypeScript back end for LiveView Apps
(Phoenix LiveView)
Author here. I really love the programming paradigm behind by
Phoenix LiveView applications and wanted to expand the ecosystem to
include programmers like myself that love Typescript. In summary,
LiveViewJS reuses all the Phoenix client code and implemented a new
backend in Typescript to handle client events and send back
updates. Lots more detail and examples in the repo. Would love any
questions and/or feedback. Thanks!
Author : floodfx
Score : 108 points
Date : 2022-02-11 16:22 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| tbranyen wrote:
| Hi floodfx, we should chat at some point if you're on
| slack/discord/etc. I'm building something extremely similar and
| there's potential opportunity to share some code/learnings.
| Personally I feel this design paradigm is the real web 3.0.
|
| My project is https://diffhtml.org/ and I have started
| experimenting with middleware to bridge to server and client
| workers: https://github.com/tbranyen/diffhtml/pull/251. For the
| server worker, it uses a WebSocket to ferry the VDOM diff
| patches, custom events, and property access/function calls. A big
| goal is to allow synchronous "main thread" access from workers,
| including on the server-side. This would allow you to write your
| UI code as if you were a client side app. It does this the same
| way as partytown using a SharedArrayBuffer and Atomics. You can
| see demo source code here:
| https://gist.github.com/tbranyen/2f5be81cfb7b3aa1bb443c8ef13....
|
| I've also toyed around with hot reloading components without the
| need for a pre-processor like Babel, and the results are hugely
| promising. Stateful live UI updates from saving a component file
| to seeing in the browser without all the fuss with complex build
| steps is liberating.
|
| I'm probably a few months out from having a usable beta, but I'm
| going to follow your project closely. Thanks for sharing!
| [deleted]
| floodfx wrote:
| hey tbranyen - happy to chat. my discord account is same as my
| handle here. :)
|
| Nice work on diffhtml!
| pawelduda wrote:
| I think the main reason original LiveView is so great is that it
| fits really well into the Erlang/Elixir/Phoenix ecosystem. Love
| to see the idea spreading though!
| floodfx wrote:
| 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...
| hartator wrote:
| Any live demos to play with? Good work.
| floodfx wrote:
| 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.
| 1_player wrote:
| Javascript is like Ice 9, it turns everything it touches into Ice
| 9.
|
| LiveView was invented not to have to deal with Javascript-powered
| SPA architectures and client-side coding in general, because JS
| is ass, and here's LiveViewJS to convert to Javascript a
| technology invented not to deal with Javascript.
|
| Gary Bernhardt warned us, yet no one listened. _shakes fist at
| cloud_
|
| https://www.destroyallsoftware.com/talks/the-birth-and-death...
| floodfx wrote:
| 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! :)
| spondyl wrote:
| For anyone curious about Ice 9:
| https://en.wikipedia.org/wiki/Cat%27s_Cradle
|
| > Ice-nine is an alternative structure of water that is solid
| at room temperature and acts as a seed crystal upon contact
| with ordinary liquid water, causing that liquid water to
| instantly transform into more ice-nine.
|
| A substance called ice-9, with basically the same properties,
| makes a passing appearance in the visual novel Zero Escape:
| Nine Hours, Nine Persons, Nine Doors if you haven't heard of
| the book but remember the term from somewhere else.
|
| Admittedly, that's where I first learned about it but that
| said, there is a real substance called Ice IX but it isn't as
| interesting
|
| https://en.wikipedia.org/wiki/Ice_IX
| searchableguy wrote:
| How is the performance and scaling story compared to live view?
|
| Live view works so well because of elixir and BEAM. The same
| model may not translate well to other languages depending on
| their concurrency and recovery pattern. There are also many
| optimizations in BEAM for keeping latency consistent over
| throughout alone which is important for live view applications.
|
| I also wonder if it will be possible to have push only live view
| application. One of the reasons for this is you can use server
| events instead of sockets. It would be cool for building
| visualization or showing metrics from backend.
|
| Awesome job all around. I love the examples folder.
| floodfx wrote:
| 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.
| mrkurt wrote:
| It's going to be hard to get close to BEAMs scaling story. I
| think you could build something on top of, like, nats.io and
| get similar scaling semantics. But centralized DBs are
| brittle for this kind of platform. Redis and DynamoDB are
| great ... just not for this.
|
| This is extreme and maybe true. The best way to make
| TypeScript scale like BEAM might be to build a TypeScript ->
| Beam compiler. :D
| floodfx wrote:
| 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?
| evol262 wrote:
| They're not brittle when running -- they're brittle
| if/when there's a failure.
|
| Bringing a Redis cluster back up is either "start each
| node in exactly the right order", "wait 10+ minutes", or
| "establish quorum yourself". Ten minutes can be a really
| long time in production.
| darnfish wrote:
| Reminds me a little of https://github.com/calderajs/caldera-react
| floodfx wrote:
| 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.)
| forgotmyoldacc wrote:
| It sounds like you're describing the same thing:
| https://github.com/calderajs/caldera-react
|
| > Think of it as the Node.js analog to Phoenix LiveView --
| all of the application logic (including rendering) runs on
| the server, and DOM updates are sent to the client in real-
| time.
| floodfx wrote:
| 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.
| interactivecode wrote:
| I always thought the react programming model could solve most
| criticisms perfectly with a built in liveview style server part
| [deleted]
| lucis wrote:
| I appreciate projects like this, as LiveView brings some amazing
| solutions to the game, but I'd guess that even if it was
| "feature-complete", I would still miss the so many great stuff
| about the BEAM/Elixir.
|
| Although, the safety of Typescript is the only thing that stops
| me from building my next hobbie/side-project with Elixir. After
| you get the benefits from the type system (specially in the TS
| ecosystem), it's hard to go back.
|
| Looking forward to see where the project goes!
| flessner wrote:
| I tried Phoenix LiveView recently and it feels really refreshing.
| In comparison to Svelte (my preferred tool usually) it feels
| oddly similar like it occupies the same idea with a completely
| different execution.
|
| I personally prefer JS over Elixir and having everything in one
| language also makes everything easier... maybe there is also a
| future to fuse some of these concepts into Svelte (I will have to
| experiment :D )
| floodfx wrote:
| 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.
| pablodavila wrote:
| I want to use Elixir more for my side projects but it's
| honestly really easy to get going with services like Vercel or
| Netlify and SvelteKit. Also coming from Next.js and SvelteKit,
| I got kind of used to the file-based routing and it creates
| some friction for me when trying to use Phoenix.
|
| I want to contribute some sort of guide to the community for
| people coming from JS metaframeworks, rather than Rails/MVC
| frameworks, but I feel like I need to use Phoenix more first.
| I'm just about finished with Sophie and Bruce's book!
| prophesi wrote:
| This is really cool! So basically instead of using LiveEEX
| templates, you can write it like a SPA with Typescript?
| floodfx wrote:
| Yes but more than that you don't write any Elixir / Phoenix
| code. Check out the examples in the repo to see some code.
___________________________________________________________________
(page generated 2022-02-11 23:00 UTC)