5 ms·
This seems to be one of those problems that entirely disappears by ditching SPAs. Using solutions from the Hotwire or htmx family would mean that a query is ju
by vemv 3y ago
This seems to be one of those problems that entirely disappears by ditching SPAs.
Using solutions from the Hotwire or htmx family would mean that a query is just a server query - making those fast is a better-understood problem.
- reddalo 3y agoBut, if I can be honest, solutions such as Hotwire or Livewire are not as snappy as a SPA. I personally prefer InertiaJs [1], which is some kind of front-end router system with its state synced with the server in an "old style" fashion. [1] https://inertiajs.com https://inertiajs.com
- FridgeSeal 3y agoI don’t know what SPA’s you have the pleasure of using, but most SPA’s I’m subjected to are an exercise in molasses like interactions and loading spinners.
- qudat 3y agoYeah, they are building SPAs incorrectly by relying on something like `react-query` which is waterfall rendering land. People don't truly understand the sacrifice they are making by using `react-query`. It isn't designed for large scale SPAs, it's designed for small sites that just need to fetch a little data.
- FridgeSeal 3y agoI can’t help but feel, if SPA’s keep getting “built wrong”, then at some point, we ought to look at why people keep building them wrong.
- reddalo 3y agoI agree, most SPA's are very poorly designed. But others work so well that you don't even notice it. Random examples: Gmail, Notion.
- FridgeSeal 3y ago> Well designed > gmail I too, enjoy satire.
- reddalo 3y agoWhy? Gmail is one of the most used webapps in the world, surely it shows its age, but it's doing its job pretty well, and way better than all the other commercial webmail clients I've tried.
- 0xblinq 3y ago+1 We're also using Inertia in a pretty large project and we're super happy with it.
- myaccountonhn 3y agoRecently gave htmx a spin. It is absolutely bananas how much complexity it removes and how much more productive you become as a result. The fact that you can use whatever stack you want is also such a blessing. I tried it with ocaml + web components and it’s a 10/10 super productive experience. Only need one build tool that compiles faster than I can blink, no wiring needed between frontend and backend to map json, it is just insanely productive.
- emmanueloga_ 3y agoI took a close look at htmx, and my impression is that the problems it addresses can be resolved with even fewer than its 4000 lines of JS [1], and without having to familiarize myself with its many opinionated approaches. The crux of the matter is to generate HTML on the server, as much as possible. I know how to achieve that without htmx. The marketing materials for htmx are also a bit off-putting to me, and the authors seem to be enjoying fueling the flames of old and useless holy wars about what REST and hypermedia "actually" are, and how we all need to get back to basics, and remember to thank Ted Nelson before every meal, etc. Their online book spends something like 30 pages explaining what hypermedia is... [2]. I prefer not to sign up for a religion when I choose a JS framework (honestly, that's a bit hard these days :-/). -- 1: https://github.com/bigskysoftware/htmx/blob/master/dist/htmx.js https://github.com/bigskysoftware/htmx/blob/master/dist/htmx... 2: https://hypermedia.systems/hypermedia-reintroduction/ https://hypermedia.systems/hypermedia-reintroduction/
- unlikelytomato 3y agoFrom where I sit, I welcome the opinionated approach. I don't need my presentation layer to be industry defining. Htmx allows me to quickly make pages in a way that has never been simple for me using other frameworks. I am primarily a backend engineer though. Maybe there is some glaring weakness that I am missing, but I have yet to find something simpler for my needs.
- recursivedoubts 3y agoi don't think htmx is very opinionated: it generalizes hypermedia controls in HTML and that's about it. No strong opinions on how you use it beyond that, can work reasonably well w/ any back-end that produces HTML. The goal is to expand the set of UI use cases that can be cleanly expressed in HTML w/o resorting to (user) scripting. Yeah, htmx is 3800 LoC, and you could do an 80/20 version of it for a lot less, but there are a lot of details to get right: history, collecting inputs, etc. plus, since it's a general purpose library, it has an extensive event system, extension mechanism, etc. There isn't a ton of dead weight to drop, although 2.0 should be smaller as we drop some bad ideas in 1.x. I don't care too much about the holy wars around REST, I found them off-putting back in the day before I really understood the concept, but I am passionate about the uniform interface and communicating to developers why that was interesting and different. I do go a bit hot at times, especially at twitter, but, on the other hand, if I didn't, would you have ever heard of htmx? I try to balance that all out w/ reasonable essays and the book, which, I think, is worthwhile for most web developers to read (it's free online.)
- deleted 3y ago[deleted]
- threatofrain 3y agoThis isn't a problem of only websites. Should mobile and desktop ecosystems start making a big move for thin-client like the browser? Should a simple app like Apple Reminders or Google Tasks have the GUI pause if there are delays or connection issues?
- vemv 3y agoRead-only access for coarse-grained pages (as opposed to building a fine-grained ad-hoc DB) seems something reasonable (and easy) to cache for any kind of frontend. That would allow offline viewing to a variety of apps, regardless of approach. Last time I checked Google Docs doesn't primarily allow editing offline files, which hints how hard it is to support substantial features beyond mere reading.
- chrisco255 3y agoThat could just hint at complex legacy code that painted Docs into a corner and prevented them from easily supporting that feature without a full rewrite. No doubt the problem is challenging but just because Google didn't do it for docs does not mean it's necessarily some Herculean feat.
- deleted 3y ago[deleted]
- threatofrain 3y agoIf I'm not mistaken, Google Docs has allowed offline editing for a very long time? You might have to enable an extension that comes default in Chrome. For offline-capable rich text collab there's also Notion or Apple Notes.
- pphysch 3y agoThe authorization story in letting the client upload a new version of the application database (after a drop in connectivity) sounds like a total nightmare. I just don't think there are "embarrassingly client-side, but also needs a server for some reason" web apps that would benefit from this in the real world. Even Google's or Apple's version of the simple Todo app has a lot of (useful) integrations, which means having some level of trust with the client.
- skybrian 3y agoIt disappears if your customers have reliable networks, and they are either close enough to the datacenter that the database is in, or you have sufficiently smart database replication. So, often, the problem comes back, but you're synchronizing between datacenters. Running server-side does seem to be one of the problems SQLSync wants to handle? I wonder how well it does at that compared to other ways of doing it?
- vemv 3y agoPrecisely an implied part of my point was, server-side caching, DB replication, CAP, etc are all relatively well-understood problems. One can solve those without reinventing the database, as the article denounces.
- willsmith72 3y agoi don't get it, how does that solve the same problem for an interactive website?
- vemv 3y agoIf you want new data, you just fetch it again from the server, and the server returns inherently-fresh data, reasonably fast, along with the HTML fragments necessary for a re-render (over ajax or websockets)
- willsmith72 3y agoi thought the whole premise of the article was that you don't want to do that, you want to cache some stuff, and instead of writing the cache stuff (a db) yourself, use a real db in your frontend. if you wanted to just fetch data from your server, it's not a problem anyway, right? a spa can also just fetch fresh data from a server. the whole point of the frontend cache was optimising ux/latency, e.g. for apps with global users but not globally deployed servers
- pas 3y agoI'm not a HTMX believer, so excuse my potential ignorance, but as far as I know the whole principle of HTMX is to keep things so simple that things cannot go out of sync. (Mostly because HTMX is basically a set of locally cute JS snippets helping with managing the very local interaction/state of a "user clicks button -> JS disables button, sends request to backend, waits for response, puts response somewhere in the DOM, and re-enables the button (or removes it, etc)" everything else is simply HTML, <a href.., routing is on the backend, etc. and yes, the article is targeting the SPA crowd
- willsmith72 3y agoso for a typical spa, you can: 1. always refetch data. always in sync, but needs a server request, so it's slow. 2. cache some data on the client. faster, but you're "building your own database". can get out of sync (redux) 3. NEW: use SQLSync. fast, client & server stay in sync, don't have to "build your own database" what you're describing just seems like number 1, right?
- gonzo41 3y agoThese people will be blown away by server side rendering. Caches in front of API's and light weight front ends.
- apstats 3y agoI think it disappears not when you move away from SPA's but when you move away from some high interactivity features products that are amazing to use often have. This especially becomes true for products that are expected to work in low internet zones.
- barumrho 3y agoOnly for some class of websites with limited interactivity. On iOS/Android, before all the WebKit apps took over, many apps would use a local SQLite database to support offline edits and implement a syncing protocol to the server. It's a lot of work, but the end product can be quite handy. (This is how you'd expect your email client to work, for example.)
- vemv 3y agoOne could also argue, this class of websites is what the majority of the website/webapp landscape should be. An average SPA is, in the end, a website for most users. Take a payment form for instance - we had those 10, 20, 30 years ago, with 0.1x the effort. Of course there's place for fat client tech, but there are 1000 websites for each 'email client' - exceptional cases often dominate the discussion.
- naasking 3y ago"Limited interactivity" is misleading. It allows much broader interactivity than you think, and arguably most sites and apps would work just fine in this context.
- qudat 3y ago“Just don’t have a highly interactive web app.” “Just don’t run services that require more than one VM.” It’s a ridiculous take.
- vemv 3y ago20 upvotes disagree. SPAs are just a subset of all the JS we can possibly write - interactivity is not compromised.
- deleted 3y ago[deleted]