> Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software, including the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
> 1. The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
> 2. The Software must not be used in the code base of HTML editors or web builders. A HTML editor is a software (or hosted web application) that can be used by a third party (the user of the HTML editor) to create HTML documents that can be exported and used elsewhere. A web builder is a software (or hosted web application) that can be used by a third party (the user of the web builder) to create HTML documents that are hosted or dynamically generated under a top level domain chosen by the third party. The code base is the source code of the HTML editor or web builder, including the source code of publicly available plugins. No calls to layerJS can be made from the code base, but third party users can use layerJS in their websites that are built with these HTML editors or web builders.
> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
This is really not meant restrictive. Its basically MIT and only restricting one particular use case (if you want to build a webeditor like WIX, etc. ) It's currently protecting our baby startup (layerjs.com) and should avoid that someone is using layerjs.org (which will be used inside) to get an competitive edge on our baby (:
So don't be to harsh on this. We will remove this clause altogether once time is ready to launch.
I had a conceptually similar tool driving a startup way back in 2001. It failed because there was no market - people who couldn't code wanted to just hire a designer/developer. People who could code didn't care about a codeless web design tool. People who did use it nitpicked the resulting markup. Admittedly, many years have passed. The market may differ now. But I'd seriously validate the problem you are solving here.
If someone copies the startup after launch and you "lose" to them, does that mean they're better equipped in some way than you? If so, does the competitive edge actually matter?
I view it more as a myth stemming from survivor bias.
You're piling on massive amounts of attributes, making your app almost impossible to read and figure out the transitions. Anything complex is going to become a tangled pile of nodes and code. It would take anyone but the original designer a long time to puzzle out what exactly is going on and figure out the workflow, unless there's also a ton of HTML comments in there too.
You have attributes that should just be classes with CSS (overflow: hidden prevents scrolling, not sure why you need lj-no-scrolling), you have html elements that actually need to have attributes to define their neighbours, and you're just overloading your HTML with a bunch of extra baggage that doesn't need to be there.
Look at your parallax example. A 30KB library, a bunch of superfluous divs, and a ton of extra attributes you need to try to figure out have successfully replaced "background-attachment: fixed". The sliding divs could be done so much more clearly with just a bit of javascript that tracks "current frame" and hides them all then shows the next one when you click the button. The ZoomUI is admittedly pretty, but I feel like you could do it much easier with just a click event that expands the frame via changing the classes on it, rather than all the extra baggage and divs and wrappers you need to make that work. The animations are pretty, but not worth the extra baggage it takes to use them.
It's a neat toy, but I can really only see it being usable by people who are inherently terrified of javascript and will do anything to avoid it. And even then they'd only need the simplest of use-cases, and they'd need to make sure it wouldn't be on something that would need updates, because I wouldn't want to have to come back to a project with this in 6 months.
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!
While I agree with you that the implementation is not ideal, the use of "awful" is a little harsh and unnecessarily discouraging! To the creator, please don't take it to heart, but do look at the more constructive observations mentioned above :)
You are talking about their implementation. It's done in an old-school way(by extending HTML), and it would be very hard to build any sort of complex UI on this implementation.
However, the idea behind this project is pretty interesting. If you haven't already, do check out their presentation in the section "How LayerJS works".
The idea seems to be inherently "UI Composition in pure HTML", at least from the user's perspective. Which, sure, it's possible. But that's not a great idea. And the video is just how HTML works already. Firefox has had a neat inspector tool that showed you all that for years. "A div that loads above the rest and is anchored to the window" isn't new.
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...
I really like this and have added it to my "dive into on the weekend" bucket. The catch phrase got me: "UI composition in pure HTML"... but a bit of my optimism left when I realized that the page wouldn't scroll (there's not even a scrollbar) without JavaScript. But still, it's better than a blank page (and the header had enough info to tempt me to white list it!).
This is just a get-off-my-lawn nitpick/feature request - because I think it looks really interesting, great work!
On the body there is a `overflow: hidden` presumably to fix horizontal overflow. The selector causing this is `[lj-type="stage"]`, so the scrollbar not working without js might be an issue with the library, rather than just the marketing site.
yes, layerJS needs a "Stage" where navigation can happen so the scrollable content will be inside that Stage. In this case the body is the stage and the page is a frame inside it. We are working on something where the stage length adapts to the frame length. Then the body will become as long as the full content and native scrolling would even work if there is no JS
Thanks! It's indeed using javascript ;-) It also has some support for "native scrolling" that could help a bit in a non-JS environment. Let me know if you have any feedback after the weekend (:
Looks promising, but the web site keeps promoting this as "Pure HTML and CSS." But it's actually all run on JS. So, not actually pure HTML and CSS.
The video didn't work on my machine. It goes as far as "How does it work?" and then it's just random dots all over the page.
And the last straw was the pop-up asking me if I want more information when I'd only been on the page for five seconds. How do I know if I want more information if I haven't had a chance to look at the page yet?
Usually I lump these into "yet another JS library to throw on the fire." But this one seems a little different. We'll see.
Thanks. Yes you are absolutely right. It is of course a JS library, but its API is full "HTML". So you only need to do things to your HTML to control it. Actually we think that the concepts of layerJS are pretty much in line with the HTML concepts esp. the box model. So maybe one day all this fitting and transitioning (==linking) will be natively supported by the browsers and then really no JS will be needed.
The video (actually an animation) had some trouble on safari where the container background was on top of the 3d elements. I hope its that one. This is hot-fixed right now
The chat window should actally open only after a minute. I know it can be a bit nasty but we need feedback (:
This actually seems like a throwback to jQuery mobile which had a similar way of doing full page transitions. I always thought that was ahead of its time.
Thanks for reporting! The website uses a mechanism to load subpages dynamically. I guess the closing and opening restores the history, but reloads the page from the server. The the content from layerjs.org is missing, but the history "thinks" its there. So we need to catch this...
Love the idea - looks like a well-thought-out and much needed abstraction. The way I’d pitch it is that it allows one to create UI in a completely declarative and stateless manner.
I wish I had more to comment on, as I'm still reading through the docs, but just a quick note to the website dev. On tablet/mobile, all but the last 2 footer links cannot be clicked because the copyright text row covers the section. This made it so I couldn't see the Licence from the website. (I had to use the main menu to navigate to Github then to the Licence.)
This looks really interesting! I will have to try it out. The Parallax seems to be different than usual since the image in the background does not scroll. It would be really cool if you could make that background image scroll and at a different speed from the content. :-)
That is a really neat "video". I see that it is mostly just 3d-transformed LayerJS, but did you use any particular tools to do it? Whether to help fine-tune the desired 3d angles or to designate where animation parts fire on the applicable timeline, etc ?
actually this is currently handcoded calling the JS api of layerJS at specific time points. Let me know if you need this somewhere i can share the code.
I have started prototyping a similar UI concept on top of Vue.js
I'd like to ask you how did you manage to support all those JavaScript frameworks in one go?
It's still very possible for me to revert to vanilla js instead of getting locked into Vue.js
The way it is getting along with other frameworks is that makes as little asumptions as possible. So layerJS will only deal with divs that have the attribute "lj-type". The it will only show, animate or hide them. There are a few exceptions to this but that's basically it. So if another framework like vue modifies other elements on the page its free to do so. layerJS actually has a few mutation observers lurking around to see if the dimensions of frames or stages change to adapt the view accordingly. So that means that other frameworks can modify the DOM the way they want and layerJS will adapt. If there may be some hickups in special cases, please let us know so we can fix it.
basically layerJS will reparse if it detects a change rigth inside one of its objects. This works for example in a vuejs app we create. If the framework actually rebuilds the whole DOM hierarchy the layerJS parse would need to be triggered manually. Let me know if you get into this situation so we can tackle it.
I would have loved to try it, but it looks a bit too heavy (.js size, even minified is 30KB+, and looks like jquery is needed too?) foe my 197KB homepage, and I am actually working to trim off few dozen KBs by not depending on jquery slim.
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...
This looks pretty nice, I like the idea and the abstraction seems nice. Super annoying problem though: you're stealing my Mac's swipe to go back gesture on your entire page even where you have no swipe actions.
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.
That's a pitty because i think this explains the concept best. The "video" is indeed not a video. It's actually layerJS operating on a "dummy" website. We tested it on a few devices including iOS. Which device version are you using?
hmm, is it that you can't see the content when it enters the 3d view? It's weird safari seems to put the containing divs background color in front if the 3d animation. I'll try to hotfix that
Scrolling, specifically auto-scrolling, is broken due to the insistence that I should look at the top navigation bar no matter where I scroll on the page.
When I disabled JavaScript to get rid of the annoying navigation bar, the rest of the site stopped working.
https://github.com/layerJS/layerJS/blob/master/LICENSE
> Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software, including the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
> 1. The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
> 2. The Software must not be used in the code base of HTML editors or web builders. A HTML editor is a software (or hosted web application) that can be used by a third party (the user of the HTML editor) to create HTML documents that can be exported and used elsewhere. A web builder is a software (or hosted web application) that can be used by a third party (the user of the web builder) to create HTML documents that are hosted or dynamically generated under a top level domain chosen by the third party. The code base is the source code of the HTML editor or web builder, including the source code of publicly available plugins. No calls to layerJS can be made from the code base, but third party users can use layerJS in their websites that are built with these HTML editors or web builders.
> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> This license is derived from the MIT license (https://opensource.org/licenses/MIT)