Thoughts on HTMX?

I've been using HTMX on a small imageboard app. Go backend with HTMX on the frontend. I've really enjoyed it. I work with a Python + React stack at work so this has been very refreshing to get my hands dirty with. I never liked working with React, but learned it because its what needed to happen. I look at the state of web development and frontend development and I cringe. What happened to the web?

its nice, because js syntax doesnt make too much sense to me coming from other languages, and instead of looking up the correct way of doing something in js, ill just let htmx do it for me. all i need is AJAX and that works for me

>>37797 >What happened to the web? Tech hype lead people to use it for things it wasn't designed for or good at, and it gradually mutated into a giant hack-y mess in order to accomedate. It's an issue that goes all the way back to the 90s (remember Java applets?), but we were all blinded to it because playing a game from your web browser was so hecking cool.

>>37816 >It's an issue that goes all the way back to the 90s (remember Java applets?) Java applets were at least defendable in concept and in context. The Hyperlinked Web of Hyperlinked Documents had swarmed the whole earth, and was designed so poorly both in concept and in early realization that it looked like the ARPANET had just gotten both of its legs amputated right as its users woke up to the possibility that it could really go places for them. Sys-administration expert Clifford Stoll got published in Newsweek https://www.newsweek.com/clifford-stoll-why-web-wont-be-nirvana-185306 because he said what everyone with experience in computers above the micros was thinking, that the tech "stack" of doing literally everything through at best generating static messages of a physicist's idea of a program semantics was going to crash and burn horribly once anyone tried to leave the bottom rung of system functionality. There weren't even great ways to integrate them into dry old traditional business data operation-ing (and they certainly weren't going to be the norm in an enviornment where any warm body could get a seat at the dev table https://queue.acm.org/detail.cfm?id=2349257 ), and there was real terror that if a stopgap wasn't adopted soon the vision of an "intergalactic" unified communication protocol for computers would literally be torn back up (this had all but happened before; the internet was very disregarded almost right up until it became famous in all kinds of places you'd think would hold on to the dream more. For example, worm-famous Robert Morris flunked out of a semester of harvard because he spent too much time taking it upon himself to repair the massive bit rot in Harvard's internet infrastructure. Everyone else was so disinterested in anything beyond a telephone connection they both let things get to that state and didn't care a bit about some random grad student fiddling about with it alone and outside of any research for the CS department. So when Sun came along and said they'd all but give out a demonstrator of the decentralized program interface the tech world reasonably decided to bite their tongues for the time being and grab lifelines like that. Was it good? Of course not. Was it at least good enough? I think there's even room for debate there, but frankly I don't think it's reasonable to fault them for coming up with any solution at all in the middle of the largest meta-production-crisis the world had seen up until then. Good programs take much more time than they had, and good programming systems take much more time than literally ten days. But that was a long time ago. Where we are today? Yeah it's absolutely undefendable and getting worse as the years roll on. Turns out trying to fix cruft by piling more cruft on top of it always means you'll take more stops backwards than forwards on net.

>>37797 >What happened to the web? Websites are developed with two metrics in mind: firstly, it needs to be flashy enough to appeal to management and make your company look technological and modern. Second it needs to be easy to develop, or at least as low effort as possible. Hence the two stake holders are executives and programmers. The user is conspicuously absent and so websites do not cater to the experience of a user. A website is primarily marketing material and only secondarily a user interface. The trend towards soykaf websites is really just another manifestation of the prevailing trend in modern business – produce more stuff at a lower quality for cheaper. Market forces, especially those of technology, demand that this happen. User acquisition is always preferable to user retention. The current vast ecosystem of libraries has sprung up to service the needs of developers to produce something better than everyone else while also putting in less effort than everyone else (a fundamentally fallacious objective).

>>37829 >Second it needs to be easy to develop, or at least as low effort as possible. yeah... this is not what the modern web is. Modern web sites are expensive to develop, expensive to maintain, and are over engineered nightmares of javascript and transpiles typescript. I don't think your point makes much sense.

>>37824 my reply won't be of much use but holly molly i missed reading top quality comments like this one, we need more people like this in Lainchan. Thanks for sharing your thoughts

>>37832 I use "develop" here in contrast to "maintain". The website needs to be developed quickly (and ideally cheaply), hence shortcuts are taken. These then spiral into increased cost of maintenance. >I don't think your point makes much sense. Well concretely, consider the case of Electron. Electron itself is the easiest and fastest way to achieve a cross-platform application library (reuse Chrome), then developers using electron can just reuse whatever code they had for their websites. Electron results from each person in the process finding the quickest and lowest effort way to implement the functionality they wanted. The result is that the user gets shafted. >Modern web sites are expensive to develop Relative to what? I don't think there's anything that even comes close in terms of cost.

>>37797 I don't know much about HTMX but a cursory search suggests to me it's yet another way to abstract away "complexity". Given the state of the JS "ecosystem" I don't put much faith in it. If I really need some dynamic functionality on the client side I prefer writing whatever bits of JS I need without any libraries, even though I dislike JS in general. Otherwise I try to stuff whatever functionality in the backend, Flask is especially nice for small apps. I don't develop websites as a profession though, so that certainly influences my opinion. >>37829 >Second it needs to be easy to develop, or at least as low effort as possible I believe the actual intention is opposite of that. IIRC the whole JS webshit started with the V8 engine in Chromium. This is of course an advantage if websites rely heavily on JS, but otherwise wouldn't matter much. I believe Google forced JS everywhere so other competing browsers would get forced out of the market as they can't compete on JS performance. The fact that Google constantly updates their own websites (especially YouTube) to have just barely acceptable performance on Chromium and simply soykaf the bed on Firefox further reinforces my belief.

>>37850 >I believe Google forced JS everywhere so other competing browsers would get forced out of the market as they can't compete on JS performance JS is everywhere because you need it to write websites. It isn't some mad conspiracy to make everyone use a certain web browser. How would google even achieve this, practically? They can't point a gun at your head and make you write your site in JS. There just isn't an alternative.

>>37852 >JS is everywhere because you need it to write websites. You don't "need" it. Plain, small static pages with forms go a very long way. >How would google even achieve this, practically? Marketing and hype

fuarrrk a website. Send source code over email and make socket connections.

>>37852 Modern HTML5+CSS is enough to make a beautiful website, these days. https://www.htmhell.dev/adventcalendar/2023/2/ Of course, for soy latte-drinking SPA-worshipping SF pathetic excuses of men busy keeping up with the latest framework du jour, things work differently.

>>37850 I seriously doubt Google conspired to monopolize the web by putting JS everywhere, although I'm sure they started leaning into it once they realized they were doing so incidentally. JS's ubiquity in the modern web goes back to the reason it was invented to begin with: HTML and CSS used to be a lot more limited than they are now. Netscape created JS so people could have dropdown menus in their web pages, and people started plastering it everywhere because it was the only way you could do that sort of thing. Fast forward to today, and that's just kind of the way people make web pages now. The received wisdom is that you need JS to make a web page that looks and works good, and received wisdom is powerful among retards. >>37855 Big man alert! We have an alpha here! I bet all the babes in town know of your amazing four inch dick!

>>37856 Don't be such a tsun. Ask for his number already!

>>37856 >>37855 >you don't need JS Are you guys living on a different planet or something? As soon as you do anything more dynamic than "submit search query to server" you need some JS. Even within forms, you need JS for validation of some things. Do you think the only use of JS is aesthetic? It clearly isn't. JS is a functional necessity in most cases, so tools developed around JS, which it then made sense to reuse for more static purposes. The site you are posting this on wouldn't work without a bunch of JS. Most sites which are developed and maintained (i.e. stuff we're talking about) do a lot more than just serve static content. And even if you are serving relatively static content, it can make sense to do it with JS so that some parts of the page can be loaded more efficiently. Yes, you can make a blog using plain HTML, but that's literally just serving documents to people. Most websites are more than just documents. The fact that the web is designed around documents but used for applications is half the reason it is like kicking dead whales down the beach to begin with. Could less JS be used? Absolutely! Would it be beneficial? In some cases, yes. Is it only used because people think it looks pretty? No.

>>37861 > The site you are posting this on wouldn't work without a bunch of JS. False. It works fine with JS completely turned off, just a few minor features don't work. JS is fine if it's just for a little dynamic content on top of existing static content. But a lot of pages now won't load *anything* unless you enable javascript, and they have convoluted systems that take *multiple requests* just to unpack the obfuscated and minified javascript from some random CDN that ultimately loads in some static content. There is no way in hell that's more efficient, unless the goal is to force users to look at ads.

>>37862 >It works fine with JS completely turned off, just a few minor features don't work. The first half of this sentence contradicts the second. Being just a little broken is still being broken. That's not an acceptable state in which to ship a piece of software. >There is no way in hell that's more efficient Depends how you look at efficiency. As I've said before, most devs are concerned with ease of implementation over all else, which is what insensitivity this bad behaviour. My issue here is that you are appealing to the pathological case of JS usage and trying to say that means it can be avoided entirely. >JS is fine if it's just for a little dynamic content on top of existing static content This sentence is neat, but absolutely meaningless and it entirely depends on what your website is actually intended to do. Suppose you have the very basic case where you want a dashboard to show a couple of panels with some up-to-date information about something, it makes total sense to do most of the page in JS because you need to refresh it frequently. In general, it makes sense to defer loaded content to rendering with JS instead of bundling it statically with HTML because the result is generally more re-usable code and a simpler system to work with overall. Most people aren't gonna notice the extra 100ms ping. >But a lot of pages now won't load *anything* unless you enable javascript Yeah. Most applications don't work when you randomly disable one of their dependencies.

>>37863 >Being just a little broken is still being broken. That's not an acceptable state in which to ship a piece of software. You said the website "wouldn't work" without JS. It works just fine, you can do all the things the website is built for, such as reading, writing, and submitting posts, it looks the same, and the user interface is not substantially changed. A user who wants to forego the javascript components, such as myself, will not find the website rendered unusable at all. I can't say the same about a great many other websites. >Depends how you look at efficiency. No, it doesn't. Ease of implementation has nothing to do with efficiency of the actual code that runs, in terms of time, network bandwidth, CPU cycles, memory usage, dollars cost, etc. Ease of implementation is a *completely different* metric to any form of efficiency and must be treated as such in any engineering context. There are cases where dynamic loading of static content can reduce server load (apparently this was the case with c2wiki) but, for instance, it never makes sense to serve static CSS templates with javascript. This is a real practice that I have seen on many, many websites. >it makes total sense to do most of the page in JS because you need to refresh it frequently I agree, this is a perfect example of something where "little dynamic content on top of existing static content" makes the most sense: you have static HTML layout, some static images, and static CSS that always needs to be served, and you run some javascript to modify the parts of the page that need to be refreshed frequently. >Most people aren't gonna notice the extra 100ms ping. If you have a bad internet connection that can easily spike to 500 ms, and also, not everyone has an unlimited internet connection, and poorly optimized web pages can lead to significant power draw, lowering the battery life of mobile devices. Inefficient design patterns materially harm users, just so incrementally that they might not even notice it. >Yeah. Most applications don't work when you randomly disable one of their dependencies. If I turn off umatrix and allow any javascript to load, some pages (especially news and recipe sites) take almost 5s and hundreds of kilobytes of bandwidth to fully load, when the content of interest, the only reason anyone would click on the link and have interest in viewing the page, is just text. That's simply unacceptable; things like overall page layout, CSS styles, and images that don't change frequently are *not* software, they are *static data*, and it makes no sense to load it in so inefficiently.

>>37864 >Ease of implementation has nothing to do with efficiency I would say efficiency is the degree to which something makes use of the resources available. Making efficient use of the programmers time is a fair metric. Then it is also more efficient in terms of hardware performance, which is nice. >It works just fine I can see we have different definitions of "works". When I am programming something, I would consider it to be broken if any part of it is broken. Perhaps this is not the case for you. >this is a perfect example of something where "little dynamic content on top of existing static content" The way you define this is flawed. In the case I presented, all of the content (stuff you actually care about) is dynamic. The only static features would be the stuff surrounding the content. Without the JS, the website would have no useful content. >If you have a bad internet connection that can easily spike to 500 ms Not really a problem still. The issue here is not so much the absolute number, but the relative difference from loading normally. >not everyone has an unlimited internet connection So it's good that you aren't sending a bunch of markdown over the wire with your data. >poorly optimized web pages can lead to significant power draw How significant? I think just running a web browser will do more than loading the content in it. >some pages (especially news and recipe sites) take almost 5s and hundreds of kilobytes of bandwidth to fully load Fox and CNN seem fine. They even work about the same with JS disabled. The only example I can think of here is YouTube, but the requirements of that service are such that I suspect it wouldn't be practical to do everything statically. I don't think we actually disagree on this. My point originally was that many websites require JS to achieve many of their features. I think we agree this is vaguely true. It was also that most websites which don't need JS, also don't use very much of it. That is perhaps more contentions, but as far as I've seen, the egregious examples you list are more outliers than common practice. This is all in contrast to the absurd idea that web developers can just forgo JS entirely, or that they use it because they've been brainwashed into think it makes websites look better.

>>37865 >or that they use it because they've been brainwashed into think it makes websites look better. Quite the contrary

>>37865 >I would say efficiency is the degree to which something makes use of the resources available. Efficiency *of a program* matters to the person running the program (the user and the system administrator, in this case). Efficiency *of the programming* matters to the person writing the program. The metrics are different because the reasons why you care about them are different. I can write you hot garbage >So it's good that you aren't sending a bunch of markdown over the wire with your data. The markdown needs to be sent one way or another. Unless you're doing something horrible like pic related, compressed HTML will be smaller on the wire than the equivalent javascript to render that HTML. >When I am programming something, I would consider it to be broken if any part of it is broken. Perhaps this is not the case for you. I would say something is broken iff it is broken in a way that obstructs its use. The features of lainchan that are implemented in javascript are so minor that I don't personally miss them. >I think just running a web browser will do more than loading the content in it. Viewing a page that doesn't have much actively running JS will take negligible power draw compared to actively running some JS. This is because the data structures don't need to be re-rendered all the time, only when some state changes. Anecdotally, I once noticed that a poorly optimized recipe website caused by phone's battery to drain substantially faster than normally. >In the case I presented, all of the content (stuff you actually care about) is dynamic. The layout is just as important as the content most of the time. >Fox and CNN seem fine. I guess they've added noscript support since I last tried. >the egregious examples you list are more outliers than common practice. I don't think so, but I suppose without hard data it's hard to say. >This is all in contrast to the absurd idea that web developers can just forgo JS entirely, or that they use it because they've been brainwashed into think it makes websites look better. I think mainly they use excessive javascript and poorly optimized HTML (they go hand in hand) because they have no incentive not to make bloated websites. Same reason why there's so much single-use plastic littering the streets.

>>37867 >I would say something is broken iff it is broken in a way that obstructs its use. The features of lainchan that are implemented in javascript are so minor that I don't personally miss them. So it obstructs your use, but not to a degree you are bothered by. Therefore it is broken but you don't mind. I personally don't see the benefit in disabling JS. It just seems like pointless masochism, especially when you'll likely be forced to re-enable it on all the websites that are actually harvesting your data. >they have no incentive not to make bloated websites It's not that they have no incentive (producing a better performing website is an incentive because it improves UX), just that other incentives are greater. Primarily speed of development.

>>37878 >especially when you'll likely be forced to re-enable it on all the websites that are actually harvesting your data. Most websites still function reasonably well with the majority of their JS disabled. Once you find the sweet spot you can decrease load times drastically.

>>37881 How much time does "finding the sweet spot" take relative to the time you save on websites loading?

>>37883 It depends a lot on the website. Very rarely more than a minute total. Considering I value my privacy and blocking unneeded javascript is by far the most effective way to block tracking attempts, this is worth it to me.

https://htmx.org/essays/#memes This and only this has made me decide that I don't want to touch HTMX with a fifty foot pole. This soykaf is fuarrrking embarrassing. HTMX could be the greatest thing in the history of webdev, but if the people making it are going to treat it like a joke then so am I.

>>37824 Any thoughts on WebAssembly?

I don't like how HTMX proponents advertise it as a "write zero JS" solution, but there are some good ideas behind it. I would read the source code (it's mostly a single file, 4k SLOC by now https://github.com/bigskysoftware/htmx/blob/master/src/htmx.js) and learn how it works. I extracted and rewrote parts of it for a project and my solution was less than 100 lines of JS for a fairly simple interactive UI. Not nearly as flexible as HTMX, but much nicer to work with inside a single project.

>>37835 Even though I misspelled "Hypertext" and failed to close that paren? Many thanks for the compliment, lainon. If you want me around more I'll be sure to make more time for effortposting. Speaking of, I'd like to repeat that, in the wider context of development today, if you're not working in a completely bespoke industry handling something like petaflops of job compute or yottabytes of data, the safe bet is pretty much always on there being some half-forgotten old system built on a smarter, cleaner foundation that just didn't happen to catch on over the current trend for whatever social reason. I don't even think Alan Kay is 100% right on the proper ways to do things, but because he came out of the old tradition of technical excellence from a strong theoretic education he's light-years ahead of today even while making those key missteps. This is why he's smart enough to recognize languages like Lisp or Erlang as also acceptable to accomplish what he wants, because he knows enough to see through the surface features to their CS underpinnings. Compare to the modern JS shop that doesn't understand why they'd want a reflective metaobject protocol or Kay's proposed online-objects architecture when five frameworks, two ad-hoc typecheckers, and three database models spread across an army of undergrads accomplishes the trivial half of the same thing. The computer revolution *still* hasn't happened yet, so Kay's at 85% while we're at 15% and slipping on a good day. >>37856 I would doubt it too based just on the suspicion, because you are correct about old HTML and CSS, but the truth is stranger than fiction sometimes. Something like this does actually seem to have been under consideration for a few years. I don't know where it falls on the scale between back pocket contingency and actually aimed at, though: http://lambda-the-ultimate.org/node/4355 >>38084 I actually don't know as much about it as I wish I did (web stuff isn't actually my primary focus), but I'm hoping it turns out to be neutral-to-positive. On the one hand it's not the way implementing Kay's philosophy of "Nothing should go lower than a computer" *should* be done, but on the other hand it's in the family of the first real fundamental thrusts at the problem to gain mainstream attention in quite a while. On the one hand the proposals like this https://www.destroyallsoftware.com/talks/the-birth-and-death-of-javascript that got people behind today's webassembly are at best reinventions of the wheel and at worst a mildly hacky way to put another slab on the pile, but on the other hand they remind people that fundamental engineering can get a lot more done than the limited context they're used to working in. In the long term I hope all of these assembly-likes either die out or are replaced by truer bytecode-likes designed for flexibility instead of uniformity to the other conventions they're trying to replicate, but in the short term I hope they stick around at least enough to prod people back into curiosity at what a future that's not entirely more of convention could look like. Back to the ultimate topic it's in most ways better than java applets (and still alive) after all, so it's probably better to not look the gift horse in the mouth until we've got a true non-incremental improvement ready to replace it with. Maybe one of the remaining 10xers at google will do it once someone points out that, I dunno, making youtube videos turing-complete would be way more engaging than making them vertical and impossible to quiet without muting on desktop, but I'm not holding my breath. We've probably got to bootstrap it ourselves.

>>38084 >WebAssembly I feel that they want to turn more programs into browser apps (and idk if that's a good think?). Also, won't WASM kill Ad blocker extensions (but not ad blocking via /etc/hosts)?

>>38127 > Also, won't WASM kill Ad blocker extensions (but not ad blocking via /etc/hosts)? Only if the browsers are intentionally engineered to make ad blockers hard to implement *looks at chrome*

>>38130 oh you mean the one browser with 95% market share? yeah that will probably never happen

>>37824 clifford was so wrong in that article .. It didn't age well xD

>>38132 I don't really see how it's wrong besides the shopping part. Online shopping has become huge. But besides that? Most of internet content isn't worth reading and is lackluster compared to just buying a book about a topic you are interested about. There is next to no curation. Usually there are just attempts to get you addicted to the screen which we call curation. For politics, computer are kinda useless unless once again spreading short content videos on youtube and punishing people from wrongthink. Education is kinda the same as it has been before. Maybe even worse as most educational software is downright terrible, and not wording your answer in a format the software understands makes it count as wrong. And no, I don't consider knowing thousands of useless facts from wikipedia to be anywhere close to education. As for human contact, yeah. It ruined it too. Most social media sites are close to self enforced spying network. I have to use linkedin and I realized that not so long ago, no one really pretended daily to be interested into such useless slop as you see on there. On the whole, I would say the internet has a high chance to be seen as a net negative.

>>38133 >to be seen as a net negative. By who? Historicist scum.

All markup languages are a curse. It's 2024 and as a species we still haven't developed a robust WYSIWYG document management system. Autistic infatuation with ascii/utf8 and text editors is holding back the industry.

>>38148 All WYSIWYG editors use a markup language under the hood. Unzip a DOCX and see for yourself.

>>38132 Consider that you just might not be smarter than the author of The ()oo's Egg, and then read it again, but carefully this time. I'm incredibly disheartened by dealing with today's up-and-coming kids in technology. They seem to think merely installing sophisticated software someone else wrote makes them as knowledgable as seasoned professionals with years of historical context sourced from hard won practical experience. Of course there have always been script kiddies, but I swear most of them were at least half aware they were standing on the shoulders of the old greybeards with antiquated minis in their messy offices who built the context they swim in like water. I'm still rather young in this industry but can remember being absolutely mortified of giving the impression that I didn't appreciate my technological predecessors in my punk teen online days. Just several years later and being flippant to, and maybe even proud of, not reading the jargon file seems to be the rule rather than the exception. What happened? Did growing up on facebook kill the tradition of intellectual bullying if you thought too highly of yourself and make people too soft? Is 4chan no longer sufficiently containing the tourists? Something else? I dunno, but it's making me very tired and very crotchety. (Also this word filter has only been getting more onerous as the years roll on, without much improving things. When a measure becones a goal it loses its predictive power.)

>>38155 People become less aware of the past the further it retreats into the past. I'm willing to bet that your own knowledge of computing history becomes pretty murky once you go further back than the 50s.

>>38133 >I don't really see how it's wrong besides the shopping part Let's go through it: >Try reading a book on disc I don't read physical books anymore, I have never purchased a newspaper, none of the problems he mentions are relevant anymore. >I hunt for the date of the Battle of Trafalgar typing "battle of trafalgar" into google, the date shows up in the autocomplete suggestions before even pressing enter. >he put every press release and position paper onto a bulletin board. In that affluent county, with plenty of computer companies, how many voters logged in? Fewer than 30. When I get my ballot in the mail, I look at the websites of all the candidates to see their positions, and local discussion boards to see if anyone is very upset about things they've done. I also look for additional context on ballot measures. I can't imagine how inconvenient all of this would be without the internet. >computers into schools I went to school before things were very integrated, but will take your word for it that it is like kicking dead whales down the beach because why would a school administration ever do anything good? >cyberbusiness Acknowledged and obvious win for the internet, but I'd like to add that he was clearly wrong about >the network is missing a most essential ingredient of capitalism: salespeople. Who the fuarrrk wants to talk to a salesperson when deciding what to buy? Good riddance. >Computers and networks isolate us from one another. A network chat line is a limp substitute for meeting friends over coffee He has a fair point with this one, because the internet clearly does displace friendships. I've very rarely had experiences akin to "meeting friends over coffee", more of that would be welcome. However things like group chats and video calls also let people stay in touch over distances when that would otherwise not happen; I wouldn't be as close with distant family if not for that.

>>38150 Firstly, that's probably not true. Secondly, why would it matter? This is something else that infects minds in computing, a lack of understanding regarding interfaces. If I have an interface to something, and it's properly abstracted, I needn't worry at all about what it does. The insistence that something never used directly is just as good as something used directly is a sign of a small mind. We see something similar with C language programmers insisting that everything is written in the C language; they don't care that the C language is compiled down to some machine code, since that doesn't matter to their small minds; when given an example of a language that doesn't use the C language at all, they disregarded it as unimportant.

>>38161 >Firstly, that's probably not true. Why don't you check for yourself instead of making assumptions? >Secondly, why would it matter? Have you even considered how you would represent layout and style? >If I have an interface to something, and it's properly abstracted, I needn't worry at all about what it does. There are plenty such interfaces/tools. You can convert DOCX to HTML, PDF or whatever else if wish to do so. >We see something similar with C language programmers insisting that everything is written in the C language. C is a programming language, and everything under the hood is a form of programming language. Machine code can be considered a form of serialized assembly, in a way, given how easy it is to disassemble. Your analogy is akin to claiming that all markup languages are HTML, which obviously isn't true.

>>38161 Your mischaracterization of C programmers is one such that confuses people and pits them against one another. C programmers don't demand that everything be written in C, but they do write almost everything in C. Could this be because they are C programmers? Every language's users dream of having all their tools written in that language, thus there are window managers, text editors, package managers, and everything under the sun written in very many different languages. Do C users complain about this and demand a return to C for everything? I hope we don't get an isolated example now treated as a general case. If we use the C ABI it is mostly for compatibility, though nobody is held at gunpoint to follow it. It is also because the kernel is written in C and understands it natively. One reason to want to have a whole ecosystem in C is to have a single compiler good for at least the base system. I don't appreciate having to compile rust in order to build X11, especially since it takes a whole day on my machine. I do expect to be able to bootstrap my system without having to build three or four heavy compilers. And even then, there is a wide array of languages that are almost required by just about any system beyond the basics. Any unix workstation can be expected to include at least perl and python. I haven't seen any complaints by C programmers on that front. Interestingly, most complaints come from people from other languages. Especially lisp. Emacs users do everything in emacs, lisp programmers want to have a pure lisp environment, isn't that what we were criticizing C programmers for? Most criticism of Unix and C are valid and worth paying attention to, but it doesn't warrant making empty claims about it's practitioners to sow discord.

>>38166 >C Lol just program in assembly noob

>>38166 Not him, but I find that C tends to attract the kind of person who thinks that computing begins and ends with C and its direct relatives and isn't particularly willing to look elsewhere; people who think that programming is about "the computer", and that their language of choice just so happens to sync up with "the computer" as closely as practically possible. It's the same deal as with Rust evangelists, but because Rust is newer it's still socially acceptable to make fun of the behavior. Lisp people can indeed be obnoxious, but most every Lisp programmer knows at least a few languages that aren't Lisp and work nothing like Lisp. But there's a disturbingly large number of C programmers that balk at anything without curly braces.

>>38150 And all programmer's languages use machine language under the hood. In this context, though, you're probably smart enough to recognize this makes refusing to use them a stubborn waste of productivity rather than a clever virtue in the vast majority of cases. Most surviving visual editors have indeed failed to develop beyond the initial power of their PARC ancestor with the increase in hardware power and human interface research, but this still doesn't make the flintlock blunderbuss not the obvious evolution of the bow and arrow.

>>38178 WYSIWYG editors edit the markup in stupid ways: the user removes text but the markup of the text remains as an empty entry and the longer you work on a project the more dead markup bloat you have. Its why anyone serious didn't use them. And this is not limited to web, any gui editor I've tried acted identical with creating bloat you had to manually clean up if you wanted clean code.

>>38180 That's not an inherent trait WYSIWYG editors. Stripping dead markup is a braindead easy thing to program. The solution isn't to manually delete everything like a caveman; it's to write a better fuarrrking text editor. The only real argument I could see in favor of doing everything manually in Vim is that it takes fewer resources to run. But that's been a nonissue since the early-90s. Besides that there's no excuse.

>>38150 My point is that converting a data structure to a string using a markup language is a mistake to begin with. Instead the data structure should be copied to a database that was designed to manage it on disk, including the pointer information, which is valuable, because it lets the system find the position of information quickly. Markup languages are a step backwards for CS, all the way to before pointers were invented.

>>38187 Factually they weren't doing it and i would say it does not happen cause the cost of dead weight is invisible to amateur users so there is never effort put into optimization. >But that's been a nonissue since the early-90s. Besides that there's no excuse. Software is as slow as 90s thanks to this "code as bad as hardware permits" thinking despite hardware being 100x faster. Software running like trash is just tolerated because users cant do anything about it anyway.

>>38192 >thanks to this "code as bad as hardware permits" thinking That's not my thinking. Optimization is always important, obviously. My point is that we shouldn't dumb down the design of our software for the sake of "the computer" if we don't have to. "The computer" exists to run software! We have more than enough computational resources to make a robust WYSIWYG editor that outputs markup as good as or better than what you'd get from a text editor, and have had those resources since the 90s.

>>38194 I think what you're saying makes sense from the perspective of the programmer, but when it comes to the end user in practice, it just makes a bunch of horrible software. Take slack, discord, or any of the million other chatting apps out there written in Electron. 90% of the time, it's not functionally doing anything that much different from any old IRC client written in C++, but these programs somehow manage to take up 1000x the resources of any of those programs. When you're running code on a server, then sure, knock yourself out, use whatever tools you want, but at a certain point, I think there needs to be some respect for end users when it comes to client side programs. 99% of websites don't do anything more impressive than what they did 20 years ago (think news sites, blogs, random online stores), so why should they require significantly better hardware? If our computers are 1000x better, why should our software be worse? When your a developer, its easy to think that everyone is running the latest hardware, but there are large swaths of people using 10 year old hardware or some random laptop they got from Walmart for $150. The issue isn't that our computers aren't good enough to run WYSIWYG editors or whatever fancy software you want to run, it's that they oftentimes can't despite the fact that they should have more than the computational resources to do so. If you look at the most textbook example of a WYSIWYG editor I can think of, Microsoft Word, I see no significant advances from Word 2024 or whatever when compared to Word 2007, but it some how takes up 25x the space and takes 20x as long to start up. Maybe you can point to one or two obscure features that I've never heard anyone mention, but do any of them make the program even 1x or 2x better? What justifies needing a 25x better computer to get the same experience then?

>>38249 Did you even read my post? I'm not saying "you can write worse code because modern computers can run it". That's not even remotely close to the point I was trying to make and I have no clue why that was your takeaway. The first PC I owned personally was a crummy hand-me-down from the late-90s that croaked every time it saw Flash, and eventually whenever it felt like it. I understand first-hand the importance of optimization. Your program should be able to run on as many systems as its feature-set allows for. My point was that a robust WSIWYG editor that outputs markup of equal quality to what you'd get to writing it by hand capable of running on hardware going all the way back to the 80s would be trivially easy to make, and that there's no good reason to have to write HTML like it's computer code.

>>37878 So, if a program some change, and I decide I don't like that feature and I turn it off, does that mean I'm using a broken program? My web browser is running perfectly fine, it's doing exactly what I want it to do. That isn't what the developer wants it to do, though, and you seem to be of the opinion that the developer's desires are what is important here.

>>38266 Well look, every time I've seen the output of a WYSIWYG editor, it's not nearly as elegant and efficient and something you would write yourself. If it was so trivial to make, why hasn't someone done it yet? When you see hand written HTML, you can tell because there's a sensible structure to it, all the class names are named something understand. Trying to do something with the output of a WYSIWYG editor is a nightmare unless you have access to the editor itself, kind of defeating the point. This doesn't apply to just HTML. Going back to Word, compare that to something like LaTeX or a similar program. Why would something like LaTeX exist if we didn't need to be writing code at that level? WYSIWYG editors are okay for a quick and dirty job where you don't care too much about the details, but for anything serious, you need a more fine tuned way of interacting with the computer. Even with WYSIWYG editors, you often have to think at the level of the output if you are trying to interoperate with something else or you just want the details of something to be just right, so then they just end up getting in the way at that point, putting up a shield between what you are doing and what you really want.

>>38268 I'm talking quality in terms of computer-friendliness; filesize and the like. In terms of generating markup that's readable and structured, you're right, to an extent. Although theoretically, it shouldn't be hard to make a WYSIWYG editor that gives you more control over how the output looks.

Not the same guy but >>38266 >a robust WSIWYG editor that outputs markup of equal quality to what you'd get to writing it by hand capable of running on hardware going all the way back to the 80s would be trivially easy to make, Then do make it, please. Turns out, your whole position seems to be based on pure ignorance, read on: >and that there's no good reason to have to write HTML like it's computer code I sure hope not a lot of people do write html by hand these days, I pity those poor souls. Have you tried to find out how many markup languages are out there? I can tell by your conceited claims of trivially easy tasks that you have not put much thought on what you are saying, nor have you been acquainted with the topics of programming and of typesetting. I wonder if it is not your kind that drives text-based protocols down the drain. I don't care if you are on a crusade against plain-text. It may not be the best medium available for many a complex data, but it is with most likelihood the best medium for text related tasks. I do abide by the heuristic that one should keep it simple. For if your text formatting system exports a different binary than my preferred text formatting system, what could be be the best way to communicate but through their own shared domain? How does a bold word look like in a binary setting? Perhaps a bit at the start of the text-object, is the text-object a string of ascii characters? Or rather, utf-8? it gets a lot of hate these days, it is not plaintext enough to some. Anyway I'll leave the details to you, since you have so kindly tasked yourself to write a >robust WSIWYG editor that outputs markup of equal quality to what you'd get to writing it by hand capable of running on hardware going all the way back to the 80s

>>38283 I never said text-based formats are bad. Why do you people have such awful reading comprehension? It's starting to become concerning. What I'm saying is that you don't need to generate markup manually, which I've still yet to see a convincing argument against. >Anyway I'll leave the details to you, since you have so kindly tasked yourself to write a >>robust WSIWYG editor that outputs markup of equal quality to what you'd get to writing it by hand capable of running on hardware going all the way back to the 80s I probably could, and honestly I very well might. The hard part for me would be the GUI side of things, which is something I'm not particularly experienced with or good at.

I've had the pleasure of using HTMX on a simple web interface to a sqlite database, implemented in Django because I didn't feel like hand-writing any SQL. It was genuinely pretty nice to use, and much easier to get working with vanilla Django features like Form widgets, especially compared to what you need to do to get something 'tiny' like Vue to work with the same features. Generally, I write a form that's completely static and then decide "oh, actually, I don't want to refresh the whole page since there's alot of forms on this page, or it's really long and I don't want them to scroll back down" and in that case, I load htmx.js on that page and have it swap the results in, it's usually just replacing a form's 'action' atribute with a hx-post or hx-target. You can send the whole page over the wire and only swap a part using hx-select, or you can add a simple check for the 'Hx-Request' header which is always sent with requests caused by HTMX. If it's there, then only render the part of the template you select, otherwise render the whole page. It's generally very easy to use without creating some giant monorepo polyglot project that needs to compile npm, then compile the static assets, then start the server, and then deal with asymetry in implementations between client and server. HTMX's killer feature is a consistent client-side behavior that the server can expect almost as consistently as the browser's standard behavior. All in a small .js file that's easily embedded inside of your website's static resources.

A good resource on HTMX I needed in order to get "over the hump" to understand its full potential; I did try it out here and there and had liked it a lot but the one thing I could never understand is - how to structure an application that uses HTMX? No matter what I did I stumbled on routing and page hierarchy became a nuisance. Never once did I find any explanation of how to do it. I hoped once I start on/read the https://hypermedia.systems book it would help explain this but luckily I found this post which explains exactly how to do routing with HTMX https://binaryigor.com/htmx-simpler-web-based-app-or-system.html#a-p-1-5-7-52

>>37861 I don't think anyone complains that google docs, facebook or whatever else use js. Sure, these things need it to function. Now, what's the similarity between a recipe, a news story and an university's front page? They are completely static content, and yet don't display at all or look otherwise completely completely broken without js.

>>38728 First of all, many of the pages you are talking about load just fine without JS. In fact, I've found that disabling JS on news sites sometimes allows you to bypass the limited number of free articles, so these sites function better than usual without JS. For the remaining examples, it may be that the website has additional more complicated sections which require the use of JS, and then it makes sense to reuse code from that section in the static portions of the site. It may simply prove more logical to use a feature of the browser to reuse code, than it would be duplicating code to cater to the .0001% of users who have JS disabled. But again, this is really very rare. Most static portions of websites work fine without JS, and most of them don't even look wonky. If anything, I would say it's surprising just how much of the web doesn't need JS. It being totally ubiquitous, you might expect to see it more. But instead, more and more of the stuff you might use JS for has been offloaded to unbounded HTML elements and overnumerous CSS tags. This is of great detriment to the web as it vastly increases the complexity of web-browsers. A better world would likely use more JS, not less (it should still function to a degree without it, though this is not particularly important as I can see no substantial reason to disable JS).

>>38725 Wow this book is something else. I was terribly ignorant going into this book, I'm not at 38% and while it treats the reader as a newbie at the beginning, but after introducing basic concepts and basics of HTMX like hx-getting stuff and whatnot - it QUICKLY goes into new territory. For example my first attempt at building with HTMX was - due to ignorance - littered with hx-post hx-vals aproaches to use HTMX as a substitute for an SPA. Like I would make an HTML page and in it I'd make some action that does an hx-post - BUT it does said hx-post to a JSON data API which had to respond with a partial template for that functionality as an isolated component; which anyone with any experience would quickly tell you is a bad idea. The book also goes into this here https://hypermedia.systems/a-web-1-0-application/#_html_notes_framework_soup >In order to avoid <div> soup (or Markdown soup, or Component soup), you need to be aware of the markup you’re producing and be able to change it. >Some SPA frameworks, and some web components, make this more difficult by putting layers of abstraction between the code the developer writes and the generated markup. >While these abstractions can allow developers to create richer UI or work faster, their pervasiveness means that developers can lose sight of the actual HTML (and JavaScript) being sent to clients. Without diligent testing, this leads to inaccessibility, poor SEO, and bloat. I was doing this exact same thing to my HTMX application and kept getting stuck. I was unaware of the following https://hypermedia.systems/extending-html-as-hypermedia/#_enclosing_forms >The simplest way to pass input values with a request in htmx is to enclose the element making a request within a form tag. And of course it is. If you write a server-side-rendered webapp with like jinja2/erb/haml/twig/blade you would write these forms to send data in. That's also part of the secret, it is easier to understand HTMX if you look at it from the fundamental hypermedia perspective: How do I send data in? <form> tag. Reading about hx-boost going forward, this is amazing.

>>38818 It really is something else, just finished it. For context I've started with programming a bit more than a decade ago with Perl/PHP CGI scripting behind an apache server and a bit of JavaScript and WordPress until I "specialized" into backend only roles. Except I didn't specialize, I kept my head down. Obviosuly I'm not the only one that now has a way to just solve problems with software. To talk to business and figure out applications of software in an industry then proceed to solve the problems. Can't promise much but I'll try to be present in this (and subsequent, if any) threads and answer questions about this architectural pattern hoping to assist other people in the same situation who see a way out by using said pattern. --- So back to the book, the hx-boost is one crazy way to make a server-side links&forms type of webapp faster, smoother, and "snappier" in terms of UX. Essentially you add an hx-boost=true attribute to an HTML link and when the user clicks it - instead of navigating the entire page to a new URI and suffering the FUOC (Flash of unstyled content (the original reason SPAs became a thing)) - an AJAX request is made and the current <body> tag is substituted with <body> from the AJAX response. The history is taken care of by HTMX, they seem to have put a lot of effort in making navigation work as it should without a need for hacks that JavaScript frameworks usually require. https://hypermedia.systems/htmx-in-action/#_boosted_links The same applies to forms, You have a form and put some data in the fields, submit it, and if <form> tag has hx-boost=true, the body gets updated from the response. What about redirects, though? Well redirects would "repeat" the HTTP method to the redirection target, unless the HTTP status code is HTTP 303 (See other), instructing the client to send an HTTP GET to the redirection target. If you have experience with webdev you might already see another benefit of the way hx-boost works - why limit the substition to changing the old <body> with new <body>? Right? Why not update any part of the page with any part of the page you get in the response? Well that's also an option; with the HX-Trigger HTTP header the desired DOM element can be substituted with something from the response, of course the server will handle the header as well https://hypermedia.systems/more-htmx-patterns/#_http_request_headers_in_htmx Want a CSS animation to happen on a DOM element despite said DOM element being substituted with something else? HTMX has a mechanism for element swapping & settling which help ensure that the CSS animations play out https://hypermedia.systems/hypermedia-systems/#_the_htmx_swapping_model --- Further on the book explains in detail Hyperview which in simplest terms fleshes out an HTML-like spec for native mobile (and other in the future?) applications. Slapping a webview on top of a web application might be sufficient, but a webapp and a mobile app are two different worlds entirely. What a hyperview application really is - is an existing React Native mobile codebase to which you set an "entrypoint" URI and compile. Basically a single-domain browser with native functionalities invoked by server-side HTML. Well not HTML, XML actually. But it looks almost identical, which means the server can render one of two template files based on the Content-Type header sent in. Or you can have two different URI paths like /web and /mobile which would serve the same application for either web or a native application. The React Native codebase is extensible by default so you can write custom behavior on top of common native behaviors that you get out of the box. --- This is all I have to say for now, I gotta go and try all of this out next.

can you manipulate chrome developer tools to do something using a programming language or any other medium? is so how? I am trying to write a program download all the images from a website automatically, How should I do it?

>>38896 Wrong thread so your post will probably get removed by the mods, check the catalog and post in a more relevant one next time. The answer is probably to use a web scraping framework, bs4 and requests in python is good for scraping static websites. Selenium is useful if the site is complex to access.

I could be wrong but I don't see the novelty in HTMX Isn't is just another javascript library that uses html attributes to extend component functionality (like every other bandwagon nonsense framework like react/angular/vue) ? What exactly am I missing/getting wrong? Sounds like there's leaner ways to do it with vanilla JS, I don't think we're deleting JS by using HTMX but rather still depending on it.

>>38904 htmx just forces html to use all the features of HTTP to their full potential ><a> does a GET to URI and reloads the screen ><form> does a POST to URI, reloads screen >but none of the other HTML elements provide any behavior >htmx allows behavior for other HTML elements >htmx also makes HTTP behavior seamless, instead of FOUC/full page render

>>38904 HTMX also lowers the barrier to entry for new web browser development because while scripting can remain, JavaScript will become irrelevant. All you have to do is HTTP requests, paint the HTML/CSS to the window, and allow XML/DOM access to some scripting language. Want Lua? HTMX is simple enough to implement in Lua. Any HTMX webapp now works with your browser the same way it works in a Chrome/Firefox/etc. Want Lisp? HTMX is simple enough to implement in Lisp. Any HTMX webapp now works with your browser the same way it works in a Chrome/Firefox/etc. Want Python? HTMX is simple enough to implement in Python. Any HTMX webapp now works with your browser the same way it works in a Chrome/Firefox/etc. Do you notice a pattern here?

>>37824 I've just realized that I had part of the Robert Morris story here wrong. He fell behind while trying to reconnect Harvard to the internet as an undergrad, not a grad student. This story is described here, ~15:00 https://www.youtube.com/watch?v=4WO5kJChg3w

>FOUC Don't you reuse your css accross multiple pages? And for the first page-load of a site, I fail to see how a "flash of unstyled content" is worse than a "flash of no content" >SPA I hate that soykaf. Makes it so much harder to refer people to what you want them to see.

>>37829 The perfect complement to "there is no security on the frontend" is then "there is no customer on the backend"

>>37797 web became an OS. Its our collective desire to escape from closed proprietary nonsense that camouflages itself as an OS - Windows

>>39359 at the cost of requiring at orders of magnitude more RAM and CPU power just to display text on a screen. DOM, HTML and JS need to all die and be replaced with some sort of bytecode alternative (not talking about WASM, total failure sabotaged by the corrupt W3C), starting first with a deprecation phase where DOM tabs are in a compatibility mode, but they are too big to fail and we'll instead need 32GB of RAM just to browse the web in 2030

>>39360 HTML is fine. If I was making everything from scratch, I would keep HTML mostly the way it is, (maybe making it more like XHTML). The way JS interacts with the DOM is okay too, the only thing that really stands out to me as bad is how cookies are handled in JS. Really, the start of the JS ecosystem we see today came in how limited old browsers were (Internet Explorer) and the need for something like jQuery. Modern JS is actually a pretty decent language, except for the lack of Tail Call Optimization (which is in the standard but for some reason only Safari supports it, Chrome and Firefox refuse). The big problem today is that nobody writes things in plain old vanilla JavaScript anymore, so they think that they need fancy libraries like React because they think that JS is much more limited than it really is.

>>39367 And there are a lot of things that can be done with CSS without a single line of javascript, yet some websites are unusable without downloading 10MB+ of javascript (and then they are still unusable because the browser becomes unresponsive). That's what I find most infuriating. So called "web-devs" can't even use web technologies.

>>39360 yes thats the cost of using closed platforms like windows we just need to switch to linux. Replacement to dom html and js is the linux platform heres an example twitter has bookmarks the browser that runs twitter has bookmarks and the OS that runs the browser in turn has an entire filesystem with folders and stuff built in... and twitter users have been begging their overlods to implement "bookmark folders" for ages do you see just how ridiculous that is? spotify does not need to exist as a website at all neither does youtube.

>>39369 tracking tools that intentionally break the site so you allow them to run.

>>39372 For better or for worse, the browser is the new Operating System. I saw this 15 year old kid use TinkerCAD for Arduino development. It has a whole breadboard simulator, and I was actually impressed that such a thing existed, but the experience of typing code into the little window it gives you was horrid. Sometimes it would freeze up for 5 seconds when all you were doing was changing a few letters on a line. He didn’t even know about the official Arduino IDE, let alone the millions of other programs out there like notepad++. For people like him, especially the new generation, everything is a website. The desktop OS with all its programs is basically a legacy platform at this point. It’s funny how for mobile development, the opposite is true, where everything is an app and no one uses websites.

>>39404 >for better or for worse it's for worse. There is some benefit to having a virtual machine that is basically uniform across all operating systems. In fact we had it for a long time, it was called Java, and it was good. Then for some reason everyone decided no actually we should use this scripting language intended to modify markup language and do HTTP requests.

>>39404 >>39405 I blame Windows for not having a native package manager. Loading up a web page in your browser is generally a lot safer and a lot easier than seeking out a binary that may or may not give your computer AIDS.

>>39405 m$ didnt want to become reliant on another company. thats why they pushed their own c+java frankenstein creation c#

>>39405 >>39412 >>39424 If history has taught us anything, it’s clear that there is a need for some kind of “write once run anywhere” system. First Sun tried that with Java, and once that went out of style, now we have the web. I personally don’t think that HTML + JS is even that bad of a model. It has proper sandboxing, all the code running on your computer is fully visible (just click inspect element) and easily changeable with user scripts. You can even use curl to interact with 99% of websites from a script. I consider this to be the good timeline, instead of a bunch of proprietary plug ins that have to be installed. Sure, the code is laggy, but that’s more of a symptom of libraries like React instead of the browsers themselves. That’s the thing I like about HTMX, it takes advantage of all the work taken to get us to this point instead of trying to reinvent the wheel. I’ve probably made something like HTMX for a few things I’ve written along the way, and I think it’s a good thing to see it systemized in this way.

>>38155 >Consider that you just might not be smarter than the author of The ()oo's Egg, and then read it again, but carefully this time. Side note: Cliff Stoll is retarded. His one claim to fame was discovering that *someone else* was precomputing password hashes. When his hippie wife pointed out he, also a hippie, was deliberately going out of his way to help the military industrial complex, he throws a tantrum and snaps at her. (It's in the book.) The young may be overly dismissive of elders but that doesn't mean every elder is praiseworthy, especially not Cliff "self serving" Stoll.

>>39432 JS has some brutal syntax traps and counter expectation behavior a guy coming from another language wouldn't notice. I think its excellent for writing something quick that just works but i wouldnt want it in anything critical.

>>39440 Sure, but that's nothing that a quick read through "Javascript: The Good Parts" and copious use of JS lint couldn't fix. I know that book is ancient now, but it's only like 100 pages, and it got me over whatever problems I had with the language. Besides, nothing really important is written in JS. It's mostly just silly little websites like these. All the financial systems are running on decades old COBOL with some C++ frontend. All the "enterprise" software is written in Java or something worse. Our operating systems are made in a mish mash of languages, and mobile apps are written in the appropriate language for their platform. JS is only really used for ads and websites used to kill time.

>>39448 Human problem is you forget. Anything not intuitive will become a pitfall due lack of use. Common traps should be really part of the warnings lsp / ide's give akin to " this does X do you really want that?"