[HN Gopher] How a hypermedia approach can address usability conc...
___________________________________________________________________
How a hypermedia approach can address usability concerns with
multi-page apps
Author : j4mie
Score : 148 points
Date : 2021-12-26 16:12 UTC (6 hours ago)
(HTM) web link (htmx.org)
(TXT) w3m dump (htmx.org)
| ravenstine wrote:
| > And, contra what Mr. Harris says, today the trend is not
| obviously in javascripts favor. Five years ago, we, as founding
| members of the javascript resistance, were despairing of any hope
| of stopping the Javascript juggernaut. But then something
| unexpected happened: Python took off and, at the same time,
| javascript flat lined:
|
| Why yes... if you use Stack Overflow usage as your measurement.
|
| The problem is that doesn't tell you anything about JavaScript or
| Python... except whom is using Stack Overflow.
|
| As a JavaScript developer (primarily), I use Stack Overflow far
| less than I did in years past, not just because I need less help
| in general as a senior, but because SO is so littered with JS
| answers that are outdated, poor quality, and conflate JavaScript
| with _jQuery_ , that it's simply not worth using 99% of the time
| because MDN provides excellent documentation.
|
| It's been a while since I've used Python, so maybe things have
| changed, but I remember the documentation not being comparable.
| It's _good_ documentation, but MDN is _excellent_.
|
| I'm not saying that either one is better, but that to use Stack
| Overflow trends to prove a point seems very fallacious. By that
| point I couldn't finish the rest of the article.
| divbzero wrote:
| Even if we assume that Stack Overflow is a good proxy for
| overall language usage, OP does not account for the fact that
| Python is used more broadly than JavaScript in non-web use
| cases -- _e.g._ the use of Python for machine learning.
| recursivedoubts wrote:
| The good news is that there wasn't much left in the article
| save a silly meme. Although perhaps this is worth pondering:
|
| _> We are fond of talking about the HOWL stack: Hypermedia On
| Whatever you 'd Like. The idea is that, by returning to a (more
| powerful) Hypermedia Architecture, you can use whatever backend
| language you'd like: python, lisp, haskell, go, java, c#,
| whatever. Even javascript, if you like. There's no accounting
| for taste, after all. Since you are using hypermedia & HTML for
| your server interactions, you don't feel that pressure to adopt
| javascript on the backend that a huge javascript front end
| produces. You can still use javascript, of course, (perhaps in
| the form of alpine) but you use it in the manner it was
| originally intended: as a light, front end scripting language
| for enhancing your application. Or, if you are brave, perhaps
| you can try hyperscript for these needs.
|
| > This is a world we would prefer live in: many programming
| language options, each with their own strengths, technical
| cultures and thriving communities, all able to participate in
| the web development world through the magic of more powerful
| hypermedia, rather than a monolith of SPAs-talking-to-Node-in-
| JSON. Diversity, after all, is our strength._
| [deleted]
| davidmurdoch wrote:
| My gripe with Stack Overflow is that TypeScript and JavaScript
| is now what is conflated by question askers.
| noduerme wrote:
| That seems like it would only be a problem if you're looking
| for Typescript answers, right? Like, ignore the typings in
| Typescript and in most cases you have vanilla JS (or ES6,
| anyway)...
| seumars wrote:
| I'm sorry but what's the point here? Rich's talk was not even
| remotely aimed at HTMX yet this article is nothing but a
| shameless list of HTMX features.
| bckr wrote:
| > htmx.org
|
| > We have been asked for our opinion on the talk, so this essay
| is our response
|
| I had the same question, answered by the above.
| recursivedoubts wrote:
| The point is that the hypermedia approach, which is what htmx
| (among other technologies, such as hotwire and unpoly) takes,
| can address many of the usability criticisms that Mr. Harris
| levels at MPAs, without abandoning the fundamental REST-ful web
| architecture.
| seumars wrote:
| In that case it would be much more interesting to read about
| the "hypermedia approach" including its own downsides. For
| instance, the differences between SPA/MPA implementations are
| also directly linked to developer experience - most people
| simply prefer business logic to live inside components. Is
| that possible using a hypermedia approach? Who knows, but "we
| think our library is great" isn't particularly an instructive
| or interesting way of discussing this topic.
| recursivedoubts wrote:
| you can find many such articles on the talk page at htmx:
|
| https://htmx.org/talk
|
| in this article we respond to specific criticisms of MPAs
| in terms of htmx, as it is a response to Mr Harris's talk
| qbasic_forever wrote:
| Read the third sentence of the link, they say they were
| explicitly asked to write about their/HTMX's response to
| Richard's talk.
|
| "We have been asked for our opinion on the talk, so this essay
| is our response."
| danpalmer wrote:
| The point is that Rich suggested that SPAs are the only way to
| solve these problems, and that MPAs can't. This is a rebuttal
| from HTMX suggesting that MPAs can in fact solve these
| problems.
| earthboundkid wrote:
| Rich wasn't arguing for SPA but for hybrid SSR, so that seems
| like it's a non-sequitur.
| recursivedoubts wrote:
| As we mention in the article, we agree w/ Mr. Harris on the
| hybrid approach, but disagree on whether or not hypermedia
| or javascript/RPC should be the "primary" model.
| seumars wrote:
| No, the entire point of borrowing the term _transitional_ is
| "having the best of both worlds". The SPA/MPA comparison is
| about highlighting the best aspects of each method and
| envision ways of implementing both. Any decent framework
| nowadays can be used to implement "transitional" features, so
| HTMX using this as a way to plug their own is lazy and
| annoyingly counterproductive in this particular discussion.
| recursivedoubts wrote:
| we were asked multiple times for a response to Mr. Harris'
| talk, and so we gave one
|
| i think you are missing the hypermedia vs. RPC aspect of
| the discussion, and the javascript-everywhere vs.
| Hypermedia-On-Whatever-you'd-Like aspect of it, which i
| believe are relatively unique in the discussions i have
| seen
|
| but, it is fair, both laziness and self-promotion are
| forever a danger for me
| seumars wrote:
| I get the argument, though I wouldn't call it unique
| given how long _JS fatigue_ has been a thing. HTMX is
| just one piece of the puzzle though so a more correct
| comparison would be a mature application built with htmx
| vs say sveltekit, not a list of cherry picked htmx
| features.
| recursivedoubts wrote:
| I reiterate, I was responding to Mr. Harris'
| presentation, and showing how a hypermedia approach can
| address his specific concerns with MPA applications.
| There are other more comprehensive and philosophical
| articles (as well as podcasts, etc.) available on the
| talk page.
|
| A sibling comment offers a perhaps useful comparison:
|
| https://news.ycombinator.com/item?id=29695531
| hstaab wrote:
| Can anyone recommend a good resource for comparing htmx with
| alpinejs? I've seen them both mentioned here but their
| differences are not clear to me.
| recursivedoubts wrote:
| The two complement one another well: htmx for exchanging HTML
| with a server and alpine.js for pure front end stuff (e.g.
| toggling a class)
|
| hyperscript, our other project, is a more direct competitor w/
| alpine:
|
| https://hyperscript.org
| qbasic_forever wrote:
| Alpine is a lot closer to jquery than htmx IMHO--I think of it
| in a very similar way as what people used to use jquery for all
| the time (adding event handlers and logic to DOM elements).
| noelwelsh wrote:
| I'm not sure these are actual problems (other than JS tooling,
| which I find opaque.) Instagram works just fine for the vast
| majority of people. It's taken as gospel that Javascript
| frameworks are "bloated" but 1) is this really true; and 2) if
| true does this really matter if the page loads fast enough? React
| is only 5.3kB and gives a very simple model for reasoning about
| code. Making code smaller or faster has a cost.
|
| I'll also note that htmx is making a programming language, but
| they don't seem to understand they are making a programming
| language, and that usually ends up a disaster. See all the YAML
| stuff in the devops world.
| recursivedoubts wrote:
| Ah, and this is precisely where you make your bloomer: we are
| not making _a_ programming language.
|
| Rather, we are making _two_ programming languages:
|
| https://hyperscript.org/
| feupan wrote:
| React is _not_ only 5.3kb because that's not the only piece you
| will need to actually use it. Check out the bundle of CRA for a
| real-world example.
|
| I agree with the general sentiment though. I think the issue is
| that it's easy to just import the whole npm registry in a
| bundle and ship it -- and it's too hard to trim it down.
|
| For you a 2MB bundle is ok, but for me it's taking 30 seconds
| to open this site and I'm standing here. That's not ok.
|
| Frameworks like Next.js provide a sane base for this; Most
| others don't.
| dreamcompiler wrote:
| This is absolutely the right approach for building web sites IMO.
| It's the best mix of whatever-server-you-want-to-use and minimal
| JS on the client.
|
| I built my own (proprietary for my employer) general-purpose AJAX
| etc framework that uses minimal javascript to produce flexible,
| interactive web sites with 1/100 the bulk of React. It even
| degrades gracefully for clients that don't run JS. But I'm tired
| of maintaining it. HTMLX looks like an even better approach
| because it doesn't seem to require me to add explicit event
| handlers all over the place and it's open source so I won't be
| the sole maintainer.
|
| Looking forward to evaluating HTMLX as a replacement for my
| stuff.
| Kiro wrote:
| Doesn't using something like hx-preserve effectively make it an
| SPA? It makes an AJAX request and replaces part of the DOM.
| What's the difference?
| deniska wrote:
| The difference is not having to touch NPM.
| recursivedoubts wrote:
| And also staying within the original hypermedia model of the
| web.
| qbasic_forever wrote:
| That's the point, it is basically a SPA but without all of the
| complexity and (over)engineering of using a modern JS frontend
| stack.
| pictur wrote:
| I don't mean to belittle anyone, but libraries like htmx are
| rather primitive compared to tools like svelte. What makes them
| see themselves so important?
| recursivedoubts wrote:
| From the article:
|
| _> This is, unfortunately, part of the culture of front end
| development right now: sky-high levels of complexity are
| tolerated in application frameworks, in build tool chains, in
| deployment models and so on, and, when problems arise due to
| all this complexity, more complexity is often offered as the
| answer.
|
| > "Simple" is disparaging and "sophisticated" is high praise._
|
| So, rather.
| kanonieer wrote:
| Seconded.
|
| There was a series of similar Twitter discussions when a
| popular JavaScript "influencer" published an article[0] on
| how they built their website. The amount of complexity that
| is self-inflicted in the said article was obviously enormous
| for proponents of MPAs.
|
| However the JS community mostly echoed that the complexity
| was absolutely within norm. The cultural chasm between JS
| developers and people who push for simplicity was huge. And
| the refusal to admit the unnecessary complexity was nothing
| short of Stockholm Syndrome, imho.
|
| [0] https://kentcdodds.com/blog/how-i-built-a-modern-website-
| in-...
|
| This was the HN reaction to the article:
|
| https://news.ycombinator.com/item?id=28818829
| spinningslate wrote:
| Thirded (if that's a thing).
|
| I've been working recently on two code bases: one using
| angular and the other htmx (with python/jinja2/FastAPI).
| Both aiming to deliver broadly comparable interaction - so
| approximately comparable in essential complexity.
|
| In a month, or a year, I'm confident I'll be able to check
| out the htmx app and work with it pretty much right away.
| The dependencies won't have changed much; the build will
| still work; and I'll be able to understand the code. I will
| lay bets now that the same will not be true of the angular
| app. On any one of those three counts.
|
| If simple, understandable, stable and effective are what
| GPP meant by "primitive", then I want more "primitive"
| tools like htmx.
|
| Light sabres, not death stars.
| Dumbassdev wrote:
| unionpivo wrote:
| That often it's enough ?
|
| You don't need jumbo jet to deliver pizzas locally.
| leetrout wrote:
| I dont think it has to be all or nothing. I think the best answer
| is to use both technologies as appropriate even in the same app.
|
| I was writing something like htmx without intercooler with
| Angular with Django (which I fondly called Djangular) in 2013.
|
| It just needed yet another framework type abstraction to reduce
| the boiler plate.
|
| Send json with the html on initial page load, use the json api to
| load addition data, hard navigate between "sections" of the app
| but tabs and such were SPA pattern.
|
| I think a middle ground combo of svelte and htmx is a killer idea
| (similar to all the "live view" stuff people are loving).
| recursivedoubts wrote:
| Indeed that is what Mr. Harris calls a "transitional" app, and,
| with him, I can recommend that approach.
|
| The difference between us on that matter would be that I would
| recommend leaning hypermedia, whereas, at the risk of putting
| words into his mouth, he would appear to lean SPA/RPC as the
| default approach.
| akiselev wrote:
| _> The difference between us on that matter would be that I
| would recommend leaning hypermedia, whereas, at the risk of
| putting words into his mouth, he would appear to lean SPA
| /RPC as the default approach._
|
| Isn't the default essentially @svelte/kit now? That's got SSR
| built in and a preloading layer that's much closer in nature
| to HTMX than to an SPA framework. RPC just happens to be the
| easiest way to abstract out data for static sites, SPAs, and
| runtime SSR.
| kingcharles wrote:
| We also have to accept that some dynamic page problems are
| completely unsolvable or have horrible solutions.
|
| For instance, with infinite scroll - I spend 10 minutes scrolling
| down through 7000 rows, with all but the first few loaded
| dynamically.
|
| I now want to send what I'm looking at to a friend. Or I want to
| bookmark it. Sure, I can have my app put the scrollposition in an
| anchor tag in the URL, but what happens when that URI is
| navigated to? Whatever solution you pick, it is horrid.
| bryik wrote:
| > CPU is cheap, network speeds are fast and increasing and
| microservices are a mess.
|
| Is CPU cheap? I can literally host a static site or SPA on GitHub
| Pages for free. Where can I get free CPU time for an htmlx
| application?
| luckylion wrote:
| > Is CPU cheap? I can literally host a static site or SPA on
| GitHub Pages for free. Where can I get free CPU time for an
| htmlx application?
|
| Cheap != free, but the large cloud providers all have a free
| tier.
| recursivedoubts wrote:
| You can host an htmx-based site on Github Pages for free as
| well.
| bryik wrote:
| Does that fit with the philosophy of htmx? It looks to me
| like htmlx expects a server?
| recursivedoubts wrote:
| htmx simply expects hypermedia/HTML
|
| whatever can serve that can be used with htmx: it is
| intended as a straight-forward extension of HTML
| qbasic_forever wrote:
| Github pages hosting your static content is a server...
| Dauros wrote:
| You can combine HTMX with a SSG like Hugo and generate a
| bunch of partial HTML files that HTMX can load later on
| request. No server is required.
| ng12 wrote:
| God, I am so tired of these arguments. We need to stop bike-
| shedding web technology. You will never, ever convince me to go
| back to server-side rendering for the type of work I do. Are
| there other domains where that would be the wrong choice?
| Absolutely.
|
| The web is a platform and we should not treat these tools as one-
| size-fits-all. Use the tools that fit your use case; there's no
| use in talking about the how without the why.
| lucasyvas wrote:
| Having written SPAs in multiple frameworks over the years, I am
| finally starting to favour the author's perspective.
|
| That said, the one criticism I can lob is toward the assumption
| that JavaScript / TypeScript will be the only path for SPAs,
| creating a full-stack monoculture. Web Assembly is on its way to
| negating this point long term.
|
| I don't think this affects the position on MPAs, but weakens that
| one particular argument against SPAs.
| feupan wrote:
| I'm confused here: htmx is not an MPA. If it were, then you'd
| call a SSR React site a MPA too.
|
| The core behavior of a SPA is that it loads pages via ajax and
| just replaces content in the current "document". The difference
| between a simple SSR React site and this is that React will only
| fetch JSON and templates after the first load, whereas this one
| fetches whole chunks of HTML.
|
| An htmx site still has to deal with all the pitfalls of SPAs,
| namely non-native navigation and history, and memory leaks.
|
| Just like htmx may have solved some of these issues, a (other
| framework) SPA can do too.
| recursivedoubts wrote:
| there is a spectrum, as Mr. Harris discusses in his talk
|
| the core difference between htmx (and hotwire, unpoly, etc) and
| most SPA frameworks is that they stick closer to the original
| hypermedia model of the web, thereby saving a lot of complexity
| and additional abstraction
| mitchtbaum wrote:
| I like the potential for sending minimal document
| elements/objects, though it seems like HTMX/Intercooler/Unpoly
| features should be built into the browser. Unpoly, for example,
| has its own entire reimplementation of fetch():
|
| https://github.com/unpoly/unpoly/blob/4854c7ccb268890a9522c6...
|
| and it uses several X-HTTP-Headers, which could be standardized.
|
| Do any browsers have the early workings of a "native web
| application sdk"?
| gorgoiler wrote:
| Regular server/client beats SPA because each request starts with
| an empty state, whereas SPAs build up bugs as they try and fail
| for mutate state over time.
|
| What about an SPA that made internal requests to a server
| backend, running in the browser?
| nawgz wrote:
| > each request starts with an empty state
|
| Strange place to post such a ... misguided stance. HTMX
| regularly brags about how it's meant to be used to mutate the
| DOM the user already has loaded, thru custom HTML attributes
| handled by their JS framework.
|
| You're just arguing in favor of HTML, but HTMX is trying to
| have their cake and eat it too. JS-level state is clearly
| easier to manage than DOM-level.
| recursivedoubts wrote:
| Well, using Hypermedia As The Engine of Application State
| doesn't seem too... outside the lines of the web.
| nawgz wrote:
| Yes, a giant tree representing a view layer which blends
| data with presentation is clearly the canonical
| representation of app state...
| recursivedoubts wrote:
| Well, according to Roy Fielding...
| Dumbassdev wrote:
| clownworldclown wrote:
| contrary to most of the comments I'm in full agreement with the
| hypermedia approach. This is an exciting development, especially
| with hyperscript!
|
| I actually attempted to make a "simplified" "js" framework (where
| you just had some html tags and it did things for you) for tasks
| congruent to alpine (since I found alpine rather complex, or that
| it comes with so much but you still have to do a good amount of
| work to get things working) but I'm not as savvy; using the DSL
| you all have in hyperscript is real smart, simple.
|
| Not too long ago I looked into using Svelte for a one-off project
| (since it was the highest rated framework at the time) which then
| prompted me to look into the current state of web development.
|
| It's absurd, and left such a sour taste that I just shelved the
| project for another time.
|
| Great stuff you guys got going here, it makes me excited to see
| what'll turn into in the future! Looking forward to trying this
| out later.
| divbzero wrote:
| I agree as well.
|
| SPAs might be the right approach for specific applications that
| are actually applications ( _e.g._ text editors, Jupyter
| notebooks, chat and other web apps) but more generally the web
| is designed from the ground up to work well with separate pages
| representing separate resources.
| noduerme wrote:
| Although a multipage text editor would be rather charmingly
| annoying.
| inwardsword wrote:
| Not withstanding that HTML and the DOM are garbage to work with
| in any language
| austincheney wrote:
| The DOM is a tree model. Navigating a tree is highly
| imperative. Developers allergic to imperative code tend to
| require unnecessary abstractions to make sense of the
| technology. Everything that follows is a foot gun of dependency
| hell.
| qbasic_forever wrote:
| I'll take manipulating and working with the web DOM _any_ day
| over going back to old Win32, MFC, and other native
| abominations.
| recursivedoubts wrote:
| hello, I am the author of this article
|
| it is a response to a talk that Mr. Harris gave at JamStack
| entitled "Have Single-Page Applications Ruined the Web?":
|
| https://www.youtube.com/watch?v=860d8usGC0o
|
| in the article I show how a hypermedia-oriented (rather than
| javascript-oriented) library like htmx can address many of the
| usability concerns that Mr. Harris raises with MPAs, without
| abandoning the fundamental REST-ful architecture of the web for a
| more RPC-like javascript architecture.
| chias wrote:
| As someone who has been developing websites for 15+ years and
| who stumbled across HTMX a year or two ago, I want to add a
| couple things here:
|
| One really _really_ nice thing about HTMX is how easy it is to
| "spruce up" a UI. You say "this part of my website could really
| do with some active content" and you start thinking about
| xmlHttpRequest and callbacks and and JSON and all that and you
| think "does it really _need_ sprucing? ". But with HTMX it's
| usually just adding a couple hx- attributes and maybe a couple
| serverside lines and you're done.
|
| Another really _really_ nice thing about HTMX is how easy it
| makes it to make things degrade gracefully. Javascript enabled?
| Get your beautiful ajax. No Javascript? Get a good experience
| in the "traditional" model. In anything else I've ever seen,
| if you want that experience, you need to write your UI twice
| (and usually in two different languages / models).
|
| So basically it drastically lowers the bar for making nicer
| experiences on top of a solid MPA. Especially if you're a solo
| developer, this basically means that you end up producing
| better UIs "for free".
| dang wrote:
| I've changed the title above to try to say what the article is
| about, using your wording here (but edited to fit HN's 80-char
| limit). In cases like this we try to avoid references to
| personalities. (We also try to avoid acronyms where possible,
| which is why I said 'multi-page apps' instead of 'MPAs'.) If
| there's a better title, i.e. a more accurate and neutral one,
| we can change it again.
| flapjackfritz wrote:
| I don't think a lot of the points in the article hit home for
| me.
|
| On one hand you suggest the culture of complexity is
| overwhelming, when just a few paragraphs earlier you suggest
| that sql-tuning and redis caching are how to deal with some of
| htmlx's problems with latency. That seems highly complex. You
| have to make deep changes to the back-end and data persistence
| systems to solve a front end issue.
|
| It feels like the article is trying to say you shouldn't use
| javascript frameworks in a lot of cases, but then it advocates
| for using htmx, which is a javascript framework, in those
| cases?
|
| In my experience the issues people have in front-end come from
| using tools and frameworks incorrectly, because they don't
| understand the tradeoffs being made -- so they don't account
| for those tradeoffs in a reasonable way that eventually comes
| back to bite the team. Handing people a new JS library that is
| seeming to intend we completely avoid javascript and therefore
| the library itself, creating an incentive not to learn how it
| works.
| satyrnein wrote:
| It seems like there are broadly 2 concerns: having rich
| interaction inside of a single "page", and smooth transitions
| between "pages". You seem to dismiss the latter in your
| article, but HTMX seems to support Turbolinks style
| functionality, correct? Can animations be layered onto that?
|
| I did some experiments around on how to do animated shared
| element transitions (as well as reactive functionality) within
| a REST mindset here, if anyone's curious:
| https://dev.to/eshan/toward-the-postmodern-web-38h (you can
| just scroll to the embeds)
|
| Ultimately, maybe the browser vendors will do something here,
| like Google's portal elements, for example. A lot of effort is
| being spent on that flash during page loads.
| jonathan-adly wrote:
| HOWl is a good idea.. either it will catch on and make web
| development fun again, or it will at least force the JS ecosystem
| to wake up and fix its terrible tooling and bloat.
| cdata wrote:
| Anyone who claims one language or tech stack is going to become
| the be-all, end-all of how we build things on the web is either
| naive or selling something.
|
| I've gotten a lot of mileage out of ignoring grandstanders and
| focusing my time and energy on learning how browsers work. If you
| understand the DOM, CSS and core JavaScript fundamentals, you can
| apply your skills to virtually any front-end stack.
|
| In the end, the thing that hurts the web the most is complexity
| in the name of DX. We are tricked into thinking that the simple
| thing is too hard to learn on the one hand, while being asked to
| juggle multiple layers of "sophisticated" abstraction on the
| other. These days there are entire businesses rising on the need
| to reduce the cognitive load created by our layers of
| sophisticated abstraction. But, I bring you the good word: you
| can still build incredible experiences without pulling in most of
| the complexity (and without sacrificing as much DX as you think).
| 88913527 wrote:
| Angular and React were a response to the problem of
| abstraction-less frontends: spaghetti jQuery, piled ten miles
| high. I appreciate the concern for over-abstraction introducing
| unnecessary complexity, but there's got to be a point on the
| continuum of spaghetti-jquery to react+redux+node_modules
| that's the sweet spot. If you're choiceful in what tools you
| use, you can have that in 2021. It doesn't have to be overly
| complex (though you certainly _can_ make it that way).
|
| By building apps using 100% client-side rendering with GraphQL
| and Rest APIs, I can use tools like Storybook to build a user
| interface that are easy to automate testing and ultimately, and
| consistently, ship enterprise-grade UIs. All my apps are behind
| auth walls. If need SSR, there's tools like Next.js.
| mattlondon wrote:
| Ironically this is why I prefer angular to react - people say
| angular is more complex, but IMHO it removes complexity by
| being "batteries included": reduced cognitive load because and
| angular project is an angular project so you only need to learn
| angular itself, and not a zillion extra libraries or
| frameworks.
| unclebucknasty wrote:
| Agree. The other thing I'd add is that we're long overdue for a
| more fundamental paradigm shift in webdev.
|
| That is, we've changed our goal from the original page
| request/response model to one of delivering native-like SPA
| experiences. But, the frameworks that win don't fundamentally
| reconsider the old technology. Instead, they stop at the DOM
| layer, speak heavy HTML/CSS, make us manage browser mechanics
| like URLs, history and back buttons, and help us to better
| manage those old Web constructs while keeping them in focus.
|
| So, they've added these abstraction layers that just keep
| piling up.
|
| At some point we have to ask whether this is fundamentally the
| right approach.
| jcelerier wrote:
| Check out Canonic https://www.canonic.com/ for an
| experimental take on an alternative web
| projektfu wrote:
| Was that supposed to do something other than show half a
| page and not respond to clicks and scrolls? iOS 15 on
| iPhone SE 2.
| csande17 wrote:
| On my MacBook, canonic.com displays a few sentences of
| text and a few links. To do this, it takes 15 seconds to
| load a 25 megabyte WASM payload. The resulting page draws
| all of its content onto a <canvas>, scrolls backwards
| because it somehow ignores my system's "natural scroll
| direction" setting, and doesn't let me right-click to
| open links in a new tab.
|
| In other words, it's a demo of what Web performance and
| usability will be like ten years from now. Twitter and
| Reddit are already working on redesigning their websites
| to incorporate this new technology.
|
| (In all seriousness, it's a demo of a subset of Qt
| compiled to run in a web browser, and it seems to work
| better on desktop.)
| nawgz wrote:
| Indeed... double digit seconds to load and then it isn't
| responsive and doesn't respond to touch events. A bit
| under baked, to say the least
| toastking wrote:
| I think they're overlooking a very big issue which is trying to
| do any sort of business logic in a markup language is terrible.
| HTML is good for presentation, trying to embed logic like
| retrying requests in it can lead to weird code. The reason people
| like Javascript is having a fully C-style language for things
| makes logic easier to read and maintain.
| seumars wrote:
| Agreed. Judging from this example:
| https://github.com/rajasegar/htmx-trello which uses htmx in pug
| templates combined with hyperscript the results are... dubious
| and hardly scalable.
| Dumbassdev wrote:
| Verydumbass wrote:
___________________________________________________________________
(page generated 2021-12-26 23:00 UTC)