I'm really excited to see this conversation, and I wanted to add a few things:
Age of HTMX
While HTMX itself was released in 2020, it is actually a rebuild of an earlier library called IntercoolerJs. So, the library itself is just about 4 years old, but the original version is 11 years old. This is not a "new shiny thing". It is actually an "old" shiny thing that has only recently been widely discovered.
HTMX _is_ Ajax
"The core of htmx is a set of attributes that allow you to issue AJAX requests directly from HTML" (from the docs). So, this is really just a more standardized and *easier* way to do Ajax. Think about how powerful it will be for developers to do much of their frontend Ajax work in Twig files. Pretty enticing.
At the same time, the complexity of the current Ajax system (while powerful) means that it is not seeing the usage or improvements people expect in a modern framework. I can click a button to get Ajax filtering of a view (cool!), but I still get that same old little spinner in a potentially random place... and trying to improve or adjust that behavior is a non-starter for most backend devs. HTMX provides a cleaner and more standard way of dealing with the Ajax issue.
Everything old is new again
The reason that HTMX is getting so much attention these days is similar to the increased focus we have seen on static sites. Speed, performance, and the recognition that things have gotten a bit out of hand for for building content focused websites. In this case, we see that the push for React/Angular/Vue as a full stack framework has led to ever more complex systems to build, tree shake, compile, partially render, and hydrate HTML code. This means that many, many applications are way over-engineered. So, there is a recognition that simpler approaches are just as good and often better. Highly reactive apps need a large JS framework, but most apps only need basic interactivity.
The core argument *for* HTMX goes like this - you make a call to a server to find data, run business logic, and then format it as JSON which is returned to the client. Then the client has to do more work to render that JSON at HTML and put it on the page. So, why not just return the HTML from the server directly? Its faster, its cache able, and it reduces the load (both time and JS assets) in the browser.
HTMX is a perfect fit for Drupal
Drupal is incredibly good at letting us generate HTML, and the templating system means we can generate it down to the field level. So, with very minor changes, we should be able to allow Drupal core to easily return HTML fragments of any entity template. Add in display modes and views, and suddenly you have the ability to create an entire HTMX backend with little to no code. Thats insanely powerful, and can give the project a shot in the arm. Instead of building a custom backend in python, laravel, or go... just use Drupal.
Then, add in the incredibly powerful caching system, and now we are in completely new territory. Drupal's caching system is one of the "best kept secrets" of the project, and by adopting some minor enhancements (like HTML fragments), we can make it even more visible and accessible. I can see how an HTMX + Drupal approach could invigorate the project and bring it more attention and a whole new type of modern developer.
HTMX is a perfect fit for Drupalistas
The average Drupalista is either a backend dev (php) or a front end themer (twig, css, js). Most "modern" app builders using React/Vue/Svelte don't want to work with Drupal - they want to use their framework. We have seen how much resistance there is to using Drupal as a purely decoupled content API - most devs who want that will go for Contentful or Strapi. Drupal can act as a content API, but it compeltely ignores the rendering engine... which is a shame.
HTMX is largely in line with this approach and is appealing to backend developers. It simplifies the front-end experience and gives us more
"spa-like" functionality with much less effort.
I think that this suggestion is about more than just making Ajax easier, adopting new tech, or even growing the community. I believe that this combination has the potential to reinvigorate the project by amplifying Drupal's core strengths and making the framework more relevant in the modern view.
Attached is the patch I'm using locally in my repo, and it seems to work well.
Please note that as I mentioned above, this works for D10, but it "breaks" for D9. So, accepting this directly in is fine, but we should be aware of it.
I just realized that I missed the Kanban css as well.
Note - this only works for Drupal 10 and is not backwards compatible... so a more complete solution will likely be needed. Options include:
- copying the SVG files to the module - the easiest
- loading a different CSS file for d10 using Deprecation helper
I would suggest the former since it is just 4 SVG files, but I leave it to the maintainers to decide. For now, this will allow D10 users to patch the CSS.
rlnorthcutt → created an issue.
nicxvan → credited rlnorthcutt → .
Yes - this would be a good thing to make progress on. As stated, there is a definite need and core contains much of what is needed.
I recently came across "FrankenPHP" which has a method for compiling a PHP app to a stand alone binary. So - consider that the Drupal instance is only needed for creation and editing, with the static output going to S3, GH pages, GL pages, etc.
If set up properly, then each author could simply add their content as a MR to the repo, and manage any edits or new content with Git. The DA could offer a free website to all users with GL Pages, and could offer a low cost solution for non-profits or smaller orgs. That would not only spread Drupal, but also help the DA generate a bit more funding.
nicxvan → credited rlnorthcutt → .
nicxvan → credited rlnorthcutt → .
nicxvan → credited rlnorthcutt → .
I can confirm that these duplicate classes are happening, but it seems to be only on the "Field Tag" classes, not all of them.
For example, here is the configuration for my "Body" field:
And here is the output:
Clearing the cache does no good, and resaving the settings does no good. Note that I have another field (taxonomy) with "Field Tag" classes, but those are not duplicated.
This is great news for the community. Thanks for all of your hard work, Lauri!
Actually, the solution may be even simpler than that. Instead of relying on fixed height and width settings, we can use the CSS aspect ratio property:
.video-embed {
aspect-ratio: 16 / 9;
width: 100%;
}The parent div will also need a 100% width, but once that is set, it should be turn key. No need for JS!
Perhaps the simplest thing to do is to provide another "Format" option for the field display. We have the current "oEmbed content" format, but we could create a "oEmbed responsive" one, which allows you to set the aspect ratio (with a default of 16/9). This means existing oEmbed media will not be affected, but users can easily make the change and get the benefit of responsive videos without needing to create custom templates, custom oEmbed providers, or use extra JS.
I hit the same error, but I was able to overcome it by adding
inline entity form →
first:
composer require 'drupal/inline_entity_form:^1.0@RC' (see the project for the proper version)
After that, I was able to install this module just fine.