7 ms·

disclosure: I'm the biased author texas https://gitlab.com/dgmcguire/texas https://gitlab.com/dgmcguire/texas is a library that brings development back to the

by toolz 8y ago

disclosure: I'm the biased author texas https://gitlab.com/dgmcguire/texas https://gitlab.com/dgmcguire/texas is a library that brings development back to the server. You can integration test without headless browsers, get SPA-like UX without writing a line of JS and basically just write SSR apps with only adding a few lines of code to make you apps realtime and SPA-like. It works by leveraging persistent connections (websockets) first page load is entirely SSR and subsequent updates are SSR, but only by V-DOM diffing html fragments, sending only the minimum amount of patch data over the wire. Your apps will be faster, your development process will be faster with less code and removing all kinds of complex tooling. Here's a todoapp that does all rendering SSR https://warm-citadel-23442.herokuapp.com/ https://warm-citadel-23442.herokuapp.com/ - you can see just how fast it is even on a free tier of heroku - open it up in multiple clients and you'll see that all operations are realtime broadcasted too and believe it or not there's only like 3 lines of code you write to make that happen (plus all the code necessary to get a normal SSR app running)

Rovanion 8y ago
Hi, I just watched through the first two parts of your three part intro to Texas on YouTube. I noted that you restart the server process each time you make a change to the elixir application and coming from the Clojure universe I have the following question: Is it possible to insetad of restarting the server program each time you make a change to it's source code instead modify the program as it is running? This is usually how I work on my Clojure programs and I find that doing that which results in near instant feedback while I am programming.
- toolz 8y ago
  yeah, phoenix already has live-reloading included, I just probably hadn't setup the watchers properly or I was being dumb xD - it's pretty trivial to have everything setup to give instant feedback, though
hnzix 8y ago
Is Texas much different to Rails Turbolinks? Or is it like Turbolinks for Phoenix? PS I'm really happy that you called out "graceful degredation to an application that continues to function in the abscence of any JS.".
- toolz 8y ago
  very much different - turbolinks just uses AJAX to get a full rendering and replaces the body of the DOM with the response - texas can do realtime updates via pushing only patches (far less data over the wire) over a websocket
  - ksec 8y ago
    Given WebSocket is now supported in most browsers, I have been wondering why such technique hasn't been more widely used? I wish HN allows me to search through all the post I have viewed or favourite, I am pretty sure I asked a similar question or saw something similar with Rails. Edit: Found it. ( Not Really similar though) https://fie.eranpeer.co https://fie.eranpeer.co
    - toolz 8y ago
      very cool, yeah I think there are a few novel concepts that texas brings to the table, but I'm super excited to see more projects are trying to leverage persistent connections to make SSR viable again. I believe SSR is not only viable, but optimal given the right techniques. Hopefully texas is pursuing all the most optimal abstractions to make this work, and I think it is, but I'm excited to see more people thinking about this. Time will tell I guess!
mandeepj 8y ago
> but only by V-DOM diffing html fragments, sending only the minimum amount of patch data over the wire. V Dom is used by browser to update your page. The algorithm involved updates only the changed parts instead of the traditional way of updating the whole page. So, I’m not sure how ‘minimum data transfer over the wire’ is involved here. Can you please clarify? Not sure if you meant getting Json data from rest apis
- toolz 8y ago
  VDOM is just a concept that means representing the DOM in code. Texas keeps an elixir data structure representation on the server as a cache of client state and diffs against that. It then pushes a patch up to the clients that is used to update only the parts of the page that have changed
  - mandeepj 8y ago
    VDOM - virtual Dom, right ? > Texas keeps an elixir data structure representation on the server as a cache of client state and diffs against that. Sorry, I don’t think that’s scalable. And, in a load balanced environment, you have to have a central server for this purpose
    - toolz 8y ago
      not true at all. For one 99% of the time people on a realtime updated page will be viewing the same content meaning you can keep a local-only cache that all clients connected to that server can share...that makes the memory footprint negligible...we're talking maybe a few MBs on a typical webapp secondly as far as scaling goes you only need to broadcast extremely small messages (on the order of bytes, not kilobytes) across servers to tell clients to update themselves using their local caches it's extremely scale-able further texas only builds on top of HTTP semantics - meaning it can fall back to a stateless protocol at any point and the user won't even notice other than their app working a bit more slowly (but still working) for a few seconds while the websocket reconnects to a new node
fouc 8y ago
That demo on heroku loads shockingly fast for me. I see initial page load is 10kb for the html/css, and then the js loads in after. Nice.
fouc 8y ago
I see your library is for phoenix. This seems like a direct competitor to LiveView?
- toolz 8y ago
  well, considering liveview doesn't exist yet it's not a direct competitor just yet - but yes it'll be solving similar problems as liveview - although last I talked to chris he was taking a much different approach than I am in the implementation details.
da02 8y ago
Do you still use HTTP compression? Or is it not necessary since the data you are sending to the browser is pretty small most of the time?
- toolz 8y ago
  on the demo? No it's not using any compression - just got something working quickly one day to show off the library. The inner workings for the patch messages are undergoing a lot of reworking and I have plans to make different levels of compression available via configuration for the messaging protocol for the patches being pushed over websockets. This is a pretty young library though the first page load is just a typical SSR webpage though - so compression could be applied just as easily as any other SSR webpage
