No one is making you write web apps, websites are still first class citizens for web browsers.
HTML lacks numerous features which a first-class document-specification language should have, including grid layouts (only very recently possible), footnotes and sidenotes, and formulae.
The promise of LaTeX is that documents could be defined strictly in semantic terms, though my belief is that this would last for approximately 37.229 minutes after such a proposal actually hit the Web.
The underlying failure of HTML is that it is runtime compiled, not precompiled. This makes things far easier on authors and publishers, and far worse for readers. In the early days, the former mattered in order to incentivise content. Last I checked, incentivising content is no longer the Web's principle problem.
I've also been leaning toward LaTeX as a document speification language for hypertext systems, though I don't believe that alone is sufficient to fix the Web's ills.
HTML has no such requirements. There's absolutely nothing stopping you from posting that in the first place. Throw something at a browser, and it will try its damndest to ingest it --- that's the "runtime compiled" element of the Web.
(It's not a perfect analogy to software compilation, though it can get surprisingly close.)
Essentially: the Web lacks any editor role. That's long been touted as a benefit. At scale, however, and over time ... it becomes problematic.
Moreover, the commercial Web has a selection process and corresponding evolutionary path which has come to be seen as less than optimal for those seeking high-value, high-relevance content. It is in fact hostile to such content, on multiple bases.
Again, LaTeX alone won't fix these problems. It addresses a few issues of structure. The concept of a post-authoring compliation state (ironically itself somewhat present in many web content-management systems, but not oriented around the document or content itself for the most part, but rather branding, advertising, and surveillance instrumenting) is also somewhat attractive but ... problematic. A discovery-mechanism scoring penalty might help (and Google's certainly applied that in other areas).
That aspect has absolutely nothing to do with the technical format of a document.
That said, and despite some quite strong semantic elements to HTML (and HTML5 especially), and the semantic/presentation separation of HTML/CSS, what we're getting, what seems to be encouraged by, and what the adtech-profiting browser vendor and driver of Web browser development seem to be encouraging, is not in fact well-structured, meaningful, high-value, high-relevance documents.
You're absolutely correct that the core of the problem isn't the technical format. But the technical format's become infected by that core problem.
"Whilst that may still pass poorly-structured documents and result in poorly-formed output" - this by the way happens much more often with LaTeX compared to html in my experience.
You seem to be unfamiliar with this aspect of the system?
- The compilation means that there's at least a check for syntactic validity before any old crap is published.
- JS-based HTML can be fully dynamic to the extent that there's no sense of an underlying document at all. There are times when this is useful. That is an exceedingly small minority of the cases in which it is used. The fact that it's often preferable to rerender an HTML document as PDF, simply for readability, let alone archival, should speak volumes.
There is lua-based LaTeX and js-based pdf. Just use html without JS.
"The fact that it's often preferable to rerender an HTML document as PDF, simply for readability, let alone archival, should speak volumes."
The fact that it's always preferable to export a LaTeX document as pdf...
And well, given the amount of people that use overleaf I would say that a lot of people (although writers instead of readers) consume LaTeX.
(Btw, you can compile html too, try printing it as ps/pdf document)
I am not making assumptions about what you do or do not know. I'm telling you how you're being perceived. You have the power to alter that perception. You've failed to use it.
Sure, but I don't see what this has to do with anything.
As for your perception, I don't care :) Keep it to yourself next time please. You too are being perceived in a certain way as well but telling you how would likely be against this site's rules.
TeX itself is a set of typesetting primitives. LaTeX is a set of structurally-semantic, document-oriented macros built on TeX.
Some of those reasons are technical, though as noted elsewhere in this subthread, economic and other factors seem more dominant, and I severely doubt that LaTeX on its own will address the broader scope of issues raised in TFA.
LaTeX is almost never semantic. People are encountered to think only about the document presentation (mostly due to LaTeX's own failures).
As for footnotes being "first class". It's just a macro, nothing first-class about that when compared to HTML's solution.
https://www.pdfa.org/resource/iso-32000-pdf
The LaTeX project announced an a16y project in January of this year. A tool is now available, though success varies.
https://www.latex-project.org/publications/indexbytopic/pdf/
Of footnotes: LaTeX has the macro, it's common across multiple document types. HTML does not.
Various tools and packages that attempted to generate accessible pdfs from LaTeX have existed for aeons, all of they had a common characteristic: they sucked. I am convinced that by this point everyone who cares about accessibility has moved to other formats (like HTML).
"HTML does not"
<aside> is "first class".
I mean, that already failed for LaTeX. To me it's kind of an unwieldy pile of wierd imperative imports. I did write my thesis in it, but for the most part it was "smash these imports together, pray for the best, if it doesn't work, try a different collection of imports, don't bother trying to fix your imports, settle for "least bad" -- which, of course, was better than MS word". I used to do my resumes too, with the same spray and pray feel. Now I just write a markdown file, and anyone that cares that the resume is poorly formatted I probably don't care to work for (many places sanitize resumes to a single format anyways, i suppose for non-discrimination purposes).
Honestly, even though I myself can't use CSS effectively, what little bit I can use feels like CSS is converging to that declarative-layout-that-is-separate-from-document-contents philosophy that LaTeX tried to do, with the major distinguishing point that LaTeX had a huge "start with sane defaults" selling point, and CSS most definitely does not start with sane defaults.
I guess the point I was trying to make is that if you just type only non-layout LaTeX it looks reasonably good, yeah, it does format it with super-wide margins (shrug), but if you do that with html you get mouth spiders.
https://codepen.io/dredmorbius/full/KpMqqB
There are a few bits of that I'd fiddle with, but the idea of defining margins and avoiding text that runs flush to gutters, as well as defining most of the whitespace in rem & em units rather than pixels or points, is a big part of it.
Another alternative would be a stock set of document types for which users could choose from predefined styles. The document would specify the doctype, the user the styling. That could include various branding or simiilar components, but they'd be reasonably minimal.
The ever-encroaching headers, footers, sidebars, floating interstitials, etc., of the modern web really need to go DIAF.
You need to try TeXmacs (which, despite its name, is not based on TeX ;-) ). www.texmacs.org
If layouting (an computationally expensive step) is done at "run-time" what would precompiled even mean?
(Still a bit silly though since the author does mention latex as an alternative too).
UBI is a non-answer to this, implementing it won't allow everyone to quit their jobs and make art instead. Ideally it's meant to be a social safety net, not a way to sponge off of "billionaires paying their taxes" and no ideal survives contact with implementation. We could hope for a marginal improvement on welfare at best (and that would be a good thing, even small improvements count).
The current web can and should be improved upon. Web browsers are in a "worst (that works) is best" situation after having roughly solved the software distribution problem. We need to take these lessons and move on to something better. Seamless execution of software in a sandboxed environment. That's how you solve the current state of the web, build something that is better suited to what people are trying to shoehorn into browsers and they will move all of their bloated apps off of the web leaving only pristine documents behind.
TBF I don't think the author meant to imply that we should "allow everyone to quit their jobs and make art instead". If we agree that the article is largely lamenting the extortive/exploitative nature of modern society cum digital medium than I'd wager what's in mind is UBI as counter-balance to the increasingly extortive/exploitative labor relations many people are living with. We're sorta getting a taste of this with the effect of exceptional unemployment benefits but that's temporary.
But HTML is good enough for people to keep using. And LaTeX is barely good enough after four decades for people to keep using.
<rant>
Is it not instead the case that today's hipster developers simply want to ignore that platforms exist beside their fancy McBooks? Is it not the case that today's developers prefer a bizarre interpreted untyped language simply because that's what they learned for building websites and they don't want to put up the effort to understand what a type system is? Is it not true that the same developers pull in dependencies reflexivly and never consider long-term maintenance, let alone such weird concepts like supply chain security? And finally did not some hip leaders invent the microservice architecture to cater to these idiots? Because it's nowadays simpler to have a huge, inefficient, pile of services that hides all complexity in the communication between these services than to have one well-designed, efficient system?
</rant>
Sorry for the rant, but sometimes I feel like the industry is actually regressing because many developers are simply lazy morons that hide behind buzzwords.
* is only for those two (and sometimes only one of those) platforms
* the preferred "version" on those platforms in an app, rather than web-based
"Qt for Application Development is dual-licensed under commercial and open source licenses. The commercial Qt license gives you the full rights to create and distribute software on your own terms without any open source license obligations." https://www.qt.io/licensing/
But since you're such a boi genius, make something that can match and get ahead of it and i'm sure everyone will jump on your boat. Until then, your opinion will remain objectively useless.
I say we are the arch phase of the web, we understand the arch and it has served us well and it does save a little bit on materials. What we want to do is create bigger and better engineered structures like the pyramids.
It's been a long time since I used a cross-platform framework so maybe things have gotten better but what used to happen was that I'd run across something in them that didn't work right and then I'd have to do one of:
1. Just not use that in my application,
2. Implement that thing outside the framework which required me to (1) know how to do that thing natively and (2) figure out how to make my implementation work with the rest of the app that was using the framework, or
3. Figure out how to fix the bug in the framework which required me to (1) dive into the framework's internals and (2) probably required me to know how to do the thing natively.
Framework internals are complicated. This complexity is expected--when you are writing a native application you only need the complexity that is inherent in doing whatever it is that application is doing whereas a framework has to be flexible and general enough to serve the needs of a wide variety of applications.
If the framework is going to make me dive into its internals to get it to work there is a good chance that the total effort of making my app run on two or three platforms via the framework will be more than writing separate native apps for those platforms.
Any replacement technology/protocol which does the same "write once, use everywhere" thing and manages to perform better would still need to achieve wide adoption. And I feel like users would still want that to be able to play seamlessly with everything in their lives that they have online.
They've worked pretty closely with the folks who designed java bytecode, to try to learn from their institutional knowledge (repeating what they felt they did well, but learning from their perceived mistakes).
It hopefully will end up really nice, because it could provide us with a machine-agnostic IR that will work everywhere, have high performance, and if it becomes popular on the web, I could it leaking into the desktop space and starting to become a standard there as well.
The web is great because people kept pushing its limits and weren't arbitrarily held back by bureaucrats. Even though Apple and Google have spent untold billions to push the "there's an app for that" line of thinking, the web has survived.
1. Youtube is just a generic video hoster, of which many came before, during, and will come after. As for the whole "pretend Youtube is a thing" thing, I can't remember one actual good video from a "content creator" ever. It's all circle jerking and quick videos on a topic based on least effort.
2. <video> tag has never had a single good implementation. They are all bugged and 100x slower/clunkier than using the built in menu on a CRT TV from the early 90s.
3. Yes, the web would be better if it was just static content. Even without <video> tag. The primary use of a <video> tag is clickbait (actually, almost nobody uses a <video> tag because they don't want to host video, and instead use a youtube embed, so <video> is not even used in practice). For anything else, like movies, porn, etc, it's 1000x more convenient to just download the video and watch it offline in a real video player like MPV. Web browsers still cannot even turn off that stupid "you are now in full screen" banner at the top of the screen, which fortifies my point that <video> is not good for what it is intended for: short one-off clips scattered throughout web pages.
4. The whole idea that it's hard to have a video tag is a product of licesnsing braindamage and the clusterfuck of video encoding standards.
5. The web is not great, and I try to avoid it as much as possible. Using a god damn terminal emulator (the most braindamaged obsolete shit in the world) is 1000x more pleasant than using a web browser.