Commercial javascript libraries have a tough stance. "Free for non-commercial" is essentially meaningless, since there is no clear definition of commercial use. For me, I wouldn't even consider including such a library into any software (OS or commercial) which runs on multiple domains/servers/computers, because it makes licensing and scaling less flexible.
To justify a licensing price, a javascript library needs to offer huge, peerless, hard to imitate functionality, stable code base, rapid bug-fixing and preferably a paid team working on it.
Which isn't to say that nobody will buy it. At $99 per site even one or two dozens of customers would cover the development costs.
I think you're underestimating the development costs for a commercial Javascript project which offers "huge, peerless, hard to imitate functionality, stable code base, rapid bug-fixing and preferably a paid team working on it.".
This isn't good. Developers should have a way to make a quick buck in the web space as well, and not just by selling Wordpress themes.
Sandstorm.io could provide a way, but I wish we had alternatives.
I disagree. 99 is a very reasonable price. I pay much more for IDEs, tools, libraries, services, support, and infrastructure. 99 is a reasonable one-time cost, all things considered (assuming it works on all modern browsers and mobile).
It is hard to justify unless you know you need it. IDEs get used on multiple projects. This license is per site. IDEs often have some kind of trial or at least you got to play with it on your friend's computer first. But "commercial use" could include testing it in your commercial application.
I prefer licenses that are based on how much something gets used. So, free if your site has small traffic or maybe free if the number of developers using it is small. That lets me use it in experimental projects or personal side projects (which may or may not make money and hence may be commercial) but not have to pay until the project grows large enough to be worth buying something like this.
I think the only library I've ever bought for a web project was $30 for a site license. It was when I worked at a company and multiple projects were going to use it and run from the same domain.
As someone who has worked at a job where spending $40 on an IDE was a big a deal, I can see where you're coming from. My current job doesn't bat an eye unless it's over $1000, so I know it's all relative.
I actually didn't say that $99 is unreasonable. I'm just saying that I would see the effort involved in adhering to this license in a commercial or open source project wouldn't be justified by the functionality.
In this licensing model, it is far from certain that the library will continue to be developed and supported.
I do understand that buying code can be a very good choice. But the decision isn't just "purchase price" vs "features".
It would seem to me that charging for premium support for libraries would be far more effective than charging for a license. You don't want to do anything to limit its wider use lest it be supplanted by a more widely available library that has a less restrictive license. But it's always painful to get support for very popular libraries, so that pain can be monetized quite easily. This also has the added benefit of locking people into using your library. They can either pay cash for premium support, or they can pay the tax of switching to a different library.
$99 isn't the full price. It's $99 for every installation, in a commercial application. For an open source application it means tracking the license and making sure every user of the application pays the $99 if he hosts the application publicly.
Also you still have to support the code yourself, even if you buy it.
I'm not saying that this is completely unreasonable. What I am saying is that small javascript libraries are a very tough sell.
I've not looked in detail, but I'm not so sure about the security of generating windows via URL parameters. I feel like there's an XSS in that for sure.
good point. What it passes via URL parameter is URL encoded JSON - which is parsed using JSON.parse()... so shouldn't expose an attack vector.
The alternative - creating about:blank windows and moving DOM elements into them comes with a wealth of glitches and restrictions
I realise that, but unless every piece of information in the JSON is dealt with caution (which I doubt from experience) it could be possible to put together an attack. Well, I should probably verify that myself.
Wow...impressive. Even though this is not so much a weakness o f Goldenlayout as rather the particular image component I use on the startpage. Still though, thanks. Remind me to hire you if I want to get back at someone.
Usually I work to prevent problems rather than create them but hey I could be the antagonist in someone's novel. I doubt that's not the only exploit in the library either. I could go through it with a finer toothed comb if you wanted.
I'd be forever grateful. I imagine this one to be quite tough since it's ultimately up to the user to create and read serializable state objects for their components.
I am always interested to see ways that people apply different layout ideas to code.
The Golden Section is a number considered to produce the most aesthetically pleasing ratios of things. A playing card's dimensions are usually roughly the same ratio: 1:1.618
For the past few hundred years print designers have been aware of the Golden Section and have been working it into their page sizes and margins - so wether it's beautiful and that's why we use it, or we use it and that's why it's beautiful - there's no question that we are familiar with seeing this design tool be used in print.
This looks like a library to help integrate some of those layout ideals into your code in ways that would be tricky or cost a lot of time to implement otherwise.
The golden ratio is not particularly magic in aesthetic pleasure; playing cards are in fact made with a ratio of 7:5, being 3.5" high and 2.5" wide. You get closer with bridge cards (a 1.555...) and index cards (1.666..). If you don't believe me, go out and try to buy picture frames for 5" x 8" or 8" x 13" or 13" x 21". They're just not a common ratio. You might as well say that the square root of 2 is aesthetically magical. (It actually is practically magical, as the European paper sizes point out.)
What's cool about the golden ratio is that it's the most irrational number by a couple of interesting heuristics, having come from one of the simplest recursive processes you can think of and therefore having the simplest continued fraction.
Transforming the definition of a golden rectangle into a process to "goldenize" a rectangle by adding a square to one side and rotating by 90 degrees leads to `goldenize (w, h) = (h + w, w), which implements the Fibonacci recursion rule. In turn if you "lift" the subscripts in that rule into superscripts F^n = F^{n - 1} + F^{n - 2}, you get a quadratic for F and if you solve it, you get the golden means F = φ and F = -1/φ.
You can also see this recursion at work in pentagrams: if you work out the three angles at the vertex of the outer pentagon, it turns out they're all the same angle (36 degrees, 180/5). If you then look at the side lengths in the top part of the pentagram, this fact lets you infer that the sideways-pointing triangles are isosceles (36-72-72) and combined with the 36-36-108 isosceles triangle you can derive the golden ratio again.
Those things about it are aesthetically pleasing; but I don't find that people unconsciously choose ratios of Fibonaccis as their perfect rectangles moreso than, say, 4x3 rectangles.
A 1:1.618 ratio has some geometric properties that are useful in rare situations, but the idea that it is "aesthetically pleasing" is completely unfounded.
We built something like this for our online 3D modeling/publishing/rendering tool: https://Clara.io
I was just looking if it makes sense to adopt, but our needs are pretty customized compared to what is offered here. But a lot of it is similar. Maybe if we were starting over, this would make sense and we could have adopted it.
Q: Can I apply a Creative Commons license to software?
A: We recommend against using Creative Commons licenses for software. Instead, we strongly encourage you to use one of the very good software licenses which are already available. We recommend considering licenses made available by the Free Software Foundation or listed as “open source” by the Open Source Initiative.
I suppose that is true, but most devs that want to do that just offer a dual license. GPL license, but you can purchase commercial license to remove GPL restrictions.
Interesting. Would you happen to know if there any downsides or upsides to either? To be completely honest, I looked at under which model HighCharts operates and did a similar thing.
It's probable that HighCharts chose CC BY-NC because there has not been a clear legal consensus (much less any sort of case law) on whether proprietary/minified Javascript linking to a GPL'd Javascript library is in violation of the GPL. If you want to prevent that type of use of your library without people paying for a license, then CC BY-NC might be a viable choice.
However, note that, say, an MIT licensed or BSD licensed or Apache licensed project, developed for noncommercial use, would be prevented from using your library for their layout, because then the non-commercialness of the CC BY-NC could "infect" their project and prevent them from using those licenses. For instance, the Highcharts license caused this project to switch to a competing library altogether: https://github.com/sebastianbergmann/php-code-coverage/issue...
In general, there's no good solution, but I personally shy away from CC-licensed code.
(I am not a lawyer, and this should not be construed as legal advice.)
just that the GPL is meant for code and CC isn't so it has special considerations in it that aren't in CC. CC is meant for media like images, video and text.
Statements like the "ultimate JS layout manager" just sound hyperbolic. This wouldn't be appropriate for the vast majority of web sites in the world, so I'm not sure how it's the ultimate anything.
I've been looking into libraries that do exactly this in the last couple weeks, thank you for sharing this one. The competitors in this space (that I have found) are wcDocker[1] and DockSpawn[2]. One "feature" lacking from GoldenLayout: you aren't hosting your code on Github, or in a way that can be utilized by Bower[3]. GoldenLayout looks like an otherwise better library than the others, could you talk about why or why not for Github hosting?
In the "getting started", you should put the .js and .css files somewhere so the examples work. I copypasted all your codelines just to be dissappointed that it doesnt not work. I understand you probably don't want to be a cdn. But for testing purposes, I cannot be assed to copy stuff over to my server. I prefixed them with https://golden-layout.com/assets/ and it nicely worked. Nice. Bookmarked.
Thanks . It’s easy to turn pretty much every feature off individually.
Just setting ‘hasHeaders’ and ‘reorderEnabled’ to false for example is effectively enough to switch off any user interaction whilst keeping the component lifecycle and resize behaviour when the phone is tilted.
Looks nice, but one recommendation: when you are moving a window, make the drop box cover the window bar as well. Also, the resize bars can cover the window bar to the point that if there is no content you cant click on the name because all you get is the resize action. Lastly, I somehow dropped a window to vertically split another one and it lost all of its content. I tried to resize the bottom border down but it wont move.
I'm simply wondering - how in general html/js applications would work with multiple monitors.
A typical set-up at work (game studio) is 2-3 monitors for artists/level builders. We had to write a new docking system for Qt5, since the existing did not allow to dock outside windows to others (or tab in them) - e.g. bit like Visual Studio docking (but not there yet)
I'm working on a project that's big into this. I extended dockspawn to support popout windows and give a breakout editor feel.
The window you popout can still communicate with its opener until you refresh or navigate away from that page. It's not ideal, but it's the best you can do without using something like signalr or sockets.io to join everything together.
The "open in new window" icon looks misleadingly like "restore original size" on Windows. Also, once you do, closing the popup removes the component altogether. You actually need to click the icon in the right bottom corner (why there??) so that it returns back to the original layout.
This would be easy to do with IE8+. They should have went for IE6+, support older browsers, they might have got those juice enterprise customers that throw $10,000 of dollars away on software. Also why is it so slow?
Nobody should waste time and money supporting IE6. It's completely unsupported by Microsoft. Those big enterprise customers should have upgraded in April at the absolute latest when XP hit EOL. Even IE8 only has a year left.
When I maximized and then restored, it put the section in a popup window and removed it from the original layout. I would have expected restore to dock the section back in the original layout as before.
Wow. Vida.io looks really promising.
I can't promise a schedule, but I'll try to add a MeteorJs tutorial as soon as possible.
Generally though it's just DOM elements that you put stuff into, so it should be compatible with pretty much anything.
Cheers. Good question about the load time. The library itself is 50k - without gZipping. But the demo on the startpage also includes Highcharts and SlickGrid and all their dependencies...and the examples are in Codepens - which take a while to load
To justify a licensing price, a javascript library needs to offer huge, peerless, hard to imitate functionality, stable code base, rapid bug-fixing and preferably a paid team working on it.
Which isn't to say that nobody will buy it. At $99 per site even one or two dozens of customers would cover the development costs.