[HN Gopher] Ask HN: What companies are embracing "HTML over the ...
___________________________________________________________________
Ask HN: What companies are embracing "HTML over the wire"?
I'm a web developer who has been in the market for a new job for a
while now. As someone who has never enjoyed working with frontend
JS frameworks (yes, I sucked it up and learned them and have worked
with them professionally) I'm wondering who all the companies are
who have embraced the semi-recent "HTML over the wire" movement
(Can you imagine... using hyper text transfer protocol for
transferring hyper text? Seems nuts, I know). It's a massive slog
shifting through endless React/Vue/etc-focused jobs out there. Even
if you use React in small areas where it pulls its weight but
generally try and stick to simplicity of sending plain ol' HTML,
I'd love to know who you are. Even if you aren't hiring, it's nice
knowing you're out there fighting the good fight :)
Author : sodapopcan
Score : 101 points
Date : 2023-02-10 19:18 UTC (3 hours ago)
| adiabatty wrote:
| Fresh does this, but I don't know who's using it in production,
| other than possibly the Deno people.
|
| https://fresh.deno.dev/docs/introduction
| [deleted]
| lolinder wrote:
| > Even if you use React in small areas where it pulls its weight
| but generally try and stick to simplicity of sending plain ol'
| HTML
|
| The reason why so many apps use React/Vue/whatever for everything
| is because this hybrid setup is far from simple. It leaves you
| with two different ways of rendering views, which creates
| unnecessary context switching for developers, and the interface
| between the two is often ugly and complicated and prone to memory
| leaks if you're not careful. It also prevents you from taking
| advantage of the most powerful patterns in these frameworks,
| which rely on the assumption that it's running as a single page
| app.
|
| The fact is, if your app has functions that require a JavaScript
| framework to work, the most straightforward answer is to build
| the whole app in that framework, rather than trying to cobble
| together multiple front end systems.
| Vosporos wrote:
| Considering their stack, I'd say probably GitHub?
| gardenhedge wrote:
| Remix Run is what you want
| realrocker wrote:
| Been working on a html over the wire library in Go:
| https://github.com/livefir/fir. It mostly works but still work in
| progress
| ravagat wrote:
| How timely, I, too, am in the market for a new job and I've
| noticed that ridiculous new buzz of "HTML over the wire" or
| related to "over/on the wire". Thanks for writing this.
| pictur wrote:
| It is quite easy to say "you should definitely use x" by giving
| examples of simple applications. however, the vast majority of
| examples given will turn the app into a soup if you want to do a
| thorough study. If you're happy with this soup, it's up to you.
| So enjoy your soups and stop criticizing the useful things people
| produce with empty arguments. If you have a worthy alternative,
| offer them. Please stop suggesting things like htmx as
| alternatives.
| gwbas1c wrote:
| Where I work we're currently developing an administration /
| employee-only pages using server-side Blazor.
|
| I don't know if this counts as "HTML over the wire" because
| server-side Blazor contains some magic to make the page kinda-
| sorta act like AJAX. It's a little laggy, but for our purposes,
| it's "good enough."
|
| (The customer-facing pages are going to be SPAs, for very good
| reasons.)
|
| https://optirtc.com/company/careers/
| bunnyswipe_com wrote:
| Well I'm glad I've discovered HTMx with this thread, I will try
| it out with my next project, really tired of SPAs and their
| bulkiness
| noveltyaccount wrote:
| _old man alert_ Back in my day, we wrote ASP.NET that was all
| server-side-rendered HTML. Once in a while we got REAL FANCY and
| used JQuery to make PARTIAL HTML requests and update only
| FRAGMENTS of the page. Hooboy I knew that fashion was cyclical
| but not tech!
| lukaszkorecki wrote:
| I wrote some jQuery-based code to enhance a page rendered by
| Rails this week, it felt pretty great as compared to waiting
| for Webpack to do its thing
| wvenable wrote:
| Webforms has an UpdatePanel control sending partial HTML (and
| even additional JavaScript) to web pages.
| matwood wrote:
| Same. AJAX was around, but quite new. Browser JS engines were
| hit and miss speed wise. Creating elements in the dom could be
| super slow depending on the browser. My solution then was to
| have the server send html as a string and then drop it into an
| existing element. Felt super hacky at the time haha.
| antoniuschan99 wrote:
| I wonder if people nowadays know that Ajax (aka. partial HTML
| requests to update fragments of the page) was a huge leap.
|
| Gmail is one of the first to have adopted this paradigm.
| nickswan wrote:
| That's exactly what we are still doing in our bootstrapped SaaS
| tool! Using asp.net mvc though, not web forms.
| tanepiper wrote:
| Back in the days of MySpace, we were working for a client in UK
| Sports betting (Littlewoods Pools) - and we managed to persuade
| MySpace to let us have a script tag on the page, pointing to a
| JS file we controlled.
|
| The script injected jQuery, then we replaced the page with HTML
| fragments. We had an Adobe Air installer, a Flash game and even
| had an RSS feed.
|
| Funnily enough today we're mostly working towards using ESI -
| which reminds me of mod_include back in the day.
| luckylion wrote:
| ESI is awesome and really connects "let's just cache it" with
| "but what if this tiny detail in the footer changes and we'll
| spent hours refreshing the cache". I would've loved to do
| more with it, but we added a lot more optimization that need
| to happen before the cache and require access to the whole
| page, so now I do a poor man's ESI transparently caching all
| kinds of widgets and shortcodes (Frankenstein's WP).
|
| I guess one could potentially have tiered caches with an
| optimization layer in the middle and ESI on the backend-
| facing cache, but that feels extreme and more brittle.
| gpvos wrote:
| Computer tech has been cyclical since at least the 1960s,
| mostly moving the cleverness back and forth between the server
| and the client.
| 88913527 wrote:
| Returning html fragments is quite stateful and contextual to
| the rest of the DOM structure. Ex: You might be referencing
| class names; is there already a stylesheet loaded that defines
| those styles? Are those styles actually what you want? I try to
| avoid these sort of "hidden dependencies" because it makes it
| harder to reason about a system and make changes to it without
| unknowingly breaking something.
| tracker1 wrote:
| Until the page gets complex and viewstate gets ugly too... Add
| in a dialup connection and you were in for worlds of pain. By
| today's standards of interactivity, I find the modern take
| (server rendered Blazor) as equally painfully slow to respond.
| seydor wrote:
| Equally is putting it midldly. Jquery sites are blazingly
| fast today. Anything that involves compiled javascript is
| impossible to load on bad connections.
| kbuchanan wrote:
| We embraced Hotwire with a Clojure backend. Favorite things:
|
| - One language model (i.e. no JS, just our favorite backend
| language)
|
| - Extremely minimal front-end tooling
|
| - All data is manipulated with the same tools
|
| - No client-side routing, validation, or... really much at all
|
| P.S. We even wrote our own import-maps solution to avoid needing
| a JS bundler for the small stuff you can't do without JS.
| jeanlucas wrote:
| All companies using Elixir / LiveView, there are quite a few
| sodapopcan wrote:
| I had a job writing Elixir but it was a terrible fit. Most
| Elixir jobs want people with multiple years of Elixir
| experience and I have 8 months, lol. I do have an interview
| lined up with an Elixir shop, though.
| danielrhodes wrote:
| People have gotten way too religious over SPAs, SSR, etc.
|
| Should you use X? Maybe it depends. I have been burned by using
| SSR when the complexity of the app increased and suddenly doing
| SSR was getting in the way and now I was uncomfortably mixing JS
| with server rendered pages and struggling to maintain state. I've
| also been on the other side, using React and creating more
| complexity than was needed.
|
| The point is: don't be dogmatic. Get requirements, extrapolate
| what could happen in the future, use first principles, weigh
| decisions against team capabilities, ask yourself if your
| decisions are for your own personal reasons or have significant
| positive user/business impact.
|
| Engineers who rush to use one technology over the other without
| doing their homework are just doing bad engineering. It has
| nothing to do with "fighting the good fight".
| sodapopcan wrote:
| I agree 100%. Doing everything on the client has its place, but
| those aren't the type of apps I'm interested in working on. My
| problem is that for the bulk of web apps out there, a frontend
| JS framework (I'm sorry I don't have hard data on that but
| going by experience and the experiences of people I know). The
| "good fight" I'm referring to is not defaulting to React to
| build your information app that has very little interactivity.
| The recent "HTML over the wire" frameworks lean heavily on
| abstracted away JS to give you a middle ground between SPAs and
| pure SSR.
| ivan_gammel wrote:
| Exactly. My rule of thumb is that SSR is good when you optimize
| conversion (hence focus on bounce rate, FCP, time to
| interactive), SPA is good when you optimize UX (hence focus on
| interactivity, response time, recoverability etc). On the
| customer journey SSR is usually everything before registration
| and login, SPA is for most of the things after (except some
| embeddable static content like help pages).
| jacobsenscott wrote:
| People also need to work within the constraints of the chosen
| stack. You can make a very good experience in either a SSR and
| SPA app. But you can't make identical experiences.
|
| Product designers are notoriously bad at working within the
| constraints of a stack - so when you choose SSR with hotwire or
| whatever, you definitely need to push back when a product
| designer hands you a mock up of something that can't be done
| easily with SSR. Don't create some mess of SSR and JS. Tell the
| designer to go back and redesign the experience so it meets the
| constraints of the stack.
|
| So when I hear "the complexity of the app increased" I'm
| hearing "the designer invented something that doesn't work with
| our stack" and rather than saying no, the devs just tried to
| forge ahead with the wrong tools. (Obviously I'm projecting
| experiences I've had :))
| brink wrote:
| My last gig used Rails' Hotwire, and my new gig is using Phoenix
| Liveview.
|
| Thankfully people are waking up and seeing that JS is most
| appropriate as a "last resort" technology.
| albertgoeswoof wrote:
| We're using Hotwire extensively at https://mailpace.com
|
| It's a joy! But we're not hiring...
| smrtinsert wrote:
| lol. We're going to end up with xslt again aren't we, it's just a
| matter of time.
| rahatarmanahmed wrote:
| For those mentioning frameworks that update the page by getting
| HTML from the server and patching it into the page: how do you
| deal with server-client skew?
| tracker1 wrote:
| It depends... are you delivering mostly static content or
| creating and interactive application front-end? Most sites are
| somewhere in the middle and so should the responses.
|
| For me, if it's an application ui/ux, then the rendering should
| be almost exclusively on the front-end. It's just delivered via a
| web server instead of installed. Yeah, it's larger than server-
| sent. It's also emphatically not tying up server resources for
| template processing, instead using the super computer on your
| desk or in your pocket.
|
| I frankly feel ill when I see more than a couple hundred kb of
| compressed JS go over the wire... why a couple hundred, that's
| just where I draw the line... React + MUI with some optimizations
| and all the application logic should _easily_ fit in under 300k
| compressed payload. If you 're going over that, you're probably
| doing something very, very wrong. Not that you can't go _much_
| smaller and hand crafted. It 's a trade-off.
|
| I also think edge development tools like Cloudflare Workers and
| Deno are exceedingly nice and can seriously bridge the gap closer
| to server rendered, but still not the same as a lot of classic
| legacy apps.
|
| On the flip side, I look at how much memory and resources
| applications use on a server as it is... They're often massively
| under-utilized as well. So who knows. I just know that there's
| nothing wrong in using the client's system to render the client.
| jacobsenscott wrote:
| I wouldn't assume building the html on the server uses any more
| server resources than building JSON. Either way you are just
| building a giant blob of text. With html fragment caching the
| server could easily be doing less work this way.
| marcopicentini wrote:
| I work for a B2B SaaS and we use Ruby on Rails with Hotwire and
| it's great!
|
| Almost zero JS (no Vue.js, no React, or else).
| sodapopcan wrote:
| Are you hiring? lol. I'm a rails dev who shifted over to Elixir
| for a bit, but I'm currently building a project with Hotwire.
| lordpankake wrote:
| I'm building a webapp[0] for turning Clickup docs into static
| sites, using CF Workers. There isn't a framework for Workers that
| has the flexibility I need, so I home-rolled one that only sends
| rendered HTML over the wire. Async components are supported too,
| so if I have a particularly data-intensive component the renderer
| just inlines a tiny JS script that sends a request to the worker
| again, which then returns just that component in HTML.
|
| Could be worth releasing on its own as a GitHub project!
|
| [0] https://intenso.app
| thrownaway561 wrote:
| ColdFusion!!! Nice!!!
| vore wrote:
| CF = Cloudflare. I would hope nobody is still writing things
| in ColdFusion these days :-)
| verhovsky wrote:
| Someone added a ColdFusion Markup Language generator to
| https://curlconverter.com/cfml/ last year and after a few
| months I decided to remove it since I've never heard of it
| so nobody could possibly be using it, and the next day the
| guy who added support for it and 3 other people complained
| about it, so it seems like they're out there.
|
| https://github.com/curlconverter/curlconverter.github.io/pu
| l...
| CoolCold wrote:
| I wonder how much visitors you have, i.e. how much
| popular is it? If its not a secret of course.
|
| I couldn't imagine any web developer need such kind of
| tool [knowing curl by heart], but obviously I'm in my own
| bubble and I'm wrong on my assumptions.
| thrownaway561 wrote:
| the client i'm working with right now uses ColdFusion
| extensively.
| jerjerjer wrote:
| Is "HTML over the wire" a new buzzword for SSR or is there a
| difference I'm missing?
| chc wrote:
| I think it's referring to partial server-side renders. SSR is
| usually used to refer to statically rendering pages, while the
| "new" thing is to dynamically update pages with chunks of SSR-
| created HTML.
| [deleted]
| jmkni wrote:
| Maybe we need to invent some sort of server-side MVC framework?
| lol
| sodapopcan wrote:
| Others already answered but that's why I bothered making that
| little quip about HTTP. It's kind of a ridiculous name but also
| funny and appropriate since it's trying to state that it's a
| return to form. My brother who is just started working with web
| tech recently didn't even realize that it was possible to send
| HTML over HTTP, lol.
| eddsh1994 wrote:
| I think it's HTMX etc, so yes SSR. That was how I started
| building web apps in my first job as a dev, crazy how the loop
| of front-end technologies is only like 10 years.
| seydor wrote:
| Was it a loop? I thought it was stagnation due to the fact
| that everyoen was trying to copy mobile apps and bring them
| to the web. It was a bad decision because mobile apps are by
| definition constrained and not very versatile. In any case,
| people seem to be picking up where they left in 2011, not a
| loop.
| mjfisher wrote:
| It _is_ rendered server side, but typically the server keeps
| track of only what needs to change and sends as small as
| possible an update to dynamically update the DOM. You end up
| with a user experience that feels close to an SPA, but a dev
| experience that feels close to traditional SSR.
| freedomben wrote:
| Tech like LiveView (Phoenix) and LiveWire (Laravel) are great
| examples of this.
| mejutoco wrote:
| And htmx for a language-agnostic one
| SirGiggles wrote:
| Also Blazer Server (C#) and the upcoming Blazor United
| slated for .NET 8
| quechimba wrote:
| I've been working on one of those frameworks, although the
| dev experience feels more like a SPA in this one.
| https://github.com/mayu-live/framework
| 88913527 wrote:
| Having only worked at SPA places, it's hard for me to imagine
| not having tools like Storybook, Chromatic, and Mocked
| Service Workers. Building the UI in isolation means with
| mocked API responses means I can, in parallel, validate
| 1000's of use cases with pixel-level precision. The backend
| teams can keep their focus on scalable, performant APIs. The
| frontend teams can focus on accessibility, consistency, etc.
| I've found a secret sauce that works very well in my
| organization, and I'd be curious to know what the equivalent
| would look like for SSR apps. But I can't overstate of much
| of a boon it's been to develop the client in isolation.
| Nearly all my bug reports go straight to the backend teams.
| It's bliss.
| bvirb wrote:
| We do browser based end-to-end testing which tests the
| frontend and backend at the same time using a single tool
| (Capybara in our case). We take snapshots at various points
| during the test runs which are then compared to previous
| runs for visual regression testing.
|
| Nothing is isolated so it's probably slower. The tradeoff
| is that the tests are really simple for how much they
| cover, and they're entirely separate from the
| implementation details so refactoring/changing technologies
| becomes really easy. It's an old project and we've
| incrementally migrated from jQuery to Backbone to React to
| Stimulus with the same tests. Conceivably we could change
| the app to a SPA and keep the tests.
|
| I have no way to really know if it's better than anything
| else (though I am interested in that question!), but I
| think it has worked out pretty well for us. One metric
| might be that our main app has been around for 10+ years,
| we're still delivering features daily, and nobody is
| complaining about a rewrite.
| 88913527 wrote:
| How do you test cases like, "the app should show an error
| screen when an error occurs in the database or server-
| side application layer"? In the SPA approach, I find
| these things quite easy to model with a service worker;
| just mock JSON API with the non-200 response code with
| body. I do see the merits of end-to-end testing but I've
| found it quite simple to mock the interface rather than
| ensure the database is primed with my situation in mind,
| or setup or teardown those records to ensure my 404 page
| renders correctly. And then I have to know how those
| parts of the system work, to create my test case. It does
| seem like an increase in cognitive load.
| jacobsenscott wrote:
| Indeed this is one of the challenges of hiring front end
| for SSR apps. There's now a whole generation of front end
| engineers who have never had to build a plain old SSR html
| page, and never had to use or read any language other than
| JS. Learning this style of development is starting from
| scratch for them. Yes SSR is a radically simpler stack, but
| not until you learn it. And you probably need to learn at
| least on more language.
| 88913527 wrote:
| We do have a SSR legacy app, and I tend to see the
| codebase littered with random global variables, mutation
| of browser-defined globals like document of window, and a
| ton of clearly bad practices-- but it was written in a
| different era. It isn't a shining example of what great
| SSR could be; pointing to it as a reason not to do SSR
| would be clearly a straw-man argument. I'd be open to
| developing a playbook for what bulletproof, high-quality
| work could look like on SSR stack, but I haven't seen the
| light. I have my tools and I know them to work for my use
| case. As long as I have cheap, extensive automation
| testing, I can keep shipping with quality. Having to spin
| up the "whole thing" -- when it's 100's of microservices,
| plus the legacy app, plus the databases -- the only way
| out I've found is to develop in isolation and mock
| communication to other team's system's. Running
| everything in order to complete a test is a tall order.
| gemstones wrote:
| Yeah, I hear the HTML-only case more from people who were
| full-stack or backend. Giving up the tooling around SPAs
| would be hard. I'm not sure what the equivalent is - is
| there any frontend-specific advice for backend devs that
| amounts to "wouldn't it be cool if you gave up all your
| developer tooling?"
| victorbjorklund wrote:
| Like "lets use firebase"?
| replygirl wrote:
| it looks no different with ssr apps, and you don't have to
| give up any of what you mentioned at the beginning
| ipaddr wrote:
| At what cost? You can validate 1000s of use cases but you
| can't validate one that doesn't include that 25m download
| and simulate what a real user experiences.
|
| Are developer tools more important than the product they
| create?
| idsout wrote:
| That sounds really expensive for the server.
| TN1ck wrote:
| Partly, but it especially means things like Phoenix LiveView[0]
| or htmx [1]. With these you can create SPA like experiences by
| sending partial html updates from the server and applying them
| by some light JS to the UI (which you don't have to write
| yourself).
|
| [0] https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.html
| [1] https://htmx.org/
| hinkley wrote:
| The first time I saw the concept codified in a library was in
| a jquery function that allowed you to replace a part of the
| DOM. Either the method signature or the documentation pointed
| you to using it in pairing with AJAX requests.
|
| The first webapp framework I saw it in was Rails
| (turbolinks). I came to Rails late and didn't stay long so I
| was never clear how old or how broadly used that feature was.
| Mostly what I got from Rails was being more comfortable
| writing NodeJS code, which stole shamelessly from Rails.
| replygirl wrote:
| i wouldn't call Element.replaceWith a codification of html-
| over-the-wire
| intrasight wrote:
| You can also go to the extreme of "jpeg over the wire". Your "web
| browser" could probably be implemented in <1000 lines of of code
| ;) No state, no cookies, no million lines of bundled JavaScript.
| someweirdperson wrote:
| If a "real" browser is used that needs javascript to request a
| jpeg of a size appropriate for the screen.
|
| There might be something that's good enough through css, not
| sure.
| avmich wrote:
| Little problems with scrolling but constant updates when a page
| is resized (changes in layout) - maybe it's worth it...
| alexbezhan wrote:
| We use htmx + Node, and we are hiring. PM me on Twitter
| @alexblearns
| root_axis wrote:
| Eschew developer fashion (and fashion contrarianism) and use the
| best tool for the job. It doesn't make sense to pick the tool
| before you even know what problem you're trying to solve.
| JonathanBeuys wrote:
| You don't even need a fancy "send html fragments over the wire"
| approach to create a better user and developer experience.
|
| Just sending full pages, server side rendered, like Hacker News
| and Wikipedia do is fine:
|
| Going from the HN homepage to this topic we are on:
| 36 KB in 5 requests.
|
| Going from the Wikipedia Homepage to an article:
| 824 KB in 25 requests
|
| Going from the AirBnB homepage to an apartment listing:
| 11.4 MB in 265 requests.
|
| Going from the Reddit homepage to a Reddit thread:
| 3.74 MB in 40 requests
|
| In comparison to AirBnB and Reddit, HN and Wikipedia feel
| _blazingly_ fast. And I am sure the developer experience is an
| order of magnitude nicer as well.
| keizo wrote:
| I've been working on a note taking app exactly because of this.
|
| https://grugnotes.com
|
| I can load 3 years of notes on a single page 100kb.
| basch wrote:
| IF you want the page to be interactive without refreshes
| though, you gotta do something. Unless you are advocating a
| completely pre-ajax web.
|
| https://en.wikipedia.org/wiki/Ajax_(programming)
| slotrans wrote:
| Why are refreshes assumed to be bad?
| ptx wrote:
| Refreshes can be very fast, and often essentially invisible
| in modern browsers, when you don't bloat the page
| unnecessarily, but I think AJAX still has a use for things
| like the voting button on HN or "add to cart" buttons in a
| web shop. It would be annoying to lose the scroll position
| (and perhaps other state) for each item you want to
| add/upvote.
|
| (Although modern sites that try to sweep latency under the
| rug by immediately updating the state on the client side
| and later reverting the change when the server responds are
| perhaps more annoying.)
| simonw wrote:
| "Refreshes can be very fast, and often essentially
| invisible in modern browsers"
|
| That's thanks to a fantastic browser feature that was
| introduced a few years ago that hardly anyone knows
| about: Paint Holding -
| https://developer.chrome.com/blog/paint-holding/
|
| "... where the browser waits briefly before starting to
| paint, especially if the page is fast enough. This
| ensures that the page renders as a whole delivering a
| truly instant experience."
|
| This is why you don't see flashes of a blank white page
| while a new page is loading on most sites these days.
| BlueTemplar wrote:
| Also browser refreshes should definitely _not_ lose
| scroll position, though I can understand how with full
| ones the former position might not be the "correct" one
| any more with dynamic content like HN... or substack
| comments (and how did those manage to be _so_ slow and
| buggy displaying what is almost exclusively text ?!)
| ptx wrote:
| Not a refresh of the same page, but if you perform some
| action (e.g. adding an item to a shopping card), that
| would imply a POST request which then (according to the
| common pattern) redirects to the original page... so then
| you do lose the original scroll position, I think?
| ivan_gammel wrote:
| Latency between page going blank and FCP, poor recovery
| mechanisms. Significant number of users is still on
| occasionally bad connections (e.g. on a train, walking into
| the part of the building with poor signal etc). If
| interaction in SPA does not work, they can try again,
| because they still have the UI. If page goes blank and does
| not load, not every user will recover from this.
| sharemywin wrote:
| if the page is large and you only need to bring back a
| little data it's probably better to just grab the little
| data. or upvote so your just sending a little bit of info
| back to the server.
| tracker1 wrote:
| I'm not convinced that it is... but it's not as smooth as
| client load-once rendering can be.
|
| What is/was painful was, as an example, the first versions
| of ASP .Net Web Forms, where every client action was a full
| server round-trip... Server-rendered Blazor over the wire
| (not local or in-office server) is roughly as painful by
| today's standards.
|
| I do think that it's a mix... start with basic html and
| enhance, or start with a component toolkit with client
| rendering, and inject server donut or other pre-rendering.
| With Cloudflare and Deno, I think the latter definitely has
| some traction.
| basch wrote:
| I find it much less smooth having a webpage consuming
| constant CPU.
| tracker1 wrote:
| That's a different issue. There's no reason CPU
| consumption should be high when you aren't interacting
| with an application.
| basch wrote:
| Most of the time there is no need for "it" to be an
| application, when it can be a page with some buttons.
| yamtaddle wrote:
| There's theory, and there's practice....
| sodapopcan wrote:
| "HTML over the wire" generally refers to tech like [0]
| LiveView, [1] Hotwire, [2] LiveView, [3] Blazor, etc. They
| aren't about about ditching JS and more about not writing
| your HTML in JS (and yes, SSR).
|
| [0] https://github.com/phoenixframework/phoenix_live_view
|
| [1] https://hotwired.dev/
|
| [2] https://laravel-livewire.com/
|
| [3] https://dotnet.microsoft.com/en-us/apps/aspnet/web-
| apps/blaz...
| basch wrote:
| and https://htmx.org/ which is ... access to AJAX, among
| other things
| rswskg wrote:
| Or mvc?
| JonathanBeuys wrote:
| A bit of Ajax here and there is fine.
|
| Look at how HN handles it when you upvote/unvote a comment.
|
| Look at how old.reddit.com handles it when you click "load
| more comments" in a long thread.
| nonethewiser wrote:
| > Look at how HN handles it when you upvote/unvote a
| comment.
|
| How?
| IncRnd wrote:
| For me, HN handles votes using deep links, since I have
| JS disabled.
| basch wrote:
| isnt ajax fancy sending html over the wire? or is it just
| the non fancy way?
| tomjakubowski wrote:
| It's so fancy in fact that it sends xml
| dtech wrote:
| AJAX was the original name for doing asynchronous
| Javascript calls to a server.
| spcebar wrote:
| AJAX stands for Asynchronous JavaScript And XML--it was
| originally designed for asynchronously manipulating XML
| data using JavaScript because at the time, the future was
| XML. The act of using JavaScript to send requests is
| still sometimes referred to as AJAX, despite usually not
| dealing with XML in any way. The most common use for
| sending asynchronous requests is making API calls, which
| today generally return JSON, but you could use AJAX to
| load HTML and dynamically add it to the page.
| basch wrote:
| the person I replied to said "we dont need any of this
| fancy hotloading" and then gave examples of fancy
| hotloading, hence me asking, and pointing out the
| contradiction.
|
| Like you said, AJAX isnt limited to XML, and is really
| just referring to any use of XMLHttpRequest to hotload
| data whether its XML, JSON etc.
|
| I wasnt asking what ajax was. I was asking if it falls
| into the definition of "fancy."
|
| I think my parent proved the opposite point they meant
| to. old reddit and hn and wp ARE the fancy html over wire
| sites, and airbnb and reddit are NOT the fancy over wire
| sites.
| tshaddox wrote:
| Is that AirBnB stat including "content" stuff like images or
| embedded maps? It's still worth critiquing the bandwidth spent
| on that stuff, of course, but it wouldn't really be fair to
| include it here when the discussion is about the architecture
| of page transitions.
| JonathanBeuys wrote:
| Page transitions are much faster for me on Wikipedia than on
| AirBnB.
|
| Whatever I click on AirBnB, I get a white screen, then some
| placeholders, then the placeholders one after the other get
| replaced by the actual content.
|
| Whatever I click on Wikipedia - its just there instantly.
| IMTDb wrote:
| Bear in mind that serving Wikipedia pages (static text
| documents) is much simpler that AirBnB listings (dynamic
| image heavy content).
|
| It is possible to create a faster AirBnB by changing some
| of the underlying constrained imposed on the system (eg by
| accepting to serve cached, stale, listings; or by lowering
| the amount of telemetry) but apparently Airbnb management
| does not think the tradeoff is worth it.
|
| Of course you are entitled to think that these decision
| from Airbnb are wrong and that they are hurting their
| sales. But you know the saying: << The least you know about
| a problem, the more convinced you are that you have the
| right answer >>
| yamtaddle wrote:
| "Plain HTML" gmail vs. any other version. It's way faster
| to navigate.
|
| Remember when AJAX was supposed to make pages faster? LOL.
| Of course, back then we were just sending HTML to be
| injected, not JSON that has to be processed by 50+
| Javascript functions before finally becoming HTML (or, some
| DOM entities, anyway).
| IMTDb wrote:
| > "Plain HTML" gmail vs. any other version. It's way
| faster to navigate.
|
| And offers far less features. Attaching a file to an
| email takes ages without drag and drop, this alone is
| worth waiting few more milliseconds to most people (Gmail
| loads in less than 2 seconds on my crappy hotel wifi)
| basicallybones wrote:
| Frontend frameworks developed in response to the need to
| develop/maintain very complex browser-based applications like
| Facebook across a large team of developers. AirBnB/Reddit have
| dramatically more complex user behavior and are much more
| input- and media-oriented. You cannot wait on round trips to
| the server for user interactions, and you cannot just do hybrid
| client/server the old jQuery way on big applications because
| you get spaghetti code.
|
| Comparing Reddit and Wikipedia is like comparing a motorcycle
| to a bicycle. They are different, with specific strengths and
| weaknesses. Both design/engineering paradigms have a place,
| imo.
| enraged_camel wrote:
| Yeah, I cannot even begin to imagine what it would be like to
| develop AirBnb without some sort of front end framework. I
| used to write pure JS and jquery back in the day, and it was
| super easy to end up with a rat's nest of spaghetti code. And
| those apps were several orders of magnitude less complex!
| jibe wrote:
| _You cannot wait on round trips to the server for user
| interactions_
|
| Old Reddit still works fine, and I'd argue better than new
| front end heavy Reddit. You are right it may be for the
| benefit developers, but Reddit isn't complicated enough that
| a heavy front end provides much benefit to the users.
| jonatron wrote:
| old.reddit feels fast, which is why I use the Old Reddit
| Redirect extension.
| JonathanBeuys wrote:
| Yes, I also use the old Reddit.
|
| What's funny is that the old Reddit makes use of dynamic
| loading of content here and there the _right_ way. The "load
| more comments" of the old Reddit is nice and fast. While the
| "continue this thread" of the new Reddit is annoying and
| slow.
| SpliffnCola wrote:
| Indeed it is; the UX/UI is also better compared to the low
| density of information with the new design.
| MrPatan wrote:
| I think I get it. You really don't want to shift your mind to the
| browser. Your mind is in the server, you know what's up in there,
| and distributed systems are complicated, so one of the ends
| should be made as dumb as possible. I get it.
|
| Except, guess where the mind of the user is? On the other side of
| the browser. Embrace the browser, server people, it's closer to
| the user!
| foresto wrote:
| There are user-focused reasons to build sites without
| (requiring) javascript.
|
| For example, respecting the wishes of users who disable scripts
| to avoid most of the web's privacy, security, and attention
| disruption problems.
| seydor wrote:
| Most of us are small-time businesses that never bought the
| overcomplexification of anything and we were constantly shamed
| about it. "Server-side-rendering" is still a laughable phrase
| though.
| boia01 wrote:
| Laminar (Scala framework) hasn't been mentioned yet so dropping
| it here as an awesome framework that support HTML-over-the-wire.
| It can be used together with React, HTMX, and many other frontend
| frameworks -- but doesn't have to be.
|
| https://laminar.dev/
| nawgz wrote:
| When I use apps like this - GitLab - I am struck by how much
| wasted user time such an approach leads to. Everything is a page
| refresh
|
| Send me some counter examples? Im a big SPA fan and there's lots
| of good examples
| hinkley wrote:
| Everything in a page refresh typically only happens with these
| solutions as a fallback when Javascript is disabled. And if
| Javascript is disabled, what do you really expect to happen
| other than everything is a hyperlink?
| beebeepka wrote:
| Isn't making a request for almost any user interaction a bit too
| much?
|
| I am more in favour of BE telling FE what to render. I honestly
| believe many apps could be simplified with better abstractions
| than hard coding html into messy components. Not saying it's a
| great approach for super complex layouts, of course.
| sodapopcan wrote:
| I'm talking about tech like LiveView, Hotwire, LiveWire,
| Blazor, etc. They use JS (in some cases with websockets) behind
| the scenes to send small bits of html which are patched into
| the DOM. The win here is that you can write all your business
| logic on the server and don't need an intermediary API for your
| frontapp to talk to your backend app, you just send HTML.
|
| If you're building an where you are going to open up an API,
| there is a little less benefit, but I've worked on projects in
| recent years where the API exists solely to be consumed by one
| client.
| [deleted]
| xjay wrote:
| This seems like a good time to ask web people to stop using the
| private unicode range for icons. It's bad practice because
| downloadable fonts are considered optional, and there is no
| fallback equivalent to alt text for undefined glyphs.
| thrownaway561 wrote:
| I was just watching a talk about htmx which is awesome looking.
| i'm a rails guy myself so i am really interested in using hotwire
| in some projects. htmx looks like a very nice crossplatform
| approach.
|
| https://htmx.org/
|
| Here is the talk: https://htmx.org/essays/a-real-world-react-to-
| htmx-port/
| rigoleto wrote:
| Unpoly (https://unpoly.com/) should be mentioned as well. Much
| like htmx but with more features.
| [deleted]
| jay-barronville wrote:
| I understand your frustration. I feel the same way. I think the
| web development landscape has become unnecessarily complex. I
| sometimes miss how simple it used to be to just throw some PHP
| files together and have a working website up and running.
| Granted, those "simple" websites came with their own set of
| issues (especially security-wise), but I still miss that
| simplicity.
|
| Over the past 10-ish years alone, I've watched web development go
| through so many phases, it's not even funny. Anyone remember
| gulp.js? Well, I remember a time when every conference talk
| mentioned it and you were weird if you didn't use it. Backbone.js
| anyone?
|
| In my experience, I've found that most folks can't even tell you
| WHY they use React or _insert JavaScript framework here_.
|
| Not too long ago, I was stepping through some "hello world" code
| for a trendy framework and the amount of code that was touched
| just to write "hello world" in the browser felt absolutely
| ridiculous to me.
|
| Let me stop myself before I go on a prolonged rant . . .
|
| Anyway, all that said, this is why I'm a fan of SvelteKit
| (Svelte) and Remix (React). I think they provide a decent balance
| of modern features while building on native web
| features/protocols properly.
| mgamache wrote:
| I have been using Blazor for projects in the last year. It's okay
| (still immature). It uses Websockets when available (HTTP
| fallback) to transfer the rendered page.
| yuzuquat wrote:
| I'm building a completely native HTML spa app over at lona.so
| (just html + js web components and i bundle it myself). Still
| very much so early days but check it out!
| freedomben wrote:
| FWIW most of the companies using Phoenix (Elixir) that I've
| talked with are sending HTML over the wire, either with LiveView
| or traditional Views.
| sodapopcan wrote:
| I used to work for one, but many companies using Phoenix want
| more years of Elixir experience than I have.
| pphysch wrote:
| We are using Django+HTMX for internal applications.
|
| Some random tips:
|
| - Write a "Django context processor" to inspect requests for "Hx-
| Request" header, and set a "base_template" variable accordingly.
| This means that any template that {% extends base_template %}
| will react to being a full page or just a fragment and you don't
| even have to think about that in your view logic. Great for
| progressive enhancement.
|
| - You can get reactive JS elements (for example, a d3.js viz that
| updates when new data comes in) in a few lines of inline JS by
| using MutationObserver, and "abusing" HTMX by using views that
| return JSON targeting a <script> element (`json_script`
| templatetag can also be used here). In summary, you tell your
| fancy JS element to render or update whenever a particular
| <script> element is mutated, and all of it is orchestrated by
| HTMX.
| greenie_beans wrote:
| do you have any code examples you'd be able to share that uses
| the base_template thing?
| pphysch wrote:
| Sure, Django docs say this about custom context processors: h
| ttps://docs.djangoproject.com/en/4.1/ref/templates/api/#wri..
| .
|
| So in my context_processors.py file, I write something like:
| def base_template(request): template =
| "templates/base.html" # full page if "HX-
| Request" in request.headers: template =
| "templates/base_ajax.html" # minimal template
| return {"base_template": template}
|
| And then my template just needs to start with `{% extends
| base_template %}`. Nothing needs to be done in the view
| (although you could technically override "base_template"
| there, if you need to).
| leishman wrote:
| We've used LiveView/Phoenix for 4 years at River.com and are very
| happy with it.
| reaktivo wrote:
| Basecamp, Github
| [deleted]
| noughtme wrote:
| yeah, i thought github was moving away from html over the wire;
| rails to react.
|
| https://news.ycombinator.com/item?id=33576722
___________________________________________________________________
(page generated 2023-02-10 23:01 UTC)