true, i think the new design saves them money (more efficient data model); and drives people into BigQuery which will eventually be paid. But i have to say that GA4+BigQuery gives a powerful combination.
Custom CSS properties make CSS even more powerful. For example you can configure a menu to fade in fullscreen on mobile while sliding in from left on desktop.
that's funny because i was always annoyed about the back functionality deleting all my carefully entered form data when unintentionally activating this gesture.
Anyway you are right. we need to make this configurable. Apart from that i find it very intuitive to use the touchpad swipe for in app navigation as it feels very much as on mobile devices.
The concept behind layerJS is very fundamental, so fundamental that one even thinks its already there. It must be there, but it's not. We looked deep. So we created a polyfill (please see my previous response).
Of course you can code every effect that layerJS can do manually. But then you would need to do so...
Oh hey, that's quite a critical comment. But usually the best comes out of criticism. So let me go a bit deeper to explain our case.
layerJS is not implementing a single UX effect. Then it would be indeed a bit too big for that. (Actually using jQuery + 1 plugin per effect would be even bigger)
layerJS implements a general UX concept that can handle basically all UX navigation pattern. It actually thinks HTML further: Instead of documents that are linked and loaded one after each other it actually links fragments (frames) into different views (stages) in an animated way.
With regular HTML documents you need code everything that is dynamic. And that actually makes things more complicated because you can't see from the declarative HTML how the final UI will look like. layerJS makes the UI layout and most of the interaction declarative, so everything is clearly declared in static HTML. And i think that the boilerplate for this is pretty small.
So your notion that some of the declarations should be in CSS or so is totally agreed. But we can't do this right now because the browsers do not support this yet. So for example the scrolling example is not working in pure CSS because we are actually allow something like "background-size: cover" (which usually only works for background images) to actually work on any frame while still allowing (or not allowing) scrolling. This we have to implement in javascript today and for this we need something like "lj-no-scrolling".
If the browser guys find the concept intriguing they may at some point implement similar mechanisms directly in HTML. For now I see layerJS as a polyfill for these concepts that may vanish at some time.
I hope i could clarify things a bit. Please let me know if that raises more questions. I really appreciate your long feedback, even if negative. I know from experience that out of those often good things arise!
Also, on a related suggestion, it could also be nice if layerJS could be modular, so that everyone does not need to download the whole thing if they only need the responsive menus, for example.
Of course, I realize that implementing this would be a lot of effort and would require change in your release flow.
But just in case, there's more demand for what I suggest, here's an inspiration from FontAwesome: https://fontawesome.com/get-started/svg-with-js. Note how they provide a fontawesome-all.js having all the icons. But they also provide separate fa-*.js for different icon families for the people who don't care about downloading the whole thing.
this is a very valid request. And we are thinking about it. But note that layerJS is not a collection of effects. It actually uses the same mechanism for every effect (that's the concept behind it). Maybe we can off-load some of the routers and some of the transitions types...