ngrilly 8y ago
That's interesting, but the latency is clearly perceptible between each action and the related screen update.
- toolz 8y ago
  Likely you're just located somewhere far from the server in Virginia, USA. If you watch the conference talk just a few minutes in I show a gif of the latency from Seattle to a server in California. Most interactions you can't tell at all.
- toolz 8y ago
  https://youtu.be/NWgwUKfR8Xg?t=1m48s https://youtu.be/NWgwUKfR8Xg?t=1m48s

by toolz 8y ago

Rovanion 8y ago

Hi, I just watched through the first two parts of your three part intro to Texas on YouTube. I noted that you restart the server process each time you make a change to the elixir application and coming from the Clojure universe I have the following question: Is it possible to insetad of restarting the server program each time you make a change to it's source code instead modify the program as it is running? This is usually how I work on my Clojure programs and I find that doing that which results in near instant feedback while I am programming.

toolz 8y ago
yeah, phoenix already has live-reloading included, I just probably hadn't setup the watchers properly or I was being dumb xD - it's pretty trivial to have everything setup to give instant feedback, though

hnzix 8y ago

Is Texas much different to Rails Turbolinks? Or is it like Turbolinks for Phoenix? PS I'm really happy that you called out "graceful degredation to an application that continues to function in the abscence of any JS.".

toolz 8y ago
very much different - turbolinks just uses AJAX to get a full rendering and replaces the body of the DOM with the response - texas can do realtime updates via pushing only patches (far less data over the wire) over a websocket
- ksec 8y ago
  Given WebSocket is now supported in most browsers, I have been wondering why such technique hasn't been more widely used? I wish HN allows me to search through all the post I have viewed or favourite, I am pretty sure I asked a similar question or saw something similar with Rails. Edit: Found it. ( Not Really similar though) https://fie.eranpeer.co https://fie.eranpeer.co
  - toolz 8y ago
    very cool, yeah I think there are a few novel concepts that texas brings to the table, but I'm super excited to see more projects are trying to leverage persistent connections to make SSR viable again. I believe SSR is not only viable, but optimal given the right techniques. Hopefully texas is pursuing all the most optimal abstractions to make this work, and I think it is, but I'm excited to see more people thinking about this. Time will tell I guess!

mandeepj 8y ago

> but only by V-DOM diffing html fragments, sending only the minimum amount of patch data over the wire. V Dom is used by browser to update your page. The algorithm involved updates only the changed parts instead of the traditional way of updating the whole page. So, I’m not sure how ‘minimum data transfer over the wire’ is involved here. Can you please clarify? Not sure if you meant getting Json data from rest apis

toolz 8y ago
VDOM is just a concept that means representing the DOM in code. Texas keeps an elixir data structure representation on the server as a cache of client state and diffs against that. It then pushes a patch up to the clients that is used to update only the parts of the page that have changed
- mandeepj 8y ago
  VDOM - virtual Dom, right ? > Texas keeps an elixir data structure representation on the server as a cache of client state and diffs against that. Sorry, I don’t think that’s scalable. And, in a load balanced environment, you have to have a central server for this purpose
  - toolz 8y ago
    not true at all. For one 99% of the time people on a realtime updated page will be viewing the same content meaning you can keep a local-only cache that all clients connected to that server can share...that makes the memory footprint negligible...we're talking maybe a few MBs on a typical webapp secondly as far as scaling goes you only need to broadcast extremely small messages (on the order of bytes, not kilobytes) across servers to tell clients to update themselves using their local caches it's extremely scale-able further texas only builds on top of HTTP semantics - meaning it can fall back to a stateless protocol at any point and the user won't even notice other than their app working a bit more slowly (but still working) for a few seconds while the websocket reconnects to a new node

fouc 8y ago

That demo on heroku loads shockingly fast for me. I see initial page load is 10kb for the html/css, and then the js loads in after. Nice.

fouc 8y ago

I see your library is for phoenix. This seems like a direct competitor to LiveView?

toolz 8y ago
well, considering liveview doesn't exist yet it's not a direct competitor just yet - but yes it'll be solving similar problems as liveview - although last I talked to chris he was taking a much different approach than I am in the implementation details.

da02 8y ago

Do you still use HTTP compression? Or is it not necessary since the data you are sending to the browser is pretty small most of the time?

toolz 8y ago
on the demo? No it's not using any compression - just got something working quickly one day to show off the library. The inner workings for the patch messages are undergoing a lot of reworking and I have plans to make different levels of compression available via configuration for the messaging protocol for the patches being pushed over websockets. This is a pretty young library though the first page load is just a typical SSR webpage though - so compression could be applied just as easily as any other SSR webpage

ngrilly 8y ago

That's interesting, but the latency is clearly perceptible between each action and the related screen update.

toolz 8y ago
Likely you're just located somewhere far from the server in Virginia, USA. If you watch the conference talk just a few minutes in I show a gif of the latency from Seattle to a server in California. Most interactions you can't tell at all.
toolz 8y ago
https://youtu.be/NWgwUKfR8Xg?t=1m48s https://youtu.be/NWgwUKfR8Xg?t=1m48s