Both TST and Sidebery are leagues ahead of tab groups IMHO. Frankly sidebar tabs just work better for 16:9 aspect ratio because with a maximized window most sites don't make good use of 1/4 of the width anyway.
When I initially read the htmx documentation I was confused because it kept talking about a hypermedia client. The context clues suggested they were referring to htmx but my brain kept saying "isn't the browser the hypermedia client?" Eventually it sank in that htmx is an extension of the hypermedia client. When I first tried to use htmx I experienced a lot of discomfort regarding areas where htmx feels non-standard, such as redirects in the hx- readers on a 200 response. Once I understood that htmx is explicitly trying to move the boundary of the hypermedia client a lot of that discomfort melted away.
Yes htmx is an augmentation of the browser, specifically through enhancing HTML by way of JS. The idea is that JS frameworks became popular due to the lack of additional hypermedia controls which are the basis for how agents (users) interact with websites through hypermedia clients (browsers).
If you're going to get that picky (and please be aware I'm only doing this for the sake of the argument) media can never be hypermedia in the absence of the client. HTML opened in notepad is just text. Cat GIFs, rendered in the correct client, would absolutely be hypermedia (you could inline link data as QR codes, if you felt like being perverse).
Hypermedia starts with the client, not with the file format.
I agree that a hypermedia can't act properly within the uniform interface constraint, without a hypermedia client, that is, you can't have a hypermedia system without a proper hypermedia client:
On the other hand, there is a real difference between plain text and HTML (or HXML, don't shoot!) which is a subset of text with additional concepts layered on top of it. This is akin to how JSON (or XML) is not hypermedia, but can be used to create hypermedia such as Siren or HXML.
So I still think it makes sense to discuss if a media is or is not hypermedia without reference to the client, whereas it doesn't make sense to claim it is being used as hypermedia unless it is being consumed by a properly written hypermedia client. To make my thinking concrete, I believe Siren would continue to be hypermedia, even if it wasn't be consumed properly by a client, but then also you could not describe that pairing as a hypermedia system. (This is one reason I focus on the systemic nature of hypermedia, rather than solely on hypermedia formats)
Semantic nitpicking perhaps, but then hypermedia discussions appear to tend to invite this sort of thing.
> HTML (or HXML, don't shoot!) which is a subset of text with additional concepts layered on top of it. This is akin to how JSON (or XML) is not hypermedia
So, HTML is different from plain text because it "has concepts layered on top of text" where as JSON is not hypermedia despite "having concepts layered on top of text". And the only reason is because you said so.
> So I still think it makes sense to discuss if a media is or is not hypermedia without reference to the client
Then JSON is just as much hypermedia as HTML. Both are structured text unusable without a specific client to display them or work with them.
> Semantic nitpicking perhaps, but then hypermedia discussions appear to tend to invite this sort of thing.
They only invite them because of your insistence on calling only HTML the "natural hypermedia" etc.
No, the reason is because HTML qua HTML has hypermedia controls and JSON qua JSON does not. Recall that, before I pointed out the widely used and accepted definition of hypermedia controls, and in particular that links and forms are hypermedia controls, you did not understand that concept, so you might spend some time quietly reflecting on that idea. It may help clarify things for you.
> Then JSON is just as much hypermedia as HTML. Both are structured text unusable without a specific client to display them or work with them.
As I have said and written previously (https://htmx.org/essays/hypermedia-clients/, https://hypermedia.systems/hypermedia-components/) I agree that a hypermedia client is necessary for a properly functioning hypermedia system that adheres to the uniform interface. However, I think that there is a good argument that Siren, for example, is hypermedia, even if it isn't being consumed correctly, just as I think HTML is hypermedia, even if someone is screen scraping it (i.e. not using a hypermedia client to consume it).
I don't think you can call those uses a hypermedia system, but I also don't think that changes the fact that the underlying formats, Siren & HTML, are hypermedia, due to the fact that they have hypermedia controls. That might be a subtle distinction, but I think it is a valid one. Again, perhaps as you reflect more on this concept, new to you, of hypermedia controls, the distinction will become easier to understand.
> They only invite them because of your insistence on calling only HTML the "natural hypermedia" etc.
I'm very sorry you that feel that way.
I would call HTML, "a natural hypermedia", rather than "the natural hypermedia". I would also call HXML & Siren natural hypermedia, due to the presence of hypermedia controls (a concept new to you) in their specifications.
Yeah, I went overboard with the example. The issue is that HTMX tries to take over the concept of hypermedia as if it means only HTMX and whatever HTMX is doing :)
Htmx posits that current browsers aren't "truly" hypermedia since only anchor tags and forms can initiate GET/POST requests. It is more of a tech demo showing what client with ANY tag being able to do requests would look like.
That's why whether it is library/framework is besides the point. The author posits that these features should be in the spec, and tries as closely as possible to show what something might look like if we had it in the spec
> The author posits that these features should be in the spec
Does he? The author pretends that his library is what hypertext and hypermedia are as envisioned by Time Berners-Lee and Roy Fielding, and that his approach is the only true representation of both. And that's about it. Nothing about "this should be in the spec"
Um, yes friend, that’s exactly what it’s trying to be. Carson has said numerous times that in an ideal world, the html spec would evolve to the point the htmx becomes redundant.
It’s not about htmx or any library/framework - it’s about extending html.
If that doesn’t convince you, then I’ve got nothing and suggest we both just go and enjoy some lazer horse/buffalo/pickle memes in the htmx twitter account
> The author pretends that his library is what hypertext and hypermedia are as envisioned by Time Berners-Lee and Roy Fielding, and that his approach is the only true representation of both.
Of course you're not. And I already pointed it out to you elsewhere. Your entire writing and marketing revolves around one idea, and one idea only: HTML is "natural hypermedia", and everything else is not.
OK, this is just completely unreasonable of you. HTML is a natural hypermedia in that it has native hypermedia controls. JSON & XML are not natural hypermedia because they do not, however hypermedia controls can be added on top of them, as in the case of HXML/hyperview, which, again I include in my book on hypermedia systems.
There are many other hypermedias, such as Siren, which uses JSON as a base, and I have never claimed otherwise. Mark Amundsen, perhaps the worlds expert on hypermedia, wrote the forward to my book, Hypermedia Systems, and found nothing objectionable and much worthwhile in it.
I hate to be rude but you didn't understand, or refused to acknowledge, the basic meaning and usage of the term 'hypermedia control' until I cited a W3C document using it. While I certainly understand people can dislike the conceptual basis of htmx, its admittedly idiosyncratic implementation or the way we talk about it, at this point I have tried to engage you multiple times in good faith here and have been rewarded with baseless accusations of things I haven't said and don't believe.
At this point, to be an honest person, you need to apologize for misrepresenting what I am saying multiple times to other people. It is dishonest and it makes you a liar, over something as dumb as a technical disagreement.
> I hate to be rude but you didn't understand, or refused to acknowledge, the basic meaning and usage of the term 'hypermedia control' until I cited a W3C document using it.
Just because you were correct in one small detail (citing a 2019 standard retrofitting definitions for the use in RDF etc.) doesn't make you correct in the grand scheme of things.
> with baseless accusations of things I haven't said and don't believe.
I literally quoted your own words at you.
> you need to apologize for misrepresenting what I am saying multiple times to other people.
I will not apologize for things that I even quoted from your own writing and words.
the presence of hypermedia controls is a defining characteristic of a hypermedia format
> I literally quoted your own words at you.
You took an essay I wrote in which I defined the term HDA specifically to contrast with the term SPA in the context of web development and spun that into an imagined philosophy where HTML is the only hypermedia in the world. You persisted in this after I pointed out that I included HXML in my book on hypermedia, and gave a clear definition of what I consider the defining characteristics of hypermedia & clarified specific examples of other formats that are hypermedia.
You have confused "X is A" with "Only X is A" and then, when large gaps in your understanding of hypermedia have been brought to your attention, you have dismissed them as small details.
> I will not apologize
I did not expect you to.
At this point I think I have taken goodwill as far as it can go. I encourage any other readers who have made it to this point in this hellthread to simply read my essays & perhaps my book, and judge them on their own merits:
At this point you are very loudly and publicly grinding your axe to the point that you’re telling someone to their face that they don’t understand their own viewpoint. Putting aside briefly the insanity and futility of that, it makes for a bad experience for literally everyone else.
I feel the same way. Legacy vimscript certainly had some warts but vim9script has been much nicer IME than lua. Elsewhere I've likened vim9script to typescript 1.0. It has just enough types to be useful but not enough to let you go down a rabbit hole. That's sort of the sweet spot when scripting another application.
Specific plugins I use all the time: bufexplorer (though I've mostly rewritten it), ctrlp, colorizer, syntastic, vim-commentary, vim-projectroot, vim-surround, zeavim (Zeal integration, similar to Dash on macos).
I don't disagree with anything you've said but I would personally take this line of argument a step further. I think Bram learned from the neovim fork. Neovim bolstered the existing lua support by reducing the impedance mismatch between the lua language and the vim host. A lot of people enjoy writing lua more than vimscript but the value-add hasn't proved compelling enough for people who didn't mind vimscript. The official neovim repo still has twice as much vimscript code as it has lua code. Even if you claim vimscript is 2x as verbose that would still leave them on equal footing within the project that is putting lua forth as an equal competitor.
My impression of vim9script is that Bram had a list of goals (clearly outlined in the docs) and saw the typescript project as a model to follow. The docs themselves mention typescript as a source of inspiration for some features. The typescript project had a similar set of goals and managed to gain massive adoption both among people who had previously disliked javascript (due to the improved semantics) and people who had previously like javascript (due to the speed improvements, transpiler ergonomics, etc).
> The official neovim repo still has twice as much vimscript code as it has lua code
Much of that is "just" the runtime files (things that define language syntax, etc), which are x-compatible (broadly) between nvim and vim. Seems it would be foolhardy to just re-write all that in lua, "just because".
This is all correct. To quote from the official description of vim9script:
Vim9 script and legacy Vim script can be mixed. There is no requirement to
rewrite old scripts, they keep working as before. You may want to use a few
:def functions for code that needs to be fast.
My read of that thread was that the initial patch had a lot of issues. The design had some flaws. The patch lacked documentation. It was like they didn't read the contributing guide. Lots of bystanders threw a bunch of noise into an otherwise normal dev process. Bram and others had reservations. Bram made good faith efforts to help them evolve the patch through iterative feedback. There was an early hint of incompatible development styles (emphasis mine):
You are correct in that we added a timer to the main loop. Looking over the code once again, I think we should have altered the calls to select/poll instead, but lets discuss the practical effect of this patch *since we can work out the details some time later.*
The vim dev process does tend to be slower than a lot of other open source projects. That is frustrating for some people but the model has proved remarkably sustainable. After about 1.5 months one of the authors said:
Bram,
I happy to see there is still some hope for this patch getting merged.
Then shortly afterward the other author gave Bram an ultimatum:
Thanks for taking time to look at our patch and give feedback. Besides pausing/resuming timers, are there any other blockers for merging this patch? Matt and I really want to get it merged, but there's been a recurring pattern where we address one thing only to have another brought up.
If this is the last thing, we'll gladly add it. If it's not the last thing, please give us a complete list of blockers. Then we can determine if we want to continue addressing your issues or just maintain our own fork of Vim.
Considering where the patch started, iterative feedback seems appropriate.
Bram replied (in part):
It's better to postpone including this patch until we settle down on how it works. I have had bad experiences with including a feature before it's fully working or insufficiently tested.
The patch authors never replied. They may develop under aliases but I've never seen either of their handles in the neovim commit history.
As someone who has engaged in the vim dev process and experienced each of the things the authors of this patch experienced, my conclusion is that they came in with fairly unreasonable expectations. They seemed to have financial interests pressuring them to cap the investment they were willing to make in the process. It's worth noting that a few years later Bram came back to the notes he made from that thread and solicited feedback (https://groups.google.com/g/vim_dev/c/M1mJ1qHHr40/m/Hd7UHMe3...) re: how timers would be used. Without the noise and suggestions to merge-now-fix-later the process went quite smoothly and the landed on a reasonable implementation that AFAICT would have solved the original need. Far from the "apathetic" epithet spawned by that 2013 thread.
I caution anyone reading this to not take this summary at face value. If you're interested, you should read the linked threads for yourself. I'd say you can leave out that someone followed up on some technical detail three years later, but you be the judge.
FWIW, my takeaway was the exact opposite. How the original async authors were treated was a disgrace. It showed, to me, that there were deep problems with the vim dev community. Forking off neovim was the best thing that could happen. I'm so glad someone had the energy to do so.
That said, I'm super grateful for Brams work on vim. It was my tool of choice for many years.
He had a separate interest in async but never actually asked for anything to be merged. You'll notice that it is advertised by Thiago as a proof of concept. One of the authors of the previous patch showed up to give a fairly inaccurate summarize of the previous thread, seemingly attempting to dissuade Thiago from continuing. The characterization of Thiago trying to get something added and being stymied seems to have come from the author of that original thread in a comment here:
In Thiago's words, the inspiration for forking seems to have come from the opportunities that were cataloged by Marc Weber. About two weeks after forking he did add the message_T changes to neovim. To say that his goal with that patch was simply to get async support into vim though is to disagree with Thiago's own words on the thread. He was upfront that he wanted to refactor the vim architecture around a different paradigm that he describes as a message loop.
Thanks for this. I had the same read when I read the original thread. The authors were lazy and kind of petty in their responses to Bram. Put me off the neovim project because it seemed the authors didn't care about design.
Weird, so people who give justification for neovim and use that thread are wrong. Thanks.
Speaking of message-loop design. This is a typical design in the vast majority of GUI software where the center of the program is a message loop. I never realized the original vim didn't have that kind of design. What is it's design?
What FF mobile fiasco are you speaking of? I am using FF mobile happily and have been for years. I haven't noticed any issues with it. Was there a business level fiasco or something?
One objective fiasco is the inability of FF on Android to keep multiple tabs in memory. Older versions were capable of it without issue, ever since the tab unloading feature, Firefox has been reloading tabs at the slightest pretense.
Switch apps? Tabs get reloaded when you're back.
Lock & unlock phone with Firefox in focus? Tabs get reloaded
Switch tabs in Firefox? Tabs get reloaded...
I wish I was just ranting, but all of the above happens with a single active tab loaded...
That is interesting to me because that isn't my experience. I just tried the lock screen for example and I couldn't get any of tabs to reload, foreground or not. I'm on Android 10 running on a Moto G7. Maybe it's affected by vendor settings?
Quite a few devices experience this though. For the record, I use an S9, and used to have 50+ tabs with no issues on older versions of Firefox - now I cannot have one tab remain open without a reload if I lock my phone with Firefox focused and turn unlock it a minute later. And that's with Firefox explicitly exempt from each and every kind of battery/memory etc. "optimization" by Android...
Doesn't happen for me. OnePlus 8 with Oxygen OS 11.
The one thing I really miss in FF mobile is the opposite.. Pull to refresh or another gesture that accomplishes that. The current two tap option is too slow.
This glosses over the outright fraud within the banking industry that was at the heart of the S&L crisis. Without the fraud there would have been enough assets and financial incentive to consolidate instead of liquidations. The Fed policies only had the effect of forcing the industry to account for the rot within.
reply