3 ms·

> we used to call them "Single Page Web Applications" because avoiding page refreshes was the point I wonder if the problem was really that the whole page was

> we used to call them "Single Page Web Applications" because avoiding page refreshes was the point I wonder if the problem was really that the whole page was reloaded into the browser which caused a big "flash" because all of the page was-re-rendered. The problem maybe was not reloading the page from the server but re-rendering all of it. Whereas if you can load just parts of the page from the server the situation changes. It's ok if it takes some time for parts of the page to change because nothing gets "broken" while they are refreshing. Whereas if you reload the whole page everything is broken until all of it has been updated.

aidos 4y ago
We had this middle ground of returning html fragments and updating subsections of the page. For posting a comment, for example. There were plenty of sites doing that in the mid 2000s.
spion 4y ago
The problem was there was no concept of reusable components. IMO htmx is not the headline here but django-components (https://pypi.org/project/django-components/ https://pypi.org/project/django-components/) is. Managing html, css and JS in component-reusable chunks on the server used to be extremely awkward, especially when you begin to need lifecycle events (HTML appeared on the page, lets attach all the necessary event listeners, but only to the right element - even in a list of 5 elements; internal HTML changed, lets see which things need more events etc). I would try this approach out in a typechecked language, if I'm certain a native mobile app isn't going to be needed.
- galaxyLogic 4y ago
  I think your explanation makes it very clear. The difficulty with web-development is there are 3 different languages (HTML, CSS, JS) which all need to make some assumptions about what is coded in the other languages. The JavaScript refers to a DOM-element by id, it assumes some CSS which the JS can manipulate in a specific way. The ideal goal much of the time has been: "Keep content separate from presentation, keep behavior separate from the content etc.". While this has been achieved in a superficial level by keeping CSS in a .css -file, content in a .html-file and behaviors in a .js -file, they are not really independent of each other at all. And how they depend on each other is not declared anywhere. That means that to understand how a web-page works you must find, open and read 3 files. Therefore rather than having 3 different types of files a better solution might be to have 3 files all of which contain HTML, CSS, and JS. In other words 3 smaller .htm files, each embedding also the CSS and JS needed.

aidos 4y ago

We had this middle ground of returning html fragments and updating subsections of the page. For posting a comment, for example. There were plenty of sites doing that in the mid 2000s.

spion 4y ago

The problem was there was no concept of reusable components. IMO htmx is not the headline here but django-components (https://pypi.org/project/django-components/ https://pypi.org/project/django-components/) is. Managing html, css and JS in component-reusable chunks on the server used to be extremely awkward, especially when you begin to need lifecycle events (HTML appeared on the page, lets attach all the necessary event listeners, but only to the right element - even in a list of 5 elements; internal HTML changed, lets see which things need more events etc). I would try this approach out in a typechecked language, if I'm certain a native mobile app isn't going to be needed.

galaxyLogic 4y ago
I think your explanation makes it very clear. The difficulty with web-development is there are 3 different languages (HTML, CSS, JS) which all need to make some assumptions about what is coded in the other languages. The JavaScript refers to a DOM-element by id, it assumes some CSS which the JS can manipulate in a specific way. The ideal goal much of the time has been: "Keep content separate from presentation, keep behavior separate from the content etc.". While this has been achieved in a superficial level by keeping CSS in a .css -file, content in a .html-file and behaviors in a .js -file, they are not really independent of each other at all. And how they depend on each other is not declared anywhere. That means that to understand how a web-page works you must find, open and read 3 files. Therefore rather than having 3 different types of files a better solution might be to have 3 files all of which contain HTML, CSS, and JS. In other words 3 smaller .htm files, each embedding also the CSS and JS needed.