Re:
by rmorey on Wednesday July 12, 2023 @03:43PM
(#36700569)
I think technically, legally, it is the opposite. Works are automatically copyrighted upon creation, so without a license, by default it is not free to use. In practice, who cares, that’s why they put it on GitHub, just use it
This is correct. The work is "all rights reserved" unless explicitly stated otherwise.
This has even been applied to projects that began with no license, but added one later on. An original author on some open source software can come back years later and claim copyright over the first few commits, when no license was present. That's why it is important to START your project with a LICENSE, and why it is a default option when creating a repository on GitHub.
I think this would only apply in a situation where the original author stepped away from an unlicensed project that got forked or taken over, then the people forking it added an OS license (the original author could come back and license the original work under whatever terms they want)
If the original author added the license at some point in the future it would apply to the entire codebase at the time they added it, which they presumably hold the copyright for, so I don't think they could make the argument that some chunk of the codebase which existed at the time of licensing falls under a different license.
I suppose if an unlicensed project gets an early outside contributor, and then the original author adds a license, the outside contributor could claim they didn't consent to the license change (this is why many professional OS projects require contributors to sign a CLA)... but in practice I'm not sure how this would work, since this would mean the outside contributor forked and modified the unlicensed project, so they would have been potentially violating copyright in the first place
There are almost certainly going to be some exceptions, but copyright law is largely consistent in the broad brush strokes at least, among a large portion of the world's nations.
TIL. There are apparently more Berne Convention signatories than WTO members, though, so I guess the former still has more reach, but I assume the intersection isn't empty, so of course TRIPS must have had some impact as well.
I would describe it as closer to an alternative to hand rolling js, using JQuery, or older templating libraries like Knockout.
Where its at its best is with server rendered frameworks like Django, Laravel, or plane old hand rolled CGI. You can sprinkle in some Alpine with no build steps. It works particularly well with HTMX.
I wouldn't call it a React alternative because there are places where React (or Vue, or Svelt...) are better placed. But there are places they are overkill and it slots in perfectly.
Alpine borrows quite heavily from Vue, it has a very similar template DSL, and uses its reactivity subsystem (I personally think this is very well designed and makes Vue 3 an incredibly good app platform).
I also believe the new Laravel Livewire just released is built on top of Alpine, they are from the same developer.
If I'm doing server side rendering and need to sprinkle in some client side interactivity Alpine is what I reach for.
(You could describe any client side templating system as a React alternative)
When the button is clicked, the menu opens (or closes). x-transition adds a smooth fade effect, @click.outside hides the menu when clicked away from the element, and x-cloak prevents it from appearing before the DOM has fully loaded.
Those are just a few of the most common Alpine directives. It doesn’t try to do everything, just the basics simply and efficiently.
It's similar, but the syntax and behavior are more inspired by Vue.
It's great for embedding behavior into HTML elements, as others have said. I have found it be very flexible and powerful. And it doesn't require a build step, so you can just pop it into plain old HTML (after importing the script, of course).
This page looks really bad on my system- Firefox Nightly and a UWQHD display- The black circle occupies most of the screen (obscuring the text) and it animates very slowly.
The giant black circle only shows up when the viewport is very narrow, and when it's very wide (like full-width on my screen)- if I shrink the browser window to a medium width (which is likely how it was developed), the issue goes away.
Aaaaand the fact that it's not easy to automated-test things like this is why I'm mainly a back-end developer =)
This looks pretty good! Usually the first thing I check with libraries like this is basic (yet commonly missed) accessibility features, like trapping focus within a modal or typing to search through select options.
Modulo some browser compatibility bugs (keyboard navigation doesn't work with the select in Safari, for example) this seems better than almost every other "simple" UI library I see on here.
Very nice, but what's the upgrade story on these kind of things? Like if there's a bug in any of these, you've got to basically manually watch the repository and manually copy bug fixes back over
Re:
by jw1224 on Wednesday July 12, 2023 @05:42PM
(#36702088)
Each component is so simple, there’s no upgrading to be done. It’s just an handful of Alpine directives, most don’t include more than a line or two of JavaScript.
Just copy-paste into your project, tweak as needed, and that’s it.
I desperately want a good library like this but every time i do they have 3 additonal premium tiers that make the free content feel like something my project cant rely on.
I'm not GP, but I agree with them. I'm totally willing to pay (I bought Tailwind UI in fact) but if the license is restrictive in what I can do with it, I won't invest time/money into learning it. If I can't use it on an open source project I built (not a UI library of course) then it's unacceptable. If I can't use it on things I build for customers, it's unacceptable. It's not the money that is the problem for me with the premium offerings, it's the license terms.
To be clear, I'm speaking broadly in general terms. I'm not suggesting that Pines has this problem.
Yep, tailwind is pretty good on that front. I paid in part because they're fine with open sourcing and using for customer projects and such. I haven't used it as much as I thought, but overall a good investment.
> They do have a catch all, but for PR sake they probably won’t use that unless you’re clearly in the wrong.
If you're relying on PR then what's the point in the licence? This is a legal agreement - it should be scoped for intended meaning of the agreement, not relying on outside influences to decide how the company will choose to interpret it because those influences change over time.
The catch all here is "Use the Components and Templates to produce anything that may be deemed by Tailwind Labs Inc, in their sole and absolute discretion, to be competitive or in conflict with the business of Tailwind Labs Inc.". What happens if I use Tailwind to build a site designer service? For a while it'll be fine, but what happens if Tailwind (the company) bring out a site designer product, and now decide that I'm in competition? Is my whole business dead? There's no caveats in that clause on time limits, ordering, or in fact anything. It doesn't even have to be a close competitor due to the "sole and absolute discretion" wording.
I would absolutely be willing to pay under the right circumstances but I have a short fuse when it comes to licenses and component libraries.
When component libraries doesn't rely on anything proprietary, isn't complex, has convoluted/restrictive licenses, is expensive or a subscription and meanwhile could absolutely be done 100% open source, then of course I'd prefer that.
The whole point of these libraries is to make building products easier, but restrictive licenses & expensive pricing makes it feel like that won't be the case.
I’ve been using shadcn’s UI library lately and have been loving it. It’s distributed as a CLI that you use to vendor in pre-baked implementations of Radix UI components using Tailwind. Once they’re in your repo, you customize them as you want. Great for scaffolding a branded component library. React-only right now.
Surely, when you are writing little 150+ line js programs in your html attributes you have to start considering if Alpine.js is the right tool for the job.
From a brief scan, there's also a bunch of stuff in there that seems like it would be more straightforward as `data-` attributes, since you can easily use those as arbitrary selectors for Tailwind styling. I don't know if it's actually more efficient, but it sure seems easier to read to me than dynamically generating the class string based on state.
Re:
by mhitza on Wednesday July 12, 2023 @09:31PM
(#36704012)
That is ridiculous amount of javascript within an html attribute. Do all major editors/IDE have proper Alpine plugins in order to highlight autocomplete js code within those html attributes?
> Do all major editors/IDE have proper Alpine plugins
PyCharm doesn't seem to have one (I hope I'm wrong). That being said, it is possible to put the code into a proper <script> block. I personally only a trivial amount of code in html attributes such as checking a boolean value with `x-show`.
I’m not sure you could implement the same level of functionality in less JavaScript using React or even Svelte. So you’re talking more about the shape of the API than amount of code.
A sufficiently advanced precompiler can extract those JS programs into their own files and a sufficiently advanced IDE can allow you to write even a 1000 line JS program in an attribute with no problems.
Eh, you should still pull the code out even with IDE support. HTML gets hard to read fast as tag size grows, and the example OP linked to is ridiculously large.
Re:
by danjac on Thursday July 13, 2023 @01:55AM
(#36705485)
With Alpine if you start having anything bigger than a snippet you should pull the JS out into a component using Alpine.data()[1] which can live in a <script> tag or a JS module.
In particular, scan past the data in that example and you will see things like @keydown.down="if(selectOpen){ selectableItemActiveNext(); } else { selectOpen=true; } event.preventDefault();"
which tells you what is happening right there. So if you eliminate the data outside the component, as one should, I think it becomes a very nice readable interface.
You might also want to consider whether markup/HTML is the right tool for the job in the first place. Don't get me wrong - I'm as much of an SGML geek as it gets - but there's no point in using multiple serialization formats (HTML and CSS and JS) just for the sake of it when you're coding an "app" as opposed to writing a "doc" and the app ultimately needs JS, and not just for progressive enhancement anyway.
The creator of this - Tony - is a friend and really active member of the Laravel community. This project is so fun and I’ve already used it for a couple projects!
As someone who adores alpinejs and is just getting into LiveView, can you explain was this removal a preference to minimize or for an alternate syntax or is there an important reason, such as if there exist conflicts between LiveView and AlpineJS clobbering each other?
Yes and no. Yes because the classes remind you of bootstrap. No because you still cannot use it without Tailwind classes. Layouts and alignments and many other things still need Tailwind.
Re:
by cjboco on Thursday July 13, 2023 @01:53AM
(#36705475)
I just tried daisyUI for a current job and found it a little frustrating. Couldn’t figure out how to modify backdrop on a modal, is just one example. Wound up just using headlessUI, which is from the makers of Tailwind… and also free. Albeit, not as robust as DaisyUI.
I can agree that daisyUI works good as it is but can be a pain if you need to customize it a "little". I often write my own components if I have to make change to Daisy's. :)
Re:
by err4nt on Thursday July 13, 2023 @01:07PM
(#36712521)
And is invalid HTML. You can invent any attribute so long as it begins with 'data-', or you can define custom HTML elements with whatever custom attributes you want, but you aren't allowed to invent non-standard attributes for standard elements.
This has even been applied to projects that began with no license, but added one later on. An original author on some open source software can come back years later and claim copyright over the first few commits, when no license was present. That's why it is important to START your project with a LICENSE, and why it is a default option when creating a repository on GitHub.
If the original author added the license at some point in the future it would apply to the entire codebase at the time they added it, which they presumably hold the copyright for, so I don't think they could make the argument that some chunk of the codebase which existed at the time of licensing falls under a different license.
I suppose if an unlicensed project gets an early outside contributor, and then the original author adds a license, the outside contributor could claim they didn't consent to the license change (this is why many professional OS projects require contributors to sign a CLA)... but in practice I'm not sure how this would work, since this would mean the outside contributor forked and modified the unlicensed project, so they would have been potentially violating copyright in the first place
See:
https://copyrightresource.uw.edu/copyright-law/international...
https://en.wikipedia.org/wiki/Berne_Convention
I would describe it as closer to an alternative to hand rolling js, using JQuery, or older templating libraries like Knockout.
Where its at its best is with server rendered frameworks like Django, Laravel, or plane old hand rolled CGI. You can sprinkle in some Alpine with no build steps. It works particularly well with HTMX.
I wouldn't call it a React alternative because there are places where React (or Vue, or Svelt...) are better placed. But there are places they are overkill and it slots in perfectly.
Alpine borrows quite heavily from Vue, it has a very similar template DSL, and uses its reactivity subsystem (I personally think this is very well designed and makes Vue 3 an incredibly good app platform).
I also believe the new Laravel Livewire just released is built on top of Alpine, they are from the same developer.
If I'm doing server side rendering and need to sprinkle in some client side interactivity Alpine is what I reach for.
(You could describe any client side templating system as a React alternative)
You can turn any element into an “Alpine component” simply by adding the x-data attribute.
Imagine a drop-down menu like so:
Without JS, everything would be visible at all times.You’d make this reactive with Alpine like this:
When the button is clicked, the menu opens (or closes). x-transition adds a smooth fade effect, @click.outside hides the menu when clicked away from the element, and x-cloak prevents it from appearing before the DOM has fully loaded.Those are just a few of the most common Alpine directives. It doesn’t try to do everything, just the basics simply and efficiently.
I use it for most projects now.
It's great for embedding behavior into HTML elements, as others have said. I have found it be very flexible and powerful. And it doesn't require a build step, so you can just pop it into plain old HTML (after importing the script, of course).
The giant black circle only shows up when the viewport is very narrow, and when it's very wide (like full-width on my screen)- if I shrink the browser window to a medium width (which is likely how it was developed), the issue goes away.
Aaaaand the fact that it's not easy to automated-test things like this is why I'm mainly a back-end developer =)
Modulo some browser compatibility bugs (keyboard navigation doesn't work with the select in Safari, for example) this seems better than almost every other "simple" UI library I see on here.
https://tailwindui.com
I really love this integration and would 100% use this if there's an ergonomic way of handing non-js users gracefully
Just copy-paste into your project, tweak as needed, and that’s it.
Also, as far as I can see the, library shared here is completely free.
To be clear, I'm speaking broadly in general terms. I'm not suggesting that Pines has this problem.
https://tailwindui.com/license
They do have a catch all, but for PR sake they probably won’t use that unless you’re clearly in the wrong.
If you're relying on PR then what's the point in the licence? This is a legal agreement - it should be scoped for intended meaning of the agreement, not relying on outside influences to decide how the company will choose to interpret it because those influences change over time.
The catch all here is "Use the Components and Templates to produce anything that may be deemed by Tailwind Labs Inc, in their sole and absolute discretion, to be competitive or in conflict with the business of Tailwind Labs Inc.". What happens if I use Tailwind to build a site designer service? For a while it'll be fine, but what happens if Tailwind (the company) bring out a site designer product, and now decide that I'm in competition? Is my whole business dead? There's no caveats in that clause on time limits, ordering, or in fact anything. It doesn't even have to be a close competitor due to the "sole and absolute discretion" wording.
When component libraries doesn't rely on anything proprietary, isn't complex, has convoluted/restrictive licenses, is expensive or a subscription and meanwhile could absolutely be done 100% open source, then of course I'd prefer that.
The whole point of these libraries is to make building products easier, but restrictive licenses & expensive pricing makes it feel like that won't be the case.
It doesn't have the long tail of components because they're CSS (via tailwind)-only, but it gives a great foundation.
https://ui.shadcn.com/
https://devdojo.com/pines/docs/select
document.addEventListener('alpine:init', () => { Alpine.data('video', () => ({ 'show_video': false, ...
That way there's code highlighting and syntax checking for JS.
I definitely go this route for Alpine about half the time.
PyCharm doesn't seem to have one (I hope I'm wrong). That being said, it is possible to put the code into a proper <script> block. I personally only a trivial amount of code in html attributes such as checking a boolean value with `x-show`.
HTML attributes are fine, 150+ line JS programs are fine, 150+ lines crammed into your HTML attributes is not fine.
A sufficiently advanced precompiler can extract those JS programs into their own files and a sufficiently advanced IDE can allow you to write even a 1000 line JS program in an attribute with no problems.
Yet, those do not exist today.
[1] https://alpinejs.dev/globals/alpine-data
which tells you what is happening right there. So if you eliminate the data outside the component, as one should, I think it becomes a very nice readable interface.
[1] https://github.com/Q42/LiveJS
[2] https://hexdocs.pm/phoenix_live_view/Phoenix.LiveView.JS.htm...
[3] https://www.npmjs.com/package/phoenix_live_view
(It is JS free, so limitations apply)
The dropdown example
It would also totally collide with Vue's template syntax.Compatibility with Vue wouldn't make sense as a goal for a competitive JS framework.