[HN Gopher] The future of web software is HTML over WebSockets
___________________________________________________________________
The future of web software is HTML over WebSockets
Author : jack_riminton
Score : 202 points
Date : 2021-02-25 18:10 UTC (4 hours ago)
(HTM) web link (alistapart.com)
(TXT) w3m dump (alistapart.com)
| hinkley wrote:
| I miss having beers with people.
|
| This whole saga feels like one of those things where "I've heard
| this story before, I think I'll sit this one out and hope it's
| not too long" situations.
|
| We all prioritize what tech we're going to spend our time on, but
| I think there's something qualitatively different between, "that
| could be interesting but I don't care", "That'll never work!",
| and, "I understand this enough to know it does not meet my
| criteria for job satisfaction, I'm out. Call me when the Trough
| of Disillusionment hits." So we come back
| around to Rails, 15 years on from its launch...
|
| I think turbolinks hit too close to the AngularJS launch, and got
| swamped. People who were trying to make everything happen with
| jQuery skipped straight to Angular. Now Elixir is trying to
| resurrect turbolinks-plus in Phoenix.
| dnautics wrote:
| frankly elixir allows you do far more than that. I am going to
| be working on enabling phoenix to serve its liveview over
| WebRTC (I _think_ it will be relatively easy); it is transport
| agnostic
| aphextron wrote:
| I know people loved turbolinks, but the very thought of it
| gives me nightmares. That kind of tight coupling between server
| side and client is everything the modern JS ecosystem evolved
| to get away from. I can see it being useful in a single
| developer full stack environment to get something up and
| running. But any kind of long term complicated application
| development in that paradigm just sounds painful.
| nickjj wrote:
| > I know people loved turbolinks, but the very thought of it
| gives me nightmares.
|
| Is it really that bad?
|
| With Turbolinks 5 (and its successor Hotwire Turbo Drive) you
| can do nothing except add 1 line of JS to your application
| and reap massive wins in terms of page transition speeds. And
| this all works without changing 1 line of code on the back-
| end and it works with all tech stacks.
|
| IMO it's the biggest bang for your buck that you can do to
| make a website feel good with the least amount of effort.
|
| And now with Turbo Drive you can do the same with form
| submissions without needing any back-end code and it also
| works with every tech stack with no special libraries or work
| to be done server side.
|
| Then Turbo Frames builds upon that to partially update a
| segment of your page and Turbo Streams introduces websockets
| for when you want to broadcast stuff or do real-time updates.
|
| It's a great system. Use HTTP for everything except for when
| websockets makes sense.
| DonnyV wrote:
| The problem a lot of developers have with SPA is that they
| literally shove the entire app into 1 page load. Which is where
| most of their problems come from. If you use a hybrid approach.
| Have the data you need to show the page right away cached in the
| html and then load any other data after while that page is being
| used. And you break the app up into multiple pages. It works
| perfectly fine. It actually makes it super easy to hand out work
| to a team of devs and minimizes stepping on each other.
| imbnwa wrote:
| Isn't this how Amazon.com gets developed?
| carapace wrote:
| This is just crazy.
|
| > Want a hyper-responsive datalist typeahead that is perfectly
| synced with the database? On every keystroke, send a query down
| the WebSocket and get back precisely the changed set of option
| tags, nothing more, nothing less.
|
| > How about client-side validations? Easy. On every input change,
| round up the form values and send 'em down the WebSocket. Let
| your server framework validate and send back changes to the HTML
| of the form, including any errors that need to be rendered. No
| need for JSON or complicated error objects.
|
| If you're not Google-scale this is just a good way to DDOS
| yourself, no?
| nom wrote:
| I gave the author the benefit of the doubt until I read this
| part. A request on every input change? Browser-side validation
| exists for a reason. Even at Google scale this leads to
| embarrassingly bad UX.
| c-linkage wrote:
| This seems like X Windows protocol over HTTPS with JSON as the
| wire encoding.
|
| It's sad to think how much effort is spent reimplementing
| technologies because the IPv4 address space wasn't large enough.
|
| If IP address space were larger, we wouldn't have needed to rely
| on Network Address Translation (NAT). NAT became a poor-man's
| firewall and effectively blocked peer-to-peer connections making
| it difficult to host a server at home. This incentivized early
| ISPs to offer only asymmetric connections that pushed users
| towards a consumer-only service that crippled early Internet
| protocols. With the World Wide Web being "the" reason people got
| on to the Internet in the first place, early NAT-enabled routers
| focused only on HTTP tunneling, so completed protocols that
| required inbound connections were finally killed off.
|
| Who would have thought that a small IP address space could result
| in a mass protocol extinction event from which only HTTP and HTML
| would survive....
| schpaencoder wrote:
| Couldn't agree more
| treve wrote:
| We are heavy into REST and HATEOAS. This, coupled with React SPAs
| has worked really well for us.
|
| The HATEOAS client we use/build has an cache/event system that
| will emit to subscribers (via react hooks) when a resource is
| stale, and needs to be refreshed.
|
| After putting this all in place, I realized that now I _just_
| need the server to emit those 'stale' events via Websockets, and
| suddenly my SPA + API is a real-time multi user system with
| nearly no changes required in either server or client.
|
| This made me wonder, why aren't we just always pushing the entire
| resource state over websockets. Use websockets to let clients
| indicate which resources they are interested in, and let the
| server keep pushing state back to the client.
|
| This solves a number of problems that plain HTTP has:
|
| 1. We can't really push/subscribe well. It's not very natural.
|
| 2. The HTTP cache kinda sucks, because we don't have programmatic
| access. Simple example: Doing a DELETE on a resource should
| expire the cache of the parent collection. There's a good HTTP
| header to indicate this, but no good way to tell the browser
| cache to delete the cache entry, so we end up building our own
| caching layer.
|
| 3. Compound requests suck because HTTP caches and clients don't
| understand them.
|
| But we can still keep using REST fundamentals. Things have URIs,
| features are discoverable, relationships are expressed with
| links.
|
| Something about this also feels terribly wrong though. Do we
| really want to reinvent parts of HTTP over websockets? HTTP is
| highly optimized, what kind of performance problems are we gonna
| run into?
| Tenal wrote:
| Coming from a game networking side, why wouldn't you want to
| embrace a WebSockets world for everything? The upsides seem so
| incredibly intuitive for someone looking at it from the outside
| of traditional web development.
| Nullabillity wrote:
| Traditional SQL databases aren't very streaming-friendly, so
| you more or less end up building an entire secondary push
| system just to figure out when to send what updates to who.
| munchbunny wrote:
| Mostly just the intuitiveness of the architecture. I don't
| need bi-directional if I'm mostly just showing you some forms
| in a CRUD app, and client-initiated request/response is
| simpler to reason about.
|
| Bi-directional gives you more power, but you also have to
| think harder about the protocol and application state once
| the server is also pushing events to the client unprompted.
| afavour wrote:
| Scaling is almost always the answer.
| mathgladiator wrote:
| Scaling not just technically either, it's also the
| engineers. Most Web engineers have had their minds bent to
| the request response model with databases.
|
| The key reason is that a game lasts... minutes to hours
| (ignoring most MMOs), so the state machine makes sense and
| the risk of failure low. Web devs have to use a database
| which has state for years.
| [deleted]
| clusterhacks wrote:
| Was your use of REST/HATEOAS mostly internal to your company or
| dev team?
|
| I ask because I rolled out a REST/HATEOAS api for a multi-org
| project and got zero uptake on the HATEOAS aspect of responses.
| The devs hardcoded URL resource links and totally ignored any
| links in responses . . .
|
| After that experience, I am always interested to hear about
| more successful REST/HATEOAS projects.
| mattlondon wrote:
| Wrangling with JSON?
|
| Not sure about React, but with Angular and tools like gRPC you
| don't see a single byte of JSON and the code that interacts with
| the APIs is automatically generated at compile-time and is type
| safe (with intellisense too!)
|
| It is pretty effortless these days IME. You can't make a mistake
| with the coding side of things calling an API as the actual
| mechanics is seamlessly hidden away - mistakes can only be made
| in the "business" side of things (and this HTML-approach won't
| save you there...)
|
| If you are using an "in house" framework (or just something
| ancient/niche like rails) then perhaps you don't benefit as much
| from modern bug-resistant frameworks and tooling I guess... In
| which case you're probably going to make more gains just by using
| a mainstream framework rather than trying something
| new/unusual/untested(?) like this.
|
| Good luck anyway!
| MentallyRetired wrote:
| `The dual approach of marrying a Single Page App with an API
| service has left many dev teams mired in endless JSON wrangling
| and state discrepancy bugs across two layers. `
|
| Umm... not it hasn't? Separating the backend from the frontend
| allows for multiple frontends on multiple types of delivery.
| Outside of edge workers, how is HTML-over-websockets supposed to
| compete with a good ol CDN (jamstack) on TTR?
| _query wrote:
| This approach definitely has a lot of value for specific use
| cases. Specifically to get MVP done in a fast way. When you need
| to scale out, you can still add a SPA later on.
|
| If you combine the approach of WebSockets + dom patching with
| postgres pg_notify you get some real magic :) In the new IHP
| framework we provide something like that. We call it Auto
| Refresh: https://ihp.digitallyinduced.com/Guide/auto-refresh.html
|
| Auto Refresh is activated with a function call inside a
| controller action, like this: action
| ShowProjectAction { projectId } = autoRefresh do
| project <- fetch projectId render ShowView { .. }
|
| The only difference to a normal IHP action is that it has the
| `autoRefresh` call in front of the do-block.
|
| Once activated IHP will automatically track all tables your
| action is using e.g. in `SELECT * FROM ...` queries. Once the
| action sends a response IHP will start watching for any kind of
| `INSERT`, `UPDATE` or `DELETE` statement to all the tables used
| by your action using pg_notify.
|
| When the page is rendered a small JavaScript function will
| connect back to the IHP server using a WebSocket connection.
|
| Whenever an `INSERT`, `UPDATE` or `DELETE` happens to the tables
| used by your action IHP will rerun your action on the server-
| side. When the generated HTML looks different than the HTML
| generated on the initial page load it will send the new HTML to
| the browser using the WebSocket connection. The JavaScript
| listening on the WebSocket will use the new HTML to update the
| current page. It uses morphdom to only touch the parts of your
| current DOM that have changed.
|
| Here's how this looks in the real world:
| https://twitter.com/digitallyinduce/status/13207288333943808...
| <- This view has no app-specific Javascript. The auto refresh is
| enabled using a single function call and the framework takes care
| of all the technical details.
|
| Some use cases where this really shines:
|
| - interactive dashboards (e.g. showing the current status of job
| queue)
|
| - simple user chat systems (you can send messages using normal
| form submission, as long as auto refresh is enabled this works
| like a SPA)
|
| - building a twitter clone, the feed will automatically add new
| content as it's added to the database
|
| We're using this approach in production since last year and it
| saves an incredible amount of development time.
| superkuh wrote:
| This is almost there. It just needs to go one step further and
| remove the websockets.
| bilekas wrote:
| This reminds me not of every proponent of new technology who
| can't get their head around knowing the right tool for the job, I
| think this article is actually positioned better than those.. I
| do like some of the points.
|
| But instead reminds me of a friend who went full gRPC learning,
| so far as to start contributing to the newer standard definitions
| of RPC, he used to turn around and say that all API's SHOULD be
| replaced with gRPC and argue as I would about how its not always
| needed etc, he knew enough to counter with good reasons instead
| or the reasons why it should be.. And sometimes thats the biggest
| hurdle, its not that it can do everything better, even easier.
| It's just the commitment devs/companies whoever will have to do
| it..
|
| I'm guilty of not using the right tool for the job sometimes..
| But I'm struggling to think of any protocol or implementation
| that has been fully replaced without huge intervention..
|
| Even TSL/SSL implentations was (rightly) pushed heavily by
| browsers, no ssl, no sensitive data transfer. But on its own, I
| don't see any replacements today wiping out the old.
|
| I'm no fan of latest fads.. You show me a good standards doc
| thats got strict implementations, I'm on board! You show me a
| 'recommendation' based on some amazing points and valid critique,
| I'm not so enthusiastic..
| hg35h4 wrote:
| Everything about this sounds terrible for mobile, lossy or even
| medium latency connections. Non-blocking background updates are
| unnoticeable, but imagine your website being jammed like a stuck
| video every time you click or scroll?
|
| He describes a "please wait buffering" future of web software. No
| thanks.
| ehayes wrote:
| Turbo[links], Stimulus, etc. ARE non-blocking background
| updates. It's HTML over the wire instead of JSON. [1] I don't
| think this is what you think it is.
|
| [1] https://hotwire.dev/
| cpill wrote:
| since when is HTML lighter than JSON?! this use case was what
| propelled JSON into the mainstream.
| silon42 wrote:
| At least their web page seems to work without Javascript... I
| hope this technology will too.
| Jtsummers wrote:
| Of these things, I've only played with LiveView (I'm a web
| dabbler, not a pro, but an Erlang/Elixir fan so it was
| interesting to me). At least through the material I've worked
| through, it fails to a usable mode when JS/WS themselves fail
| on the client side. In theory, the only required JS is the JS
| needed to establish the WS connection and communicate with
| the server and issue the updates. But if the WebSocket fails,
| you should end up with just a full page load instead of the
| diff being applied. (NB: A particular site/application may
| have more JavaScript, but for what LiveView offers out-of-
| the-box there's not much JavaScript that's included or
| needed.)
| Asmod4n wrote:
| With this approach you can keep all of the traffic inside a
| WebWorker, so nothing blocks. You also get the benefit of not
| having to open a new connection for every request and automatic
| reconnects when someting goes wrong. The connection is most
| likely already established before you even need it.
| water8 wrote:
| You just described http2
| Asmod4n wrote:
| Wait, with http2 a webbrowser never closes the connection
| it has to a webserver?
| qbasic_forever wrote:
| Yes, it's a long-lived TCP connection. It's not mandatory
| but the whole point of the protocol is to make one
| connection and send/receive all your assets over it
| instead of making more connections (which take time to
| setup and slow down page rendering).
| SahAssar wrote:
| It keeps it open as long as it is used and usually a bit
| past that. So if you have any traffic or are making
| periodic requests then it won't close the connection. If
| you are using SSE that can also use the same shared
| connection for streaming realtime updates to the client.
| jlokier wrote:
| Even HTTP/1.1 from 1999 keeps a persistent connection
| open, if the client and server agree.
|
| What it doesn't do so well is lots of parallel requests
| and responses out of order. HTTP/2 is better for that.
|
| Both versions will close the connection if it's been idle
| for a while, and automatically reconnect as needed.
| dahdum wrote:
| That was my first thought too, the word "latency" isn't even
| mentioned in the article.
| antihero wrote:
| Also:
|
| > Do we really believe that every one of our users is going to
| have a device capable of digesting 100 kB of JSON and rendering
| a complicated HTML table faster than a server-side app could on
| even a mid-grade server?
|
| Yes. This really isn't hard. Pretty much any smartphone can do
| this with blissful ease. And it scales horizontally because
| your server can just worry about getting stuff from the
| database and handing it out.
| netik wrote:
| There is so much wrong with this article I don't know where to
| start.
|
| Apollo's GraphQL with built in pub sub and JSON over websockets
| solves most of the issues brought up here with little work.
| fayten wrote:
| As an alternative that still relies on REST instead of web
| sockets is intercooler.js. It's a nice little framework for
| annotating html to give it more power. This little library seemed
| to have some buzz at the time it was first released, but I
| haven't seen it brought up in years.
|
| I decided to look it up and Intercooler is still supported, but
| there is a successor now called htmx. I have not shipped anything
| with either, but I think they are both technologies worth taking
| a look at. It also looks like htmx is working on support for SSE
| and websockets.
|
| https://intercoolerjs.org
|
| https://htmx.org
| qbasic_forever wrote:
| htmx is great, it's come up a few times on HN and has good
| commentary. There's a small set of web folks that look at all
| the ridiculous complexities of react, virtual DOM, etc. and
| nope right out back to good old server side rendering. htmx is
| perfect for primarily server rendered stuff. And ironically,
| now we see react going full circle back to investigate a server
| side approach with their recent react server component
| experiments.
| fayten wrote:
| I fooled around with a Spark java, j2html, and Bulma css web
| app for a prototype back in 2017 (2018?) and it killed me how
| nice it was. The only tooling I needed was Intellij and the
| app started in milliseconds along with supporting hot
| reloading.
|
| Modern web development is a big reason, I left my job at the
| end of 2019 and went back to school.
|
| I'm tempted to try something with Javalin(a fork of Spark),
| j2html + htmx, and Tachyons css now. I think together those
| would make a beautiful stack.
|
| http://sparkjava.com
|
| https://javalin.io
|
| https://j2html.com
|
| https://tachyons.io
| qbasic_forever wrote:
| Yep, and if you squint serverless stuff like AWS Lambda,
| knative, etc. is basically a slicker more modern take on
| plain old CGI scripts. I don't view that as a bad thing--
| the less friction there is between "here's a function/code
| block.. please run it on this web request" the better.
| mathgladiator wrote:
| I have thoughts, and I agree but also disagree a bit.
|
| We are in the dark-ages with respect to streaming sockets, and I
| am the architect of one of the worlds largest WebSocket and
| streaming services.
|
| First off, unseating the operational benefits provided by request
| response is a huge challenge. It's possible, and I've done it.
| One of these days, my co-authors and I will present an OSDI paper
| with the broad strokes. It's very easy to list a lot of the
| challenges with scaling WebSocket, but each of them can be
| solved.
|
| I believe we will have a nicer world with QUIC --> Http/3 and the
| up and coming WebTransport discussion. SADLY, that will result in
| a decade long "caniuse" issue, so we should expect to see
| WebTransport polyfills to arrive...
|
| Second, HTML over WebSockets is nice, but what is better is
| reactive data binding over the socket. Let the browser maintain a
| DOM tree that templates over a JSON object, then reactive-ly
| update and it's an amazing experience. You have minimal data
| transfer, and minimal rendering updates. There is a great deal of
| power in having your UI be a stateless function over a giant JSON
| object.
|
| Finally, the big challenge is dealing with the server state in a
| meaningful way. The exceptionally nice property of using request
| response for everything is the shared-nothing stateless nature of
| the web server. It's exceptionally forgiving in both operational
| and developer issues.
|
| It's very easy to fuck up the implicit state tied to the
| connection, and this requires discipline to get right. It's very
| easy to ship unreliable software that then has issues based on
| the connection.
|
| Now, I'm a HUGE believer in that we need to use streams for
| everything, but it requires a mind shift. The key thing to tackle
| is dealing with the server side state, and this is where I have
| my shitty idea of a programming language for board games. In
| essence, I am building a DIY database such that people connect
| directly to the database and get that sweet giant JSON object
| along with a stream of updates.
|
| The DIY part is related to the fact that I invented a programming
| language to transact on the JSON object such that you get all the
| benefits of durability with the mental model of working within a
| single machine.
|
| http://www.adama-lang.org/
| jlokier wrote:
| The architecture you're describing is awesome.
|
| It sounds like the one I was working with ~18 years ago.
|
| Except it used HTTP (long polling or comet) instead of HTTP/3
| for the transport. And more partial rendering to DOM-diffs on
| the server side because it was faster than doing it all on the
| client, but the client still applied diffs.
|
| The issues with full DOM state synchronisation, handling
| network errors and recovery, transport of templates and data,
| minimisation of transport subject to maximising responsiveness,
| some amount of anticipatory prefetching, were much the same
| then as now.
|
| A lovely thing about all this stateful streaming cleverness is
| you end up building a mostly stateless, functional-reactive
| model _on top_ of it again, that ends up extremely robust.
|
| It's just faster, and it can react immediately to server side
| data changes as well as client side. And that model can be
| declarative, it doesn't particularly need to be in JavaScript
| despite running on the client.
| djedr wrote:
| Interesting ideas, somewhat in line with what I've been
| thinking about.
|
| Perhaps you or someone in this topic might be interested in my
| little project[1] fit for innovative ideas like this. It is not
| very far from being available for experimental use in place of
| JSON. A future direction is experimenting with replacing
| HTML[2].
|
| [1] https://www.tree-annotation.org/
|
| [2] https://imgur.com/a/ER5qwtZ
| methyl wrote:
| > Let the browser maintain a DOM tree that templates over a
| JSON object, then reactive-ly update and it's an amazing
| experience
|
| Totally agreed. I even pulled off an Elixir library as a POC to
| show this concept, here's an example project:
| https://github.com/surferseo/live_data/tree/master/examples/...
| (most relevant part of API is here:
| https://github.com/surferseo/live_data/blob/master/examples/...
| and here: https://github.com/surferseo/live_data/blob/master/ex
| amples/...)
| RangerScience wrote:
| Got a question for you -
|
| I'm making a chat bot thing (https://www.brian.bot/) and have
| added socket-based web chat... but I don't even know how to
| phrase the question of "how do I horizontally scale the socket
| connections".
|
| Webchat <-> Server <-> Slack. Once I have more than one server
| dyno (heroku), then I can't ensure that the Slack event hits
| the dyno with the corresponding socket connection.
|
| Thoughts / tips?
| mathgladiator wrote:
| I'll be completely honest... you're mostly screwed. I say
| this with full love in my heart.
|
| Your best bet is to use Amazon and then leverage their ELB
| offering with sticky routing. HOWEVER, now you have a new
| problem as capacity dies, gets removed, cycled, added, etc.
| Sticky routing was designed with the assumption that it was
| an efficiency play as opposed to a deterministic play.
|
| What you will see happen is that your internal state will be
| split brain, and people joining the chat will not be globally
| consistent. Some people will be on host X while some will be
| on host Y. So, you have two choices. You could use a database
| to provide the global state, at which point now you have a
| whole bunch of problems. You can start with polling the
| database, and the key advantage of the websocket is moving
| the polling from client to server, so that will be a win for
| users. However, it will cost you. Second, you could introduce
| a message broker, but then you have the problem of how to
| initialize the state. Ultimately, everyone ends up with a
| hybrid database for storage and message broker for real-time.
|
| In your model, the database becomes like Slack, and your
| Server becomes a proxy. This could be super neat, but what is
| the value-add of the Server?
|
| The interesting thing to observe is that the solution is how
| to turn your front-end app into a database like thing. If the
| load balancer could route traffic like a database traffic
| controller thing, then you can put all your state in the
| front-end and move crazy fast. However, you will move so fast
| that you will fuck up your state. State is VERY HARD and
| exceptionally unforgiving to manage yourself.
|
| There is great wisdom in using a database with versioning and
| all that. It's a great abstraction having lasted so long. I'm
| working on the state bits and trying to figure out the people
| side of discipline with my silly language, and I have some
| novel contributions to provide over the coming years.
|
| There are some linked pdfs on http://www.adama-
| lang.org/blog/some-thinky-thoughts-2021 which may provide
| some more insight.
| naugtur wrote:
| Just a random thought - wonder if anyone tried a p2p
| protocol instead of a database or message broker for
| spreading information. Wonder if it'd be any better than
| broadcast to every stateful instance.
| Deadron wrote:
| You can use a redis to distribute messages via PUB/SUB. The
| sockets subscribe to the events that are relevant to them. It
| can handle thousands of messages a second in a local
| environment and probably more in a dedicated hosting
| environment.
| hfjtktkf wrote:
| I am doing something somewhat similar - I have a Postgres
| database and I send all the user tables to the client on
| connection and then stream all the updates. I use Vue and Vuex-
| ORM to make the client tables reactive, and put a view on that.
| When something changes in the database, the client UI will also
| update.
|
| It is indeed a very powerful and reliable way of ensuring
| synced state.
| mxxx wrote:
| Sounds like you're describing a system similar to Meteor.
| anderspitman wrote:
| > HTML over WebSockets is nice, but what is better is reactive
| data binding over the socket. Let the browser maintain a DOM
| tree that templates over a JSON object, then reactive-ly update
| and it's an amazing experience. You have minimal data transfer,
| and minimal rendering updates. There is a great deal of power
| in having your UI be a stateless function over a giant JSON
| object.
|
| Interesting that you're exploring this idea in the context of
| board games. I implemented[0] a similar idea while making a
| browser-based magic the gathering interface. Basically send
| commands to update the server state (a big JSON object), and
| the server does state diffs per client and sends lz compressed
| JSON patches. Worked quite well, but I haven't played with it
| for a couple years.
|
| [0]: https://github.com/anderspitman/pojo_flow
| brundolf wrote:
| > The key thing to tackle is dealing with the server side state
|
| The core problem of web UIs has always been managing state.
| People like statically-rendered pages because most state gets
| kept in a) the URL, and b) transient HTML elements, and both
| are highly visible and easy to deal with in robust ways. When
| you're forced to have server-side state it's exceptionally
| painful, but people usually just avoid it altogether which in
| most cases pushes things towards the virtue of having less
| state anyway.
|
| For complex UIs with lots of little interactions the above
| story doesn't really work, so we've invented state management
| systems for the client. Managing complex state still sucks, but
| it sucks less with these tools.
|
| Sounds like this approach is just moving that state store back
| to the server, with a greased pipeline so it isn't so horribly
| painful to add new pieces of state even though both sides are
| involved. But you'll still face all the same problems you face
| with a front-end store: transientness, cache-clearing, even
| modeling is hard when you're dealing with a big blob of mutable
| state. And there will be the additional challenge of
| associating this stuff with a user (which you get for free on
| the front-end, even with modern state stores).
|
| > Let the browser maintain a DOM tree that templates over a
| JSON object, then reactive-ly update and it's an amazing
| experience. You have minimal data transfer, and minimal
| rendering updates. There is a great deal of power in having
| your UI be a stateless function over a giant JSON object.
|
| > this is where I have my shitty idea of a programming language
| for board games
|
| It's funny, I started building a web-based board game to play
| with family during quarantine, and I landed on this exact
| approach totally by coincidence :) I'm using polling requests
| instead of websockets because I'm lazy/it doesn't need to
| scale, but it's the exact same idea where the server just
| publishes a giant JSON object of state and the clients are pure
| functions of it (and send messages to the server to mutate it).
| I wonder if there's some aspect of board games that pushes one
| towards that line of thinking.
| jamesjyu wrote:
| > I'm using polling requests instead of websockets because
| I'm lazy/it doesn't need to scale, but it's the exact same
| idea where the server just publishes a giant JSON object of
| state and the clients are pure functions of it (and send
| messages to the server to mutate it).
|
| I like this approach as well, but I do worry that users today
| expect optimistic updates on the client, and the injection of
| a X00ms delay would make the app feel sluggish.
| jagger27 wrote:
| > where the server just publishes a giant JSON object of
| state and the clients are pure functions of it (and send
| messages to the server to mutate it)
|
| So, XSLT for JSON basically. I like it.
| mathgladiator wrote:
| I'm working on the complex UIs now, and it is a challenge.
| Fortunately, I can focus on gaming designs which is less
| complicated.
|
| I think the key thing here is figuring out how the UI can be
| made mostly declarative and a stateless function of the
| state. I'm drawing some inspiration from
|
| https://flutter.dev/docs/development/data-and-
| backend/state-...
|
| and the challenge is the polish to make products great. My
| strategy is that I'm going to make a UI editor so I can make
| faster progress on designing the board game UI and then build
| a minimal set of controls to do data binding. The key is to
| get into the fight about what is the polish needed, and what
| reasonable escape hatches are needed.
|
| > I wonder if there's some aspect of board games that pushes
| one towards that line of thinking.
|
| There is, they are exceptionally complicated!!! SO
| COMPLICATED! The key is the implicit state machine between
| all the players, and you just can't quickly model it with
| traditional tools and databases. All it takes is a single
| card or game piece (which changes rules) to invalidate
| EVERYTHING. Games are exceptionally messy!
| vinay_ys wrote:
| If your game has limited number (say, < 10) participants
| per game board, then concurrent updates to shared state etc
| can be solved with a traditional game state hosting server
| model. But if that number is higher say 100+ then you need
| a sharded distributed setup. That's when things get really
| tricky if you don't keep things simple.
| radicalbyte wrote:
| This sounds like what Microsoft were trying to do 15 years ago
| with webforms: the browser was treated like a dumb terminal
| with the UI rendered on the server and pushed to the client.
|
| The UX back then was horrible, however technology has come a
| long way since.
| exabrial wrote:
| I have a brilliant idea, why not HTML over plain sockets?
| sitkack wrote:
| To a local server running in a Wasm env? Yes please!
|
| And by local, I mean running in the same page.
| snejad123 wrote:
| I don't understand the benefit ???
|
| This seems like unnecessary overhead for any startup software
| companies, costing both extra time and money while overloading
| your server right out the gates.
|
| Instead of expecting 100 requests per min from say like 20 users,
| I can now expect 1000s+ to my server because I'm sending every
| keystroke to the server ???
|
| That means I'll need a super expensive instance to handle all
| those users and this is in the extremely conservative use-case of
| 20 users at once.
|
| No thanks.
| Animats wrote:
| It can work, but it's harder than stateless. The web works with
| crappy code because the persistent state is in the database,
| which is of higher quality and stability than the applications.
| If you have persistent in-memory state server side for each
| client, the server has to maintain that state correctly. The
| server has to be much more bug-free.
|
| Also, every background tab in the user's browser now consumes
| server resources although idle.
|
| You do not need this for your 1 to 5 stars rating thing. Most web
| pages do not need this. They're rather banal. We have huge
| overkill in web technologies now. We have WebGL, which is little
| used, and WebAsm, which is little used, for when you really,
| really want to have full interactivity in the browser. There are
| a few nice applications using those, but only Google Earth is
| mainstream.
| pantelisk wrote:
| the energy utilization of keeping sockets open for every tab,
| can get out of control quickly. Usually if users are expecting
| it to (eg multiplayer game, or collaboration apps) that might
| be fine. But fetching a tiny page and then keeping a socket
| active just in case 2 hours later somebody goes back and clicks
| on some link is not so great.
|
| Nonetheless the idea is not bad. I just feel that HTTP/2 with
| its multiplexing is a nice middle ground and it comes for
| absolutely free.
| [deleted]
| frompdx wrote:
| This seams really optimistic and kind of glosses over the subject
| of scaling out websocket connections apart from this.
|
| _Anecdotally, the typical single Rails server process seems to
| be perfectly happy supporting nearly 4,000 active connections.
| And you can easily swap in the excellent AnyCable to bump that up
| to around 10,000+ connections per node by not relying on the
| built-in Ruby WebSocket server._
|
| That's not a lot of connections on it's own. If you are
| implementing a chat service you'll still need some form of
| pub/sub (or something) to glue all of that together when users
| connect to disparate nodes.
|
| Also
|
| _How about client-side validations? Easy. On every input change,
| round up the form values and send 'em down the WebSocket._
|
| That's just server side validation.
|
| As a disclaimer, I haven't used any of the HTML over WS
| frameworks the author discusses, but I've spent a fair amount of
| time dealing with scaling socket connections. It definitely makes
| the question of scaling horizontally more challenging. I feel
| like this article really glosses over that aspect.
| skullum wrote:
| Phoenix live view (anything on BEAM really) maps each ws to a
| BEAM process so scaling to 10000+ connections is both cheap and
| built-in
| nickjj wrote:
| But LV is still in its infancy and there are very real
| implications of using websockets that are unrelated to open
| connections.
|
| Just the other day someone posted on the Elixir forums about
| live_redirect causing 2 network round trip connections[0].
| Basically there was double the latency to transition between
| pages due to this "bug". I air quoted "bug" because it's
| working as intended, it's just not optimal.
|
| The creator of Elixir mentioned it was doable to fix the
| issue but when an issue was open on GitHub[1] it was shot
| down with a "this is a known tradeoff, you'll need the 2nd
| route trip for the websocket". I'm not sure what the state of
| the issue is but it currently stands as closed.
|
| I've pinged 80ms to servers where LV was being used and the
| delay was extremely noticeable (before I even knew about this
| double network round trip issue). It feels much worse than a
| Turbo Drive / Turbolinks driven site (which uses HTTP instead
| of websockets like LV does). In some cases LV feels slower
| than a regular site even with the DOM having to re-parse all
| of your assets. The only time LV feels like a net win to me
| is when you're on a local connection with 1ms of latency.
|
| I wanted to use LV a lot, but backed out because I kept
| running into bugs and missing features. Plus after feeling a
| LV site on a non-local connection I can't say that I would
| want to impose that experience on users. Especially folks who
| happen to connect from let's say Europe to the US, or even
| further away. The web is a global place.
|
| [0]: https://elixirforum.com/t/shortcomings-in-liveview-are-
| there...
|
| [1]: https://github.com/phoenixframework/phoenix_live_view/is
| sues...
| benzible wrote:
| When did you last use it? Javascript hook support wasn't
| there early on. The state of the art is the "PETAL StacK"
| [1] which uses client-side JS for interactions that don't
| require a roundtrip
|
| [1] https://thinkingelixir.com/petal-stack-in-elixir/
| nickjj wrote:
| > When did you last use it?
|
| I gave it a fair shake a few times.
|
| Once when it first came out, then again a year later and
| then again 6 months ago.
|
| Lack of hooks wasn't a concern I had at the time. It was
| more around core behavior of the library and critical
| features that were missing. Some of those features have
| been added after I posted about them but all that did was
| destroy any confidence I had in using LV because these
| are things that would have been encountered on day 1 of
| deploying a single LV app to production. We're talking
| huge things, like how to invalidate and update assets in
| the <head> of your page in a user friendly way.
|
| It left an impression on me that LV isn't really being
| used much in real world apps by the team developing it. I
| could be wrong of course but that's the impression it
| left. Plus it feels like it's taking a really long time
| for certain features to make their way into the library.
| For example file uploads took something like 18 months to
| go from being talked about publicly to getting an alpha
| release and now it feels like it's on the burden of the
| community to test this in production without really
| knowing much about the feature.
|
| That and the docs still leave a lot to be desired
| (especially around the time I read them) and the story
| for the last ~18 months is that since LV is a pre 1.0
| release the docs aren't really written up yet since stuff
| is changing all the time. I know docs take a long time to
| write (I've written literally over a million words of
| blog posts / course notes / documentation) but docs and
| practical examples are also the most important thing IMO
| to nudge folks into using something.
|
| Personally I don't want to have to read minimal docs, API
| specs and dive into the source code that I can't read
| very well because there's a lot of macros to see how
| something works just to use it effectively. Especially if
| I'm on the front lines of having to pioneer the tech,
| which means I'll probably be under pressure to report and
| fix bugs that I don't know how to fix.
|
| I don't know. All of this experience with LV and Elixir /
| Phoenix really made me understand that this tech stack is
| not for me. Especially not when Hotwire Turbo exists and
| works with any back-end language and it also has proof of
| it being used in a mission critical massive SAAS
| application (https://hey.com). That leaves me super
| confident that it'll work for me (and it has been), even
| outside of Rails.
|
| Maybe in 5+ years I'll try Elixir again (hopefully Stripe
| and other payment providers have Elixir clients by
| then!), because the core Elixir eco-system in general has
| a bunch of nice things. It just doesn't feel optimized
| yet for building applications (IMO). At least not
| compared to most other web frameworks.
|
| Also, while I don't use Laravel I also have major respect
| for Caleb Porzio. He created Laravel's version of Live
| View (LiveWire)[0] by himself. It mainly uses HTTP and he
| also has a ton of docs / videos on implementing practical
| application features with it. He shipped 2 major versions
| and everything about its API and docs just oozes creating
| something made for developers to develop applications.
| It's funny how a slightly different position on something
| can make something explode in popularity.
|
| I haven't even written a single line of Laravel and have
| no intention on switching to it, but his presentation and
| execution of an open source library is something I
| admire.
|
| [0]: https://laravel-livewire.com/
| conradfr wrote:
| I think ultimately Phoenix and by extension LV just don't
| have the manpower.
|
| LiveWire builds on Laravel which is a massively popular
| framework on a massively popular language, Laravel itself
| using components from Symfony that is basically the
| backend framework with the most contributors in the
| world.
|
| But LiveView may hit 1.0 this year :)
| mplewis wrote:
| Sure, it's server-side validation - which is great, and works
| well. And now it works without a full page submit and reload.
| That's a huge benefit.
| the-dude wrote:
| Which you can do already for over a decade with AJAX.
| sago wrote:
| Yup. And DHTML over a Java applet before XMLHttpRequest.
| 1999 at least, iirc.
| brod wrote:
| Ever since xmlhttprequest (and even before that with images)
| we've been able to do server-side validation without a full
| page reload.
|
| This "solution" completely ignores the purpose of client-side
| validation which is to a) reduce load on server-side
| resources, b) validate faster without the network latency and
| c) validate more securely and privately by not sending the
| content to the server.
| ksec wrote:
| It is also important to note the latency in these connection.
| Generally speaking 4000 Active connection you are looking at
| 150ms+ for 98th percentile already. Which is bad to be frankly
| honest.
|
| ( Results were from 2016, so may be things has improved )
| CyberRabbi wrote:
| Im skeptical of all the benefits of the approach promoted here.
|
| * not everyone has "two codebases" many people have one codebase
| and two different application distributions, one for server and
| one for client.
|
| * you will still have "two codebases" you have just removed the
| rendering logic from you client codebase.
|
| * What is the distribution of latencies of rendering json into
| html on the client? Are there numbers to suggest this takes more
| than 100ms for many people? If not the proposed efficiency
| advantages are being overstated.
|
| If the article were suggesting removing client side logic
| completely these arguments would be stronger.
| anderspitman wrote:
| I used to love WebSockets a lot more. At some point I got deeper
| into implementing HTTP servers and proxies, and realized how much
| of a special case WebSockets are to implement. They're cool, but
| I prefer Server-Sent Events on HTTP/2 whenever I can get away
| with it, which is pretty much always (binary data being a big
| exception, and even then I consider long-polling first).
|
| I think there's value in keeping our protocols as simple as
| possible to accomplish the task at hand.
| iomcr wrote:
| I feel like websockets get waaay too much hype and attention
| compared to SSE, especially for use cases that are barely
| interactive at all.
| viklove wrote:
| Future-proofing is a good use case though. As a developer I
| don't want to maintain _both_ SSE and WebSockets, since they
| solve similar problems and WebSockets are a superset of SSE.
| Even though my WebSockets implementation is currently
| unidirectional (server to client), I still opted for that
| over SSE because I 'll probably need send data the other way
| at some point in the future. Why learn two tools when I can
| just learn one?
| anderspitman wrote:
| What's wrong with normal HTTP requests for client->server
| streams? You get the added bonus of being able to dump them
| to a curl command for debugging.
| anderspitman wrote:
| Sadly it's not entirely unfounded. SSE on HTTP/1.1 is
| basically useless due to the connections-per-domain limits
| implemented in browsers. So WebSockets got a lot of mindshare
| while we waited for HTTP/2.
|
| But today I always start with plain HTTP, then try SSE, and
| finally WebSockets if I have to.
| phaedryx wrote:
| I'm also sad that SEE's don't get the attention and love they
| deserve.
| kdunglas wrote:
| And using SSE with Hotwire is even easier than using
| WebSockets: https://mercure.rocks/docs/ecosystem/hotwire
| yingw787 wrote:
| I've used HTTP/2 SSE for TinyDev (docs.tinydevcrm.com) and I've
| encountered the need for a reverse proxy and the unidirectional
| dataflow to be kinda eh, even if it is great in theory. I
| haven't played around too much with WebSockets though, but IMHO
| money + traction carries a good deal of weight.
| tschellenbach wrote:
| Isn't HTTP/2 SSE being deprecated?
| anderspitman wrote:
| I sure hope not. Are you thinking of HTTP/2 server push?
| iomcr wrote:
| https://stackoverflow.com/questions/28582935/does-
| http-2-mak...
| jamescun wrote:
| I've seen nothing to suggest SSE would be (or is even
| capable of being) deprecated on HTTP/2.
|
| You may be confusing it with HTTP/2 Push, where a server
| can inform a client of a future resource it will need,
| which is _de facto_ dead, with only a few real
| implementations beyond the bare minimum required by the
| HTTP/2 specification.
| anderspitman wrote:
| Why do you require a reverse proxy, and are those
| requirements unique to SSE for some reason?
|
| I guess I'm not seeing what the alternative setup would be,
| even with WebSockets.
| vfclists wrote:
| More snake oil from the Internet industry as usual.
|
| It is almost 30 years since the web came into existence and
| somehow people harbour this illusion that those who control the
| standards or are responsible for implementing them are genuinely
| committed to delivering technology which will help the
| competition (ie the rest of the world) bypasses their app stores.
|
| It makes one wonder whether those who keep blabbing on about
| these wonderful new technologies are shills or just stupid.
|
| Do they believe that a company that patented round corners and
| tie batteries to a particular phone to prevent it from working on
| another of the same make to be committed to technologies that
| bypasses their app stores?
|
| Do they think companies which ban apps from their stores as a
| consequence of their political partisanship will create an easy
| and effective bypass for them?
|
| I see someone mention Blazor below? Why not Silverlight? Oh it is
| proprietary.
|
| Well there are only two players in the browser market now, Apple
| and Google, and somehow between the two of them they can't come
| up with an NPAPI replacement although one of them makes the other
| happy to the tune of $12bn a year.
|
| It is 10 years since these companies conspired to deprecate Flash
| on the grounds that it was buggy and performance was poor. 10
| years on phones and computers are an order of magnitude more
| powerful, yet through some mysterious means the replacement
| technologies are still buggy, underperformant, need more
| refinement yada yada yada.
|
| Why do otherwise intelligent people continue to put with this
| fraud, or is more a matter of Stockholm Syndrome?
| mathgladiator wrote:
| They are neither shills nor explicitly stupid, just
| inexperienced (mostly young people) with a great deal of
| enthusiasm and energy.
| vfclists wrote:
| John Gruber has been around too long for like this to appear
| on his blog, but then he is not the writer of this article
| and probably doesn't much exercise much of an editorial
| influence.
| [deleted]
| qbasic_forever wrote:
| I do have to laugh a bit at people being very quick to dismiss
| this idea when HTTP/2 is effectively the same idea--one long-
| lived bi-directional 'socket' to multiplex all requests. It adds
| a lot more niceties like the server proactively pushing assets on
| first load. Many folks might even be using it right now without
| really realizing or knowing it.
| symlinkk wrote:
| Good lord what a long winded article. Just get to the point.
| An0mammall wrote:
| I just read the headline, that's enough for me...
| [deleted]
| NanoWar wrote:
| How does it compare to let's say Blazor?
| jordanab wrote:
| Blazor comes in two flavors: Blazor via WebAssembly and Blazor
| server-side over websockets/SignalR. The contents of this story
| directly relate to the latter one.
| didip wrote:
| Stateful proxy and horizontally scaling them is not easy. I doubt
| this approach will be hugely popular.
| Martinsos wrote:
| Didn't Meteor offer a conceptually similar solution, in the sense
| that data is constantly synced, via sockets? But it didn't
| require us to think about sockets so much, which is great.
|
| There is a lot of talk at the start of the article how web
| development should be easier, how it should be less about the
| underlying architecture and that we shouldn't spend time on
| implementation details like state that SPA suddenly has to
| manage. On the other hand, I felt the rest of the article seemed
| pretty implementation focused, talking about details of how
| sockets could be used - I do have decent web dev experience but
| grasping the practicality of the concept based on what was
| described was beyond me.
|
| That said, I love the first part that is talking about
| simplifying the web app development, to make it similarly simple
| as it was 10 years ago, but I can hardly imagine that solution to
| that is replacing one piece of underlying technology with another
| piece. I imagine that instead, we need a higher level of
| abstraction that will hide all the implementation details that we
| don't care about and capture that what is common through time, so
| we don't have to care if we are using websockets or http or smth
| else underneath - instead we say how we want data to behave, and
| it gets done. Dealing with HTTP or sockets should be reserved for
| advanced use cases, not typical web apps. I am working on a
| concept of this, open-source web dev DSL, still in alpha though:
| https://wasp-lang.dev , and while I can't be sure that it is the
| exact solution, I imagine something similar in the future, a DSL.
| At the end, frameworks are a step in that direction (embedded
| DSLs), it is just that they are not standalone languages and are
| therefore again pretty coupled with the language and architecture
| they are modeling.
| qbasic_forever wrote:
| Make it HTML over WebRTC data channels and then we're talking
| about something special--totally P2P decentralized web browsing.
| Beaker Browser is working on stuff like this:
| https://beakerbrowser.com/
| ampdepolymerase wrote:
| Does anyone still use ASP.NET Web Forms?
| keithwhor wrote:
| I'm gonna be "that jerk on HN," but this is that idea that just
| keeps getting rehashed every couple of years then fizzles out.
| The reason that it's so attractive is because as developers we
| love to build and save time, and we think, "imagine what we could
| do if we didn't have to ask for data from remote servers..."
|
| The problem is that stateful connections suck and create
| artificial complexity when you don't need them. Instead of
| managing the state of your app you're now managing the state of
| your app _and a connection to a remote server_. HTTP is a
| stateless protocol _on top of a stateful socket connection_. It
| wasn't designed this way by accident.
|
| I'm all for new engineers building SPAs creating exciting new
| libraries, but HTML-over-websocket has been rehashed at least
| three times over my professional career so far and it's not even
| that long.
|
| Don't get me wrong -- websockets have their use cases.
| Multiplayer online experiences pretty much require them. It's
| just that HTTP isn't fundamentally broken, and by engineering
| HTML over websockets you'll almost universally find yourself
| building protocols to abstract the state away... re-engineering
| HTTP in the process.
|
| It's certainly a fun project which I have personally worked on.
| But I'm not sure it has legs outside of that. Open to being
| proven wrong, the authors of HTTP aren't infallible.
| dnautics wrote:
| > The problem is that stateful connections suck and create
| artificial complexity when you don't need them. Instead of
| managing the state of your app you're now managing the state of
| your app and a connection to a remote server. HTTP is a
| stateless protocol on top of a stateful socket connection. It
| wasn't designed this way by accident.
|
| Seriously, try phoenix liveview if you haven't already. These
| problems of dealing with stateful connections over questionable
| tranport and managing them are what the Erlang vm were designed
| for, and phoenix was designed by rails core team members.
| steve76 wrote:
| Secure cookie. Secure cookie. Secure cookie.
|
| WebSockets need the client. How do you pass a secret over
| WebSockets without using the client? With HTTP, you have that
| secure layer not accessible to client side code.
| [deleted]
| Joeri wrote:
| Not only that. The basic problem is latency. We moved logic to
| the client to be able to update the screen without incurring
| the latency hit of a server roundtrip. Latency isn't going
| down, thanks to physics, so it is going to keep making sense to
| run logic locally to improve apparent performance. Granted, you
| need data to render something useful and if an SPA does a data
| fetch on every click, it might as well be rendered server-side,
| but still, it is going to keep making sense to render on the
| device in many cases.
| TheRealPomax wrote:
| Note that a websocket round trip is vastly shorter than an
| http round trip, though. If your payloads are small, 500
| consecutive websocket back and forths take orders of
| magnitude less time than the "traditional" high level url
| post/fetch becauses there's none of the overhead of an http
| round trip.
| bennysonething wrote:
| Genuine question: is this what Microsoft blazor is?
| kevingadd wrote:
| Blazor has two modes, one is based on client-server round
| trips to talk with managed code on the server, the other runs
| everything on the client using WebAssembly
| networkimprov wrote:
| I built a localhost web app, where the app runs locally and
| displays its UI in one or more browser tabs. [1]
|
| It uses websockets & JSON to connect the SPA UI (in Vue.js) to
| the app (in Go). That works well, and I can't imagine any
| advantages to generating HTML with Go, except perhaps less JS
| code :-)
|
| [1] https://github.com/networkimprov/mnm-hammer
| keithwhor wrote:
| As a thought exercise;
|
| - What happens if the client's internet connection temporarily
| drops? How do you handle client reconnections and retries?
|
| - What if the remote server crashes through no fault of your
| own (AWS server rack catches fire)? How do you ensure a
| consistent reconnection that preserves application state?
|
| These are just two questions that HTTP + Browsers solved
| decades ago.
|
| Websockets are this cool technology that seems powerful and
| exciting until you realize the "boring old stateless World Wide
| Web" was built over decades of iteration using stateful sockets
| as the backbone, did most of the work for you in tandem with
| browsers, and is ultimately a lot cooler and more sophisticated
| than a lot of us give it credit for.
| Graffur wrote:
| What you mean by sockets in "exciting until you realize the
| "boring old stateless World Wide Web" was built over decades
| of iteration using stateful sockets as the backbone".
|
| I should probably already know this.
| keithwhor wrote:
| HTTP is a stateless protocol built on top of TCP network
| sockets [0] intended to standardize transfer of hypertext.
| It's the backbone of the WWW.
|
| HTTP is quite literally "hypertext over sockets" so "HTML
| over websockets" is functionally equivalent... with a layer
| of abstraction added on top. If you build web software by
| sending HTML over websockets you're just reinventing what
| already exists; it's probably why it's never taken off. I
| think most developers realize within ~weeks to months of
| working on a "websocket-everything" framework that they're
| doing _more_ work, not less.
|
| [0] https://en.wikipedia.org/wiki/Network_socket
| conradfr wrote:
| You restore the state like you would on a SPA or regular
| server side rendered page.
|
| A crash or someone hitting refresh on his browser is not that
| different in this respect.
| cogman10 wrote:
| Here's another one. How do you deploy a new version of your
| service?
|
| Imagine a few customers open up your site and leave for
| lunch. Or maybe just a random crawler or bot sitting watching
| for some piece of information they are scraping.
|
| These sorts of issues can be challenging with stateless
| connections. I can only imagine how daunting they are with
| persistent connections.
| bitsen wrote:
| I bet your ass that at least half of the developers reading
| HN don't have caching of JS fully figured out such that
| when the JS changes server-side and immediately needs
| reloading on the client side that it does then and there
| instead of on the next request, the next page refresh, or
| never because they've f'd it up.
|
| With server-fed, event-driven pages, you could potentially
| force refresh.
| m00dy wrote:
| it is called hot-reload.
| meheleventyone wrote:
| The nice thing about persistent connections is that you
| know when they've been closed so you could literally signal
| that the connection was going down for a deployment and
| close everyone's connection. Clients can retry the
| connection until it comes back up or use another service to
| monitor the status.
|
| Games basically do this routinely.
| rootusrootus wrote:
| But you can do that sort of communication already with
| existing websockets, without trying to add the complexity
| of pushing all your regular traffic over that link.
| shakow wrote:
| > Instead of managing the state of your app you're now managing
| the state of your app and a connection to a remote server.
|
| Wouldn't an intermediate layer such as _e.g._ Phoenix /LiveView
| (https://www.phoenixframework.org/) solve the problem?
| nickjj wrote:
| > Wouldn't an intermediate layer such as e.g.
| Phoenix/LiveView (https://www.phoenixframework.org/) solve
| the problem?
|
| I don't think so but if I'm wrong please correct me.
|
| For example, imagine this simple scenario: you load the
| comment page for this post on HackerNews
|
| HackerNews renders an HTTP response to your browser and your
| browser renders the page based on that HTTP payload.
|
| You can be sitting here on the page for 10 minutes reading
| comments and even if HackerNews randomly went down 20 times
| for 10 seconds each time during those 10 minutes you would
| never know because your browser has everything it needed to
| render the page when it loaded. It's a done deal. The request
| was made and the response was served.
|
| But now let's say you use LiveView and you made this page an
| actual Live View. Let's also say you load all of the comments
| at once to keep the example the same.
|
| Since there's a persistent websocket connection open at all
| times, in all 20 cases of HackerNews going down you're going
| to get a visual warning that the websocket connection was
| dropped. You also don't want to disable this visual warning
| because on slower devices it might take 2 seconds to load the
| page which is much different than an uncontrolled disconnect.
|
| IMO this user experience is pretty bad. Why should users be
| concerned with the server's state after it has everything it
| needed to handle the request it asked for (loading the
| comment page). If they try to post a comment and the server
| is down then the user should see that error at the time of
| them making the comment (such as a custom 502 error page if
| the back-end is down).
|
| The grandfather's comment of "it wasn't designed this way by
| accident" is spot on. The stateless web is a happy web. Sure
| you can sprinkle in websockets for progressive enhancements
| like broadcasting new content somewhere (which is awesome
| when done well), but websockets shouldn't be the basis for
| everything. HTTP has decades of very careful thought and
| optimizations around its protocol.
| shakow wrote:
| > You also don't want to disable this visual warning
| because on slower devices it might take 2 seconds to load
| the page which is much different than an uncontrolled
| disconnect.
|
| You can restrict the visual warning to the first load only,
| it would be pretty distracting otherwise.
| lostcolony wrote:
| If the connectivity state doesn't matter to the user, why
| would you show it?
| TheRealPomax wrote:
| This. No reason to say "the server's gone!" when your
| user's not doing anything in which that matters. Do
| notify them _before_ trying to execute on a task that
| requires the server to be up, but that's not the case
| that was getting described.
| nickjj wrote:
| > If the connectivity state doesn't matter to the user,
| why would you show it?
|
| It's due to Live View triggering a visual indicator that
| the websocket connection isn't available.
|
| It's a combination of CSS and JS. You can turn this off
| but if you turn it off then you have no way to show an
| indicator when you do care (such as transitioning between
| pages or submitting a form).
|
| I don't think LV at the client level can be coded in such
| a way that it can tell the difference between the server
| dropping and the user's connection dropping due to their
| internet being spotty.
| the_gipsy wrote:
| Also I've seen request/reponse over websockets too many times.
| Martinsos wrote:
| Do you have any preferences regarding a direction to simplify
| web development, remove some of the complexity introduced with
| client-server separation?
| fartcannon wrote:
| Use as little tech as you can. Write HTML, CSS and if you
| absolutely have to, javascript.
| snejad123 wrote:
| it's difficult to keep up with the design expectations of
| the modern web with just HTML and CSS.
|
| It's possible but extremely difficult to create a "modern"
| experience with just html. Just like how we don't build
| houses with mud-bricks anymore even though it's easier than
| steel and wood.
| lmarcos wrote:
| How so? One of the most popular (if not the most)
| websites for developers out there is pretty much HTML +
| CSS. JavaScript is used, but minimally.
|
| "Modern" experience is not necessarily the same as "good"
| experience. Good old server side rendered pages are fine;
| SPAs are being built just because "we can", not because
| they are actually needed (sure, in some cases,SPAs are
| needed, e.g., chat sites).
| IgorPartola wrote:
| Are you talking about Reddit, StackOverflow, or something
| else?
|
| I have yet to see a proper web app (not a blog/collection
| of static pages, but something that does something
| complex like let you manage inventory, do payroll, do
| your taxes, monitor sensors in real time, interact with
| geographical maps, or edit documents) that is done
| without JavaScript and has even OK UX.
|
| SPAs are great because of separation of concerns. Sever
| takes care of the data (storing it, syncing it,
| authenticating your access to it, serving it, sharing
| it). Client takes care of presentation. I build SPAs
| because they are better. Imagine if all the apps on your
| phone or computer were effectively HTML documents
| rendered on the server. Emacs over HTML/CSS? Minesweeper?
| World of Warcraft? Would that be an OK experience?
| Probably not because you don't want to wait for a page
| load every time you do something in your Minesweeper game
| or check stock prices or whatever. Why should web apps be
| inferior?
|
| When people complain about SPAs it's because they don't
| like web apps running in the same environment as their
| document-based content. I guess some people prefer the
| ActiveX/JavaApplet model, which to a degree I can
| understand. Slack is an application, not a website. But
| let's not overlook the fact that implementing a Slack
| client with just HTML and CSS would be miserable to do
| and miserable to use.
| inopinatus wrote:
| On the contrary, I generally browse with JS disabled and
| there's a strong correlation between sites for which this
| is existentially problematic and sites whose content or
| utility are garbage.
|
| I have a personal toolkit of components I call "you might
| not need Javascript". Dropdowns, slideovers, toggles,
| modals, tabs, accordions, autocomplete, lightboxes, all
| with nice transition animations, and all in pure server-
| rendered HTML+CSS. A lot of it is just semantic elements
| being used appropriately. How many developers use
| <datalist> or <summary>/<details>? or :target and :focus-
| within? In my experience, not enough. How about, using
| <summary> in combination with a CSS [open] selector? The
| palette gets rich in combination.
|
| Overall, no, it's not hard, but it does require one to
| study. A couple of times a year, I'll re-read through the
| HTML and CSS standards. There's a lot in there to build
| from, and almost all of it has broad evergreen browser
| support. For the leading-edge stuff, "caniuse.com"
| remains an essential reference. I now have my eye on the
| <dialog> element, high expectations there, works well
| already in Chrome; Firefox just has a couple of bugs to
| shake out, and it's experimental (but incomplete) in
| Safari.
|
| All that said: a light dusting of JS can still provide
| progressive enhancement, but we can limit this to minor
| cosmetic improvements & optimizations, for browser
| compatibility, and where dynamic ARIA markup is
| necessary.
|
| The motivation as to _why_ I prefer this style is another
| matter, and it 's do with product strategy, and in
| particular, not crystallizing your architecture in the
| front end (where it is brittle) but in the backend (where
| it is much faster to pivot and/or rapidly
| prototype/spike/redevelop, by proximity to business logic
| and persistence schema). These are understandings that've
| been long (and sometimes painful) in the learning, but
| they're pretty much universal.
| IgorPartola wrote:
| VueJS SPA + simple REST API will get you a really nice
| experience for most CRUD type apps. For the backend I like
| Django.
| egfx wrote:
| You sound like someone that gets it and after reading further
| it appears you have built an app in this space, and this makes
| sense. I have too and your right, the coolness of the realtime
| web is also it's achilles heel. It's not that the web wouldn't
| be better off realtime, it's just that there is unlikely to be
| in most cases a time when more than one person if any at all
| will consume a shared resource. And now you have to account for
| the most sensible case being the static state of the app where
| you are over-engineering the realtime features that are not
| really going to be used that often. In my app I had a a channel
| state (realtime) and a snapshot state (static). Only thing that
| made sense in the end was the static snapshot state for content
| consumption.
|
| Here is a short demo of the product:
| https://www.youtube.com/watch?v=TwkgGBrK_tA
| Spivak wrote:
| Nice to see that we're back to thin clients again but I don't
| think it addresses why SPAs backed by JSON APIs caught on which
| is that you got dead simple cross-platform development when every
| UI was just a porcelain over your backend.
|
| The missing piece here is that you still need those platform-
| agnostic APIs and an absolutely clean separation of your backend
| with all the business logic and your presentation layer. But now
| your presentation layer mostly lives on your servers and is doing
| SSR and pushing data over websockets. It takes real discipline to
| not commingle the two because you're right there you could just
| peak at the database a little _smack_.
|
| The other hard thing about this approach is that now your
| frontend presentation servers have to keep their own state since
| they are the clients now which means they need shared storage of
| some fashion and likely even shared persistent storage if you
| really want to take advantage.
| aeoleonn wrote:
| Another "The future of <thing> is what <some person> says it is"
| without much more than a few paragraphs of explanation.
|
| No diagrams. I don't see much of a comparison between
| costs/benefits of alternatives.
|
| Nice hypothetical. I didn't read it, because I've seen the format
| before and I'm getting a bit bored of it.
|
| Whereas if it cited some other engineers/technologists, some
| studies, some academics, etc., then perhaps I'd be more inclined
| to read this.
|
| But one person's opinion? Nah. I need an aggregate of opinions to
| be persuaded to read another "The future of thing..." article.
| hinkley wrote:
| The guy I learned about 'mis en place' from had coined a term,
| "retro-grouch" for people who loudly insist on a nostalgia for
| old technology.
|
| When the Trough of Disillusionment hits, us old farts pop out
| of the woodwork to say "see, told you so" whether we were right
| or wrong.
| burnished wrote:
| Did you learn mis en place in a kitchen, or does it have a
| meaning in technology circles that I'm unaware of?
| blacksmith_tb wrote:
| I work in an org where it is used to refer to the prep for
| a release, but with sort of a wink and a nod.
| hinkley wrote:
| Turns out if you do skilled manual labor, the concepts
| translates. Bob was a bike mechanic. I don't know if he
| used the words, but he kept harping on us for not having
| our shit or tools together for a task ahead of time. When
| you're covered in grease is not a time to be digging for a
| wrench.
| sitkack wrote:
| https://en.wikipedia.org/wiki/Mise_en_place
|
| I think it also relates to operational professionalism
| and having your tools and toolbox in order ala Adam
| Savage and Jamie Hyneman from Mythbusters. They both had
| very interesting relationships with order, process and
| tooling.
|
| I think structuring dev teams around a professional
| kitchen is really powerful model. All roles are critical,
| the sous chef, the busser, the prep cook, the dishwasher,
| everything.
| hinkley wrote:
| You can't scale without delegating. And in a crunch is
| not the time to work out procedures. You do that between.
| Yeah, it's not a bad model, and you can stretch it pretty
| far until it breaks.
| sitkack wrote:
| I think the closest other team arrangements to watch for
| modeling software around would be theatrical performance
| and to a lesser extent bands.
|
| Though kitchens are especially interesting as they have
| pipelines, surges, lots of tasks that can be broken down
| into a series of steps.
|
| Mythbusters has another interesting aspect in that they
| came from movie production background, so wall time was
| really critical, you can't hold up a shooting day to get
| a better glue formulation for simulated flesh falling off
| bone.
|
| Part a thing is its structure, but the other part is how
| it evolves over time and its reaction rates to stimulus.
|
| Agree on the beers.
| jack_riminton wrote:
| Well, it is an opinion piece
| aeoleonn wrote:
| Clearly I arrive at this piece without the expectation of it
| defining the future-- I know better than to expect a pop tech
| piece to deliver to me a view of the future.
|
| format: blatantly unoriginal
|
| content: not persuasive, underdeveloped
|
| effort: very low
|
| value: very low
|
| "The future of" is a very bold statement. The more cliche it
| becomes, the more I expect an author to actually outline, in
| a bold, cohesive, relatively comprehensive way, their theory.
|
| Otherwise stop trying to tell people what the future will
| be-- it's a waste of time & attention.
|
| Sure, the headline is catchy. The rest seems like the author
| was simply trying to reach a certain word count and claim
| their cheque.
|
| --> "Future of" articles should read like a graduate academic
| paper-- give the future of technology the proper respect it
| deserves.
|
| --> Or, they should be a policy paper.
|
| Not a pop tech piece. Pop writers-- stop with the silliness--
| stop appointing yourselves as definers of the future unless
| you expect folks like myself to come along and bring you back
| to reality.
|
| ____
|
| Take this linked citation for example:
|
| "Fast-forward to 2020 and the web isn't getting any faster"
|
| It's linked to an article by an individual who has an
| undergrad degree in psychology, a grad degree in IT, and is a
| design/UX-related employee. That's not the person I would go
| to for a technical, knowledgeable analysis of internet speed
| evolution.
| jack_riminton wrote:
| But he could be right
|
| Why does it annoy you so much?
| aeoleonn wrote:
| I'm just sick of low effort articles where the author
| appoints themselves oracle/definer of the future.
|
| It results in devolution of knowledge and a disrespect of
| the attention of intelligent people.
|
| "he could be right" -- what a waste of a statement unless
| it is followed up by any premise. He could right... Ok,
| that's a claim. But based on what?
| jack_riminton wrote:
| But you're the one whose decided to dedicate so much
| attention to it. If it's a prediction you don't agree on
| just ignore it
|
| The fact that it's touched a nerve is more interesting to
| me
| aeoleonn wrote:
| Wait a sec-- So someone can write an opinion, and that's
| ok-- but hey: no one critique it, ok?
|
| But if I write an opinion-- that's not ok. But you--
| you're allowed to critique my opinion.
|
| _______
|
| Let's apply your logic to your replies:
|
| Well, jack_riminton, It seems like I've touched a nerve.
|
| Why did you feel compelled to comment on my commentary,
| when you could have just ignored it?
|
| Why are you critiquing my opinion if you're making the
| case that opinions should not be critiqued (and should
| simply be ignored if a person is in disagreement)?
|
| ______
|
| Ohh.... Now I see. You're the one who posted the article.
|
| Well, everything is very clear now: Simple bias.
|
| ______
|
| Note: You never followed up when I questioned the premise
| of your claim "he could be right." It seems you're not
| interested in analyzing whether or not he is right. So
| what's the point of even posting this article?
|
| Yet the purpose of my entire thread is to draw attention
| to the fact that him being right will not result from
| conclusions of a poorly contrived, low effort, pop-tech
| article.
| nom wrote:
| Seems more like your nerve was touched. If you can't
| handle critique and do not want attention why are you
| posting your article here?
| jack_riminton wrote:
| Firstly it's not my article
|
| Secondly I don't even agree with it
|
| It's an interesting (and apparently provocative)
| prediction. I've enjoyed reading the responses
| StellarTabi wrote:
| In college, when you write only "2" for an answer, the
| teacher doesn't say "hmmmm, he might be right", instead
| you get an F for not showing your work.
| Jtsummers wrote:
| Really? Requiring you to "show your work" was rare in
| college for me, though typical in K-12. But not showing
| your work, if you're wrong, means no potential for
| partial credit in college (for instance, correct process
| but a lost sign might get you half credit versus no
| credit).
|
| Unless of course, showing the work was the task (such as
| writing out a proof) versus a straight computation.
| jack_riminton wrote:
| It's not college though is it?
___________________________________________________________________
(page generated 2021-02-25 23:01 UTC)