This is not true in any sense: a backend process that performs no I/O and leaves no observable output has no user value. There needs to be an interface between the user and the application.
We can debate how rich that interface needs to be, but there is most certainly value in the interface itself. And you can make it more or less valuable based on how you build it.
And my point is the client is never a nice-to-have, it’s always essential. On top of that, proper business functionality requires proper presentation in the client. Business value is inherently coupled to the user interface.
The client doing something is often a nice-to-have.
When they say ‘the client doing something’, they are talking about things like ‘drag an email into the Trash folder to delete it’, which is a nice-to-have. Whereas if you are looking at an email and click the Delete button, the server actually deleting the email is essential.
Go back and read that paragraph carefully. It’s not difficult to get this when it’s in the proper context. The immediate previous sentence is:
Many interactions are not possible without JavaScript, but that doesn’t mean we should look to write more than we have to.
Clearly we are talking about complex interactivity that can only be implemented with JavaScript when we say ‘nice-to-have’.
It seems to me you also have not read what I wrote. This is the key part:
Business value is inherently coupled to the user interface.
Sometimes interactivity is essential to the business functionality. That’s the point. Like, great for this person who doesn’t need it. That doesn’t mean that’s how every business is. Sending an email is a silly example. Most businesses are not email-sending businesses.
For example, anything involving complex data analysis. Which every vertical SaaS app ends up becoming. Tables and buttons for server-rendered data actively gets in the way of achieving business value. Because business value is completely coupled to the client experience.
That’s not a good faith summary of what’s going on here, at all. It’s clear that we have different definitions of “sometimes.”
My definition is that more often than not, more interactivity is better. The author’s definition is that more often than not, less interactivity is better.
I frankly don’t know what your opinion is since you’re only nitpicking words and trying to be a representative for the posts’s author or (ironically you seem to be the one just looking to argue for the sake of arguing. I have an actual point).
The article is about entirely moving away from a JS-heavy framework, and claiming that:
“fat client” era JS-heavy frontends is on its way out
I disagree with this. And I think HTMX, and server rendering in general, is going back to the Stone Age.
My definition is that more often than not, more interactivity is better
If you are redefining the meaning of ‘sometimes’ to be ‘more often than not’, then I don’t have anything more to say because this is not a useful discussion.
Do you have an interest in getting into the conversation of preferring interactivity or not? That was my real intention all the way back to my initial reply. We’ve devolved into nitpicking about the semantics of words, which I agree isn’t useful.
I already engaged in good faith by giving an example of the kind of interactions that the OP was talking about, the drag-and-drop email delete. I don’t see how any reasonable person can disagree that these kinds of interactions are often nice-to-have rather than essential 🤷♂️
What if it were proven that the drag-and-drop experience prevented accidental deletions, made it more clear to the user what they were doing, as well as reduced the time it took to figure out how to perform the action they wanted to take?
Would that fall under “essential” to you? Because sure, the user technically could take the action without any them, but this is just another manifestation of the Turing tarpit. Just because something can be done doesn’t mean that it is practically viable for it to be done.
What if we both magically set up our own scenarios such that they were infallible and unassailable? This is not engaging with the discussion, it is just steelmanning your own point to make sure you never have to acknowledge another’s. No reasonable developer would ascribe those benefits to DnD UIs. In fact DnD is also an accessibility nightmare for people without perfect motor control. Let’s be realistic here.
Just because something can be done doesn’t mean that it is practically viable for it to be done.
This is exactly the point that OP and I are trying to make. Just because a fancy interactive UI can be made with JavaScript, doesn’t mean it should.
I think you would benefit from watching this talk that delves into the complexities of UI/UX/interaction design and just how difficult it is to get it right: https://youtu.be/mtHf7crZZIQ
Think several times before reaching for JavaScript to code up fancy interactions. Chances are really good that it will be broken for a large variety of users.
Friend, the point of the contrived example was to see if you distinguish between technically supporting requirements and supporting them well (for an arbitrary definition of “well” and nothing to do with drag and drop in particular). Not to trick you into agreeing with something.
This is exactly the point that OP and I are trying to make. Just because a fancy interactive UI can be made with JavaScript, doesn’t mean it should.
You misunderstood the point then. My point was that an oversimplified UI technically works, but that shouldn’t count as fulfilling a user’s requirements because the requirements may include a more efficient interaction. Your point is that just because a more complicated UI can exist doesn’t mean it should exist. These are not the same thing. Do you see the difference?
the requirements may include a more efficient interaction
Do you see that you are repeatedly making up scenarios where your argument can be the only possible ‘winner’? I gave you a realistic, reasonable scenario to illustrate my point. You took it and repeatedly tried to move the goalposts.
‘What if DnD is actually better for moving emails to Trash?’ It’s not.
‘What if the requirements require it?’ Then ask where the requirements come from. More often than not someone just added it in without thinking through the tradeoffs and consequences, and if you let them know, they will immediately and happily drop it.
Clearly we are talking about complex interactivity that can only be implemented with JavaScript when we say ‘nice-to-have’.
Just for fun, that kind of drag and drop thing actually can be done without javascript. Make the emails links and have a textarea. When you drag and drop a link in, the URL lands there. Server then parses the pasted link text and makes it so. See: https://arsdnet.net/ddemail.html
Is this a good experience? No, it sucks lol, I’d do some script here too (well actually, I’d probably just have a delete button or maybe a checkbox on the list or something, I think that’s easier to use than drag and drop anyway). But you can make it work. Again, just for fun.
If you step outside the world of web SaaS, then there are all kinds of software where the client is a requirement to the business and a server is unneeded or a nice-to-have. I don’t think you can make such a generalised distinction based on where your code runs.
I don’t think you can make such a generalised distinction based on where your code runs.
But they didn’t make a generalized distinction, they made it specifically in the world of React-based SPAs, which you are tried to step out of earlier, but as established, we are not doing that.
I feel like the Ruby line got a lot steeper after the “epoch” . It’s hard to tell because there seems to be a lot of noise in the Ruby line, but it feels a bit disingenuous to just say “look, we wrote less JavaScript than we would’ve” without addressing what you wrote instead and how much of it you wrote.
I don’t think it’s a contradiction. A business can grow liabilities and, as long as it is growing assets faster, that’s fine. If you take out a loan at 5% interest to be able to grow revenue at 50% annually, you’re growing liabilities but in a way that lets you grow the business. The problem is when your liabilities grow faster than your assets. If you’re adding useful features that users want, you’re growing assets, and the cost of this is that you also grow the amount of code you have (liabilities).
I think the GP refers to the contradiction between the article’s sections, not between terms.
In the Javascript/React section code was highlighted as being a liability, and they needed to get rid of it.
In the Ruby/Rails section they simply acknowledge superlinear growth (part of which compensates for the decline in clientside code, which they do not address), and simply call this growth “expected”.
Maybe it’s the changing interest rates or political winds, but I think the “fat client” era JS-heavy frontends is on its way out.
I wish, but I use NoScript and I feel that every day, the share of blank pages when not running JS increases. Also, the share of stuff that brought my old laptop to its knees.
“Content” websites still are best with SSR. I have come to accept that browser and Javascript-based has become the cross-platform GUI by default for highly interactive applications. Although most GUIs developed on that stack are unnecessarily sluggish, there are reasonably fast users, such as VS Code. (Yes, it is slower than most non-web-based editors. But it’s fast enough and much faster than the average web-based GUI.)
It is, IMHO, incorrect to implement something like Slack using HTMX or similar technologies. And given the lack of alternatives to browsers (QT is perhaps the most viable?), I understand it’s so popular.
Of course, there’s a wide spectrum between “content websites” and “highly interactive applications”, where I think SSR + progressive enhancement makes a ton of sense to add real-time elements, improve basic UIs, etc.
Basically, when you naturally keep a complex model (in the case of Excalidraw, the elements of the drawing) that is synchronized with HTML elements (or SVG, etc.). I am not an HTMX expert, but I really doubt you want to implement Excalidraw with HTMX.
Back in 2004 I worked on a web application that had some scheduling UI. (I thought it was implemented using JQuery, but I just realized JQuery came out in 2006.) We basically keep some internal datastructures in JS and rendered HTML elements to display schedule grids. It was tedious implementing by hand, and it was quite buggy- things would go out of sync after some operations, and users would need to reload. Something like React would have helped us a lot.
(Fun anecdote: we rendered the initial full grid using JS, but for lots of scheduling slots, it took ages to load. This was after rendering the grid on the server meant a huge download, which was also unusable. The “fixed” the performance issue by reverting to SSR and… enabling mod_gzip! So we did the SSR -> JS -> SSR dance 20 years ago already!)
(Fun anecdote 2: I’m a bit fuzzy on the timeline of Ajax, XMLHttpRequest, and the diverse iframe tricks that were used in those days. This was a different time and age, and when one of my colleagues shared with us these techniques, they blew my mind!)
OK, yeah, after taking a quick look at that, I’d probably do that with javascript too (or heck, given it is mostly one big canvas, probably have even done it in D compiled to webassembly).
I ask this somewhat rhetorically because I’d argue that any form that requires user text input is highly interactive by almost any definition (and having implemented all that from scratch myself…. probably the hardest programming task I’ve ever taken up, there’s a lot of tricky detail in implementing the text edit stuff people expect - scrolling is harder than it looks, highlighting and arrow keys have subtleties you only notice when it is broken, keyboard input is pretty involved to handle all the combinations, chords, input method sequences, etc., then the text layout and drawing stuff itself is a deep hole, and the interop protocols needed for clipboards to work take some effort to implement right…. like I’m glad in html you put <textarea> and it works lol, I’d actually argue making rich text layout w/ embedded widgets dead easy is why HTML won). There’s quite a bit of internal state to a text edit widget too that you want to work, but probably don’t want in your application model.
But, at the same time, the interface of the textarea is…. well, also pretty involved, see the selection api, but you can mostly encapsulate it into a content string property and a change event and go very far with it. So arguably, the highly interactive component can be part of a minimally interactive application. Then you ask: how do you get to an highly interactive application? If you had ten textareas does that do it? I don’t think so.
No, I think the definition has to be in terms of interactions between components. So I think “highly interactive” is not referring to the user, but rather to the software components, between branches of the dom tree. I haven’t gotten down to a more detailed definition yet, hence trying to gather ideas in comments like these….
Back in 2004 I worked on a web application that had some scheduling UI.
Yeah, I did a scheduling thing last year too, I did it as a loop on the server to generate the slots - fundamentally, what I wanted on the server was a list of “preferred”, “tolerable”, “impossible” for each time slot for the user, so it is an array of inputs for that, then javascript made this easier to user so you can click and drag and stuff like that; a progressively enhanced form. Nothing too fancy but it worked for me.
And yeah, gzipping html is such an easy win, was back then, still is now!
Fun anecdote 2: I’m a bit fuzzy on the timeline of Ajax, XMLHttpRequest, and the diverse iframe tricks that were used in those days.
Yeah, I don’t think I used ajax until 2010ish (did my first part-time web job in 2005, then i went full time 2009-2018, so this prolly more selection bias from my experience more than any big trend). Pretty sure it was an IE5 feature so it was around but a pain to use for a long time anyway, for a while I have some javascript boilerplate that did the whole ActiveObject create dance to find the right syntax lol. Nowadays of course use new XMLHttpRequest and the code reviewer will be like fetch lol.
To me, it’s about how viable it is to implement your UI as progressive enhancement JS on top of SSR HTML.
If you feel like writing it in vanilla JS, go for it. If you find yourself dealing with endless state bugs, go use something that can bind between DOM elements and your data model, instead of trying to hack it out by hand or writing your own system. I assume within the million JS frameworks out there, there must be some that can do this well.
I realize this is not the best definition, but I think it works.
Their heyday came and went during a period when I had no need to try them out, but before things like React took the spotlight, libraries like Backbone.js were the thing of note.
I ask this somewhat rhetorically because I’d argue that any form that requires user text input is highly interactive by almost any definition (and having implemented all that from scratch myself…. probably the hardest programming task I’ve ever taken up, there’s a lot of tricky detail in implementing the text edit stuff people expect - scrolling is harder than it looks, highlighting and arrow keys have subtleties you only notice when it is broken, keyboard input is pretty involved to handle all the combinations, chords, input method sequences, etc., then the text layout and drawing stuff itself is a deep hole, and the interop protocols needed for clipboards to work take some effort to implement right…. like I’m glad in html you put and it works lol, I’d actually argue making rich text layout w/ embedded widgets dead easy is why HTML won). There’s quite a bit of internal state to a text edit widget too that you want to work, but probably don’t want in your application model.
I’ve become quite a fan of Blazor. You can get SSR with pre-rendering and fairly easy interactivity with very little to no JavaScript, with strong typing and react-esque components.
Sure, a bit of JavaScript under the hood, but it feels like a good trade off in the personal projects I’ve built.
Interesting and depending type of application this is likely good decision. Speaking of going server Side Rendering that is (going Ruby is questionable on many layers).
But this differs greatly base on use case.
In case of Wide Angle Analytics we built landing/blog/docs with SSR or even full static rendering. But the core app, which is data heavy, benefits from sending just raw data via API and do fast rendering on client.
I was wondering about the choice of Ruby/Rails as it’s been labeled as notoriously slow. Still reading through the article, trying to understand the problem they need to solve and what less JavaScript is doing for them.
I was wondering about the choice of Ruby/Rails as it’s been labeled as notoriously slow.
Based on first-hand experience I would be more nuanced:
RoR can be slow if you’re not careful (typical of ORMs).
Ruby itself is slower than similar languages but it’s fast enough.
You get a big gain in early-to-middle development time.
Ruby and RoR have a pleasant developer experience with lots of references and components.
Reasonably easy hiring or learning it by an existing developer.
I probably wouldn’t choose it today but knocking out CRUD and reporting apps or bits of configuration (Chef) worked well enough that it wasn’t in the top ten reasons for startup/project failures.
I imagine more client computation makes sense when bandwidth is limited or latency is high. It also makes sense if you can share code between your web client and your phone App.
A type of application I am apart of is essentially a reporting application or a dashboard. It primarily reads information from a database, some calculations on the backend, and the only thing that it saves are some user selections that affect the view being displayed (filters).
This application is done in Angular. I do love angular and love where it is going. But the application is a little bit of a beast at times.
I have considered how the application could look without that. What if it were using something like htmx? The mcmaster-carr site is a nice example of the performance I am sure we would all want. Some of our pages do take some time to load elements (cards), although we want it less than 3 seconds ideally.
Some immediate problems I can think of are charts which need some ability to dynamically lay themselves out. We use d3 or parts of d3 for the math + svg. These could be implemented using a dedicated web component for a chart. The purpose of isolating it to a web component is suddenly it is not beholden to anything outside of its parameters.
Filters used on the dashboard are the other interactive part. Some of this would require interaction and some representation of the state - a web component for some of the more complicated parts could be useful here.
But outside of those areas and some lingering questions a heavy framework like angular isn’t really required. But I am not entirely convinced it could truly be made simpler. But we are doing more stuff on the backend as time goes on - so who knows.
Anyone else mentally thinking about this sort of thing, even if it is unlikely to gain traction anytime soon?
For dashboard, i would 100% go with something like phoenix live view. Web Components eff-ed up their isolation and composition, but Phoenix Live views and Live Components hit the spot well.
I played around with progressive enhancement here a bit a long while ago (in the jQuery age), wondering what’s the basic content of a graph. One of the more obvious choices was a table, which would fit nicely with the HTMX approach. For simpler graphs, this might even be more than a wire protocol and could be displayed in a noscript environment or be directly accessible as a stand-alone web page. For more complex and interactive ones, it’s not a really good fit (but then again, what is?). It’s also quite good for debugging.
Now you can do web components or some less structured HTML stuff for this. Heck, with the most recent Angular versions, I wouldn’t even rule out that framework, if enough developer are familiar with that.
On the other hand, if both filters and graphs are highly complex and interactive, you don’t gain that much. Also if there’s not much else to the dashboard but that.
I think that’s mostly debunked at this point, due to the performance creep and complexity that comes in with a more complicated client-server relationship.
Nonsense. I can make any SPA fast or any server rendered site slow.
A great quote from the article, which also resembles the HTMX philosophy.
This is not true in any sense: a backend process that performs no I/O and leaves no observable output has no user value. There needs to be an interface between the user and the application.
We can debate how rich that interface needs to be, but there is most certainly value in the interface itself. And you can make it more or less valuable based on how you build it.
(Emphasis mine)
And my point is the client is never a nice-to-have, it’s always essential. On top of that, proper business functionality requires proper presentation in the client. Business value is inherently coupled to the user interface.
You have not understood their point. They said:
When they say ‘the client doing something’, they are talking about things like ‘drag an email into the Trash folder to delete it’, which is a nice-to-have. Whereas if you are looking at an email and click the Delete button, the server actually deleting the email is essential.
Go back and read that paragraph carefully. It’s not difficult to get this when it’s in the proper context. The immediate previous sentence is:
Clearly we are talking about complex interactivity that can only be implemented with JavaScript when we say ‘nice-to-have’.
It seems to me you also have not read what I wrote. This is the key part:
Sometimes interactivity is essential to the business functionality. That’s the point. Like, great for this person who doesn’t need it. That doesn’t mean that’s how every business is. Sending an email is a silly example. Most businesses are not email-sending businesses.
For example, anything involving complex data analysis. Which every vertical SaaS app ends up becoming. Tables and buttons for server-rendered data actively gets in the way of achieving business value. Because business value is completely coupled to the client experience.
I feel like you are now arguing for the sake of arguing. Basically you are saying the same thing in a different way.
Them: it’s often not needed.
You: it’s sometimes needed.
OK great sometimes it’s needed 👍🏼
That’s not a good faith summary of what’s going on here, at all. It’s clear that we have different definitions of “sometimes.”
My definition is that more often than not, more interactivity is better. The author’s definition is that more often than not, less interactivity is better.
I frankly don’t know what your opinion is since you’re only nitpicking words and trying to be a representative for the posts’s author or (ironically you seem to be the one just looking to argue for the sake of arguing. I have an actual point).
The article is about entirely moving away from a JS-heavy framework, and claiming that:
I disagree with this. And I think HTMX, and server rendering in general, is going back to the Stone Age.
Do you have an opinion on that?
Here is what you said first:
Here is what you are saying now:
If you are redefining the meaning of ‘sometimes’ to be ‘more often than not’, then I don’t have anything more to say because this is not a useful discussion.
Do you have an interest in getting into the conversation of preferring interactivity or not? That was my real intention all the way back to my initial reply. We’ve devolved into nitpicking about the semantics of words, which I agree isn’t useful.
I already engaged in good faith by giving an example of the kind of interactions that the OP was talking about, the drag-and-drop email delete. I don’t see how any reasonable person can disagree that these kinds of interactions are often nice-to-have rather than essential 🤷♂️
What if it were proven that the drag-and-drop experience prevented accidental deletions, made it more clear to the user what they were doing, as well as reduced the time it took to figure out how to perform the action they wanted to take?
Would that fall under “essential” to you? Because sure, the user technically could take the action without any them, but this is just another manifestation of the Turing tarpit. Just because something can be done doesn’t mean that it is practically viable for it to be done.
What if we both magically set up our own scenarios such that they were infallible and unassailable? This is not engaging with the discussion, it is just steelmanning your own point to make sure you never have to acknowledge another’s. No reasonable developer would ascribe those benefits to DnD UIs. In fact DnD is also an accessibility nightmare for people without perfect motor control. Let’s be realistic here.
This is exactly the point that OP and I are trying to make. Just because a fancy interactive UI can be made with JavaScript, doesn’t mean it should.
I think you would benefit from watching this talk that delves into the complexities of UI/UX/interaction design and just how difficult it is to get it right: https://youtu.be/mtHf7crZZIQ
Think several times before reaching for JavaScript to code up fancy interactions. Chances are really good that it will be broken for a large variety of users.
Friend, the point of the contrived example was to see if you distinguish between technically supporting requirements and supporting them well (for an arbitrary definition of “well” and nothing to do with drag and drop in particular). Not to trick you into agreeing with something.
You misunderstood the point then. My point was that an oversimplified UI technically works, but that shouldn’t count as fulfilling a user’s requirements because the requirements may include a more efficient interaction. Your point is that just because a more complicated UI can exist doesn’t mean it should exist. These are not the same thing. Do you see the difference?
Do you see that you are repeatedly making up scenarios where your argument can be the only possible ‘winner’? I gave you a realistic, reasonable scenario to illustrate my point. You took it and repeatedly tried to move the goalposts.
‘What if DnD is actually better for moving emails to Trash?’ It’s not.
‘What if the requirements require it?’ Then ask where the requirements come from. More often than not someone just added it in without thinking through the tradeoffs and consequences, and if you let them know, they will immediately and happily drop it.
Just for fun, that kind of drag and drop thing actually can be done without javascript. Make the emails links and have a textarea. When you drag and drop a link in, the URL lands there. Server then parses the pasted link text and makes it so. See: https://arsdnet.net/ddemail.html
Is this a good experience? No, it sucks lol, I’d do some script here too (well actually, I’d probably just have a delete button or maybe a checkbox on the list or something, I think that’s easier to use than drag and drop anyway). But you can make it work. Again, just for fun.
If you step outside the world of web SaaS, then there are all kinds of software where the client is a requirement to the business and a server is unneeded or a nice-to-have. I don’t think you can make such a generalised distinction based on where your code runs.
But we are not doing that in this post.
But they didn’t make a generalized distinction, they made it specifically in the world of React-based SPAs, which you are tried to step out of earlier, but as established, we are not doing that.
I feel like the Ruby line got a lot steeper after the “epoch” . It’s hard to tell because there seems to be a lot of noise in the Ruby line, but it feels a bit disingenuous to just say “look, we wrote less JavaScript than we would’ve” without addressing what you wrote instead and how much of it you wrote.
Yes, the article says it grows superlinearly
Saying that it is ‘expected’ or good while also calling code a liability is contradictory imho.
I don’t think it’s a contradiction. A business can grow liabilities and, as long as it is growing assets faster, that’s fine. If you take out a loan at 5% interest to be able to grow revenue at 50% annually, you’re growing liabilities but in a way that lets you grow the business. The problem is when your liabilities grow faster than your assets. If you’re adding useful features that users want, you’re growing assets, and the cost of this is that you also grow the amount of code you have (liabilities).
I think the GP refers to the contradiction between the article’s sections, not between terms.
In the Javascript/React section code was highlighted as being a liability, and they needed to get rid of it.
In the Ruby/Rails section they simply acknowledge superlinear growth (part of which compensates for the decline in clientside code, which they do not address), and simply call this growth “expected”.
I wish, but I use NoScript and I feel that every day, the share of blank pages when not running JS increases. Also, the share of stuff that brought my old laptop to its knees.
“Content” websites still are best with SSR. I have come to accept that browser and Javascript-based has become the cross-platform GUI by default for highly interactive applications. Although most GUIs developed on that stack are unnecessarily sluggish, there are reasonably fast users, such as VS Code. (Yes, it is slower than most non-web-based editors. But it’s fast enough and much faster than the average web-based GUI.)
It is, IMHO, incorrect to implement something like Slack using HTMX or similar technologies. And given the lack of alternatives to browsers (QT is perhaps the most viable?), I understand it’s so popular.
Of course, there’s a wide spectrum between “content websites” and “highly interactive applications”, where I think SSR + progressive enhancement makes a ton of sense to add real-time elements, improve basic UIs, etc.
What is a highly interactive application?
Excalidraw, for example.
Basically, when you naturally keep a complex model (in the case of Excalidraw, the elements of the drawing) that is synchronized with HTML elements (or SVG, etc.). I am not an HTMX expert, but I really doubt you want to implement Excalidraw with HTMX.
Back in 2004 I worked on a web application that had some scheduling UI. (I thought it was implemented using JQuery, but I just realized JQuery came out in 2006.) We basically keep some internal datastructures in JS and rendered HTML elements to display schedule grids. It was tedious implementing by hand, and it was quite buggy- things would go out of sync after some operations, and users would need to reload. Something like React would have helped us a lot.
(Fun anecdote: we rendered the initial full grid using JS, but for lots of scheduling slots, it took ages to load. This was after rendering the grid on the server meant a huge download, which was also unusable. The “fixed” the performance issue by reverting to SSR and… enabling
mod_gzip! So we did the SSR -> JS -> SSR dance 20 years ago already!)(Fun anecdote 2: I’m a bit fuzzy on the timeline of Ajax, XMLHttpRequest, and the diverse iframe tricks that were used in those days. This was a different time and age, and when one of my colleagues shared with us these techniques, they blew my mind!)
Excellent phrasing right there.
want vs should vs can.
Can you build Excalidraw with HTMX? You can… Probably most of the work will be just JS with the HTMX taking care of some kind of last mile.
Should you build Excalidraw with HTMX? Maybe… If backend is more up your alley than front-end.
But do you want to build Excalidraw with HTMX? No… Because there are better ways to build Excalidraw than with HTMX.
OK, yeah, after taking a quick look at that, I’d probably do that with javascript too (or heck, given it is mostly one big canvas, probably have even done it in D compiled to webassembly).
I ask this somewhat rhetorically because I’d argue that any form that requires user text input is highly interactive by almost any definition (and having implemented all that from scratch myself…. probably the hardest programming task I’ve ever taken up, there’s a lot of tricky detail in implementing the text edit stuff people expect - scrolling is harder than it looks, highlighting and arrow keys have subtleties you only notice when it is broken, keyboard input is pretty involved to handle all the combinations, chords, input method sequences, etc., then the text layout and drawing stuff itself is a deep hole, and the interop protocols needed for clipboards to work take some effort to implement right…. like I’m glad in html you put
<textarea>and it works lol, I’d actually argue making rich text layout w/ embedded widgets dead easy is why HTML won). There’s quite a bit of internal state to a text edit widget too that you want to work, but probably don’t want in your application model.But, at the same time, the interface of the textarea is…. well, also pretty involved, see the selection api, but you can mostly encapsulate it into a
contentstring property and achangeevent and go very far with it. So arguably, the highly interactive component can be part of a minimally interactive application. Then you ask: how do you get to an highly interactive application? If you had ten textareas does that do it? I don’t think so.No, I think the definition has to be in terms of interactions between components. So I think “highly interactive” is not referring to the user, but rather to the software components, between branches of the dom tree. I haven’t gotten down to a more detailed definition yet, hence trying to gather ideas in comments like these….
Yeah, I did a scheduling thing last year too, I did it as a loop on the server to generate the slots - fundamentally, what I wanted on the server was a list of “preferred”, “tolerable”, “impossible” for each time slot for the user, so it is an array of inputs for that, then javascript made this easier to user so you can click and drag and stuff like that; a progressively enhanced form. Nothing too fancy but it worked for me.
And yeah, gzipping html is such an easy win, was back then, still is now!
Yeah, I don’t think I used ajax until 2010ish (did my first part-time web job in 2005, then i went full time 2009-2018, so this prolly more selection bias from my experience more than any big trend). Pretty sure it was an IE5 feature so it was around but a pain to use for a long time anyway, for a while I have some javascript boilerplate that did the whole ActiveObject create dance to find the right syntax lol. Nowadays of course use
new XMLHttpRequestand the code reviewer will be likefetchlol.To me, it’s about how viable it is to implement your UI as progressive enhancement JS on top of SSR HTML.
If you feel like writing it in vanilla JS, go for it. If you find yourself dealing with endless state bugs, go use something that can bind between DOM elements and your data model, instead of trying to hack it out by hand or writing your own system. I assume within the million JS frameworks out there, there must be some that can do this well.
I realize this is not the best definition, but I think it works.
Their heyday came and went during a period when I had no need to try them out, but before things like React took the spotlight, libraries like Backbone.js were the thing of note.
You’re reminding me of these two excellent posts:
I’ve become quite a fan of Blazor. You can get SSR with pre-rendering and fairly easy interactivity with very little to no JavaScript, with strong typing and react-esque components.
Sure, a bit of JavaScript under the hood, but it feels like a good trade off in the personal projects I’ve built.
Same here! People often seem to disregard C# / .NET, but the tech and tooling around it are incredible.
Interesting and depending type of application this is likely good decision. Speaking of going server Side Rendering that is (going Ruby is questionable on many layers).
But this differs greatly base on use case.
In case of Wide Angle Analytics we built landing/blog/docs with SSR or even full static rendering. But the core app, which is data heavy, benefits from sending just raw data via API and do fast rendering on client.
I was wondering about the choice of Ruby/Rails as it’s been labeled as notoriously slow. Still reading through the article, trying to understand the problem they need to solve and what less JavaScript is doing for them.
Based on first-hand experience I would be more nuanced:
I probably wouldn’t choose it today but knocking out CRUD and reporting apps or bits of configuration (Chef) worked well enough that it wasn’t in the top ten reasons for startup/project failures.
I imagine more client computation makes sense when bandwidth is limited or latency is high. It also makes sense if you can share code between your web client and your phone App.
I enjoy this much more than yet another Alex Russell article.
A type of application I am apart of is essentially a reporting application or a dashboard. It primarily reads information from a database, some calculations on the backend, and the only thing that it saves are some user selections that affect the view being displayed (filters).
This application is done in Angular. I do love angular and love where it is going. But the application is a little bit of a beast at times.
I have considered how the application could look without that. What if it were using something like htmx? The mcmaster-carr site is a nice example of the performance I am sure we would all want. Some of our pages do take some time to load elements (cards), although we want it less than 3 seconds ideally.
Some immediate problems I can think of are charts which need some ability to dynamically lay themselves out. We use d3 or parts of d3 for the math + svg. These could be implemented using a dedicated web component for a chart. The purpose of isolating it to a web component is suddenly it is not beholden to anything outside of its parameters.
Filters used on the dashboard are the other interactive part. Some of this would require interaction and some representation of the state - a web component for some of the more complicated parts could be useful here.
But outside of those areas and some lingering questions a heavy framework like angular isn’t really required. But I am not entirely convinced it could truly be made simpler. But we are doing more stuff on the backend as time goes on - so who knows.
Anyone else mentally thinking about this sort of thing, even if it is unlikely to gain traction anytime soon?
For dashboard, i would 100% go with something like phoenix live view. Web Components eff-ed up their isolation and composition, but Phoenix Live views and Live Components hit the spot well.
I played around with progressive enhancement here a bit a long while ago (in the jQuery age), wondering what’s the basic content of a graph. One of the more obvious choices was a table, which would fit nicely with the HTMX approach. For simpler graphs, this might even be more than a wire protocol and could be displayed in a noscript environment or be directly accessible as a stand-alone web page. For more complex and interactive ones, it’s not a really good fit (but then again, what is?). It’s also quite good for debugging.
Now you can do web components or some less structured HTML stuff for this. Heck, with the most recent Angular versions, I wouldn’t even rule out that framework, if enough developer are familiar with that.
On the other hand, if both filters and graphs are highly complex and interactive, you don’t gain that much. Also if there’s not much else to the dashboard but that.
Nonsense. I can make any SPA fast or any server rendered site slow.