Great idea! ++ for things that are jQuery-free. :)
One quick (fix/)suggestion: the kutty header on the top left, even being a clickable link to home as expected, changes the cursor to textual selection cursor upon hover instead of the usual link/hand/finger pointer. :)
I've been really interested in Intercooler.js, but the jQuery dependency bummed me out. This is a very cool project, and I highly appreciate you putting in the work here!
I do have one question. Is there a specific reason why you chose not to follow the standardized specification[0] of using data-* prefixes for HTML attributes? I realize it's pedantic, but I'd like to see this project receive wide support and usage. I'm concerned many potential users will criticize this.
Same thing happened to me. I was really intrigued by intercooler when I first found it a couple years ago, but lacking experience in the front-end, I found myself cornered in a conversation about it with a React snob. Ultimately, I turned my attention elsewhere before I ever got a chance to sink my teeth into it.
Glad to see the project is going strong and getting a makeover. Especially in web development, the constant obsession with the Next Big Thing can be a real deterrent against some really cool ideas. Kutty won't make you a more desirable job candidate or force you to develop new and challenging mental models (afaiu); it'll never give rise to an ecosystem of plugins and extensions the way React has; and with Webpack integration in the latest release of Rails (where I'm coming from), frontend frameworks are being normalized as the default approach (or at least the final destination) of any web application these days.
But engineering is about trade-offs. There's a sizable chunk of projects out there whose requirements are modest enough to be met with HTML, AJAX, and a little glue to hold them together, and kutty seems to provide a really clean abstraction layer there.
One of you is definitely wrong, but it depends on the scope of the project. I would never build an SPA with intercooler and I would never build a static website with Angular/React.
I mean question is when do you need a spa. Take my beloved online pivot table. The web UI state is very similar to the server state. For instance, if the user adds a dimension to the pivot we need to instantly feed that back to the server. So it makes sense to use kutty here because server and web state are pretty much in sync and why would you not leverage server rendering for this.
Most apps I work on deal with large amounts of complex domain objects which are constantly being updated. A recent project ended up sending an average of 1 request per second. Doing all this server-side is a non-starter.
This is why I build SPAs: binding a button to a fetch request is the easy part. Managing lots of data in an dynamic/interactive UI is where I spend most of my time.
and why is that? Though mithril.js fan here, but intercooler, kitty, unpoly - they look fantastic kit for SPA. These libraries just look like what Golang is against C++ and Java.
For the same reason I use React instead of jQuery. Kutty/Intercooler handle simple AJAX very cleanly but as the volume of data and scope of interactivity increases it becomes difficult to manage.
Would this work with an html table element? I am building online pivot tables and I like the idea of building the entire table on the server and swapping it with a div on user click.
Hey just some feedback. The UX there is wrong because there is instant feedback in the toggling of the activate/deactivate button but a slight delay in the reaction time for the selected row (due to the round trip). I believe the correct paradigm here is for the button to not toggle state until the response is received/acted upon (to indicate a short “hang”).
Unpoly is awesome, and I think deserves more recognition. Having said that I recently moved to Alpine JS (plus Turbolinks) and I think that also deserves more recognition https://github.com/alpinejs/alpine
Yup, so this is really for my use case - but essentially unpoly was great, but after a while I started having a lot of custom compilers for specific things.. And again, that's fine - but I was really trying to have less custom JS code off in seperate files. Turbolinks gave me the super simple ajax page-refresh concept, and Alpine allowed me to move my JS functionality inline.. which I actually like (for now!). I actually use Alpine with Laravel Livewire for some more server-side functionality that seems like magic (similar to Phoenix LiveView) https://laravel-livewire.com/docs/quickstart
I was amazed that this page preserved HTML and scroll even for dynamic content. I'm thinking about how to do the same in Vue, and my crazy idea is using a store/controller for each path and storing and retrieving it from an LRU cache on history events.
Congrats on the launch! As a big user of Intercooler, I'm curious about which features you considered mistakes, or which ideas didn't work out as well as you expected. My own library Hyperview is heavily inspired by Intercooler, so I'm hoping to learn from your experience!
- the ic-action attribute (sometimes it's OK to write some javascript)
Generally I'm trying to reduce the number of attributes and add a bit of syntax if necessary, e.g. kt-trigger="every 1s" vs. a separate ic-poll attribute.
Also I'm trying to make it pluggable so that people can add their own functionality rather than pressuring me to add a new attribute or feature. :)
Hyperview is an awesome library btw, everyone check it out:
This reminds me a lot of rails-ujs. I built a jquery-based alternative to intercooler (didn't know it existed) back in the day that used the rails-ujs events to do its thing.
A few days ago, instead of going this route, I just used a `.js` view in Rails to replace the necessary elements in the DOM. This is even easier than having to load something like kutty and specifying in attributes what it needs to do:
To all users of unpoly, intercooler / kutty: which one would you recommend for a new e-commerce project? I'm especially concerned by maintainability issues, as well as possible SEO implications.
45 comments
[ 4.1 ms ] story [ 102 ms ] threadOne quick (fix/)suggestion: the kutty header on the top left, even being a clickable link to home as expected, changes the cursor to textual selection cursor upon hover instead of the usual link/hand/finger pointer. :)
I'll fix it up.
update: fixed, thanks for calling me out for being lazy
I do have one question. Is there a specific reason why you chose not to follow the standardized specification[0] of using data-* prefixes for HTML attributes? I realize it's pedantic, but I'd like to see this project receive wide support and usage. I'm concerned many potential users will criticize this.
[0]: https://html.spec.whatwg.org/multipage/dom.html#embedding-cu...
Edit: Nevermind, I just looked through the docs from the start. You do support it!
Btw, check out the kt-classes attribute if you want to do some slick CSS transitions w/o javascript:
https://kutty.org/attributes/kt-classes/
Love it, thank you for putting so much effort into it!
That's part of the rename, I want it to break out of that comparison.
Glad to see the project is going strong and getting a makeover. Especially in web development, the constant obsession with the Next Big Thing can be a real deterrent against some really cool ideas. Kutty won't make you a more desirable job candidate or force you to develop new and challenging mental models (afaiu); it'll never give rise to an ecosystem of plugins and extensions the way React has; and with Webpack integration in the latest release of Rails (where I'm coming from), frontend frameworks are being normalized as the default approach (or at least the final destination) of any web application these days.
But engineering is about trade-offs. There's a sizable chunk of projects out there whose requirements are modest enough to be met with HTML, AJAX, and a little glue to hold them together, and kutty seems to provide a really clean abstraction layer there.
Really looking forward to trying it out soon.
This is why I build SPAs: binding a button to a fetch request is the easy part. Managing lots of data in an dynamic/interactive UI is where I spend most of my time.
and why is that? Though mithril.js fan here, but intercooler, kitty, unpoly - they look fantastic kit for SPA. These libraries just look like what Golang is against C++ and Java.
https://kutty.org/examples/bulk-update/
For others interested in this field of “graceful enhancement” see also unpoly: https://unpoly.com/
OP may also want to look into integrating some features/ideas from there as it is very similar to intercooler.
I’m currently using it in a project that’s a PWA and its been a pleasure to work with.
https://blog.makandra.com/2019/01/performance-impact-of-remo...
Can you explain your switch and the library choice a bit more? Turbolinks seems to me to be a very primitive version of Intercooler/Unpoly.
https://kutty.org/examples/click-to-load/
Here are some off the top of my head:
- the dependency mechanism (too magical)
- the ic-action attribute (sometimes it's OK to write some javascript)
Generally I'm trying to reduce the number of attributes and add a bit of syntax if necessary, e.g. kt-trigger="every 1s" vs. a separate ic-poll attribute.
Also I'm trying to make it pluggable so that people can add their own functionality rather than pressuring me to add a new attribute or feature. :)
Hyperview is an awesome library btw, everyone check it out:
https://hyperview.org/
Hypertext: the once and future king.
https://www.urbandictionary.com/define.php?term=kutty
Maybe in dutch it can be called mutty.
What, you don't like kutty?
A few days ago, instead of going this route, I just used a `.js` view in Rails to replace the necessary elements in the DOM. This is even easier than having to load something like kutty and specifying in attributes what it needs to do:
Taken from the Rails guides:
This uses jQuery, but you can all imagine how to do this with vanilla js and it works so well.