bind:group is explained in the docs (https://svelte.dev/tutorial/group-inputs). I don't think React would be particularly easy to grok without first having read its docs (or some kind of instructional material) either. Regarding the "magic," note that you can always inspect the generated Javascript, which is quite readable (particularly in dev mode). Given that the component code is largely self-contained (it does refer to some common shared helper functions), you might even find it easier to understand how Svelte is working than trying to follow whatever the React library is doing behind the scenes.
That's not what I mean when I say "magic". Magic, to me, is having some special string in your template which is going to invoke some arbitrary logic to get something "just working". In this example, note how `group` does different things depending on what kind of input you're dealing with. That's the kind of stuff that sounds great in a demo but quickly becomes a pain in a large application.
It's not about being able to learn a framework without reading the documentation, it's about how many distinct concepts you have to read the documentation for to use the framework. React is extremely conceptually light, by design, which is something I love about it.
bind:group is not a "special string" but simply part of the API, in the same way useEffect is part of the React API. bind:group is no more "magical" than useEffect (both are ultimately going to "invoke some arbitrary logic").
> In this example, note how `group` does different things depending on what kind of input you're dealing with. That's the kind of stuff that sounds great in a demo but quickly becomes a pain in a large application.
I really don't see how. It is relevant to exactly two kinds of inputs (radio and checkbox) and does exactly what you would expect with each (given the different behaviors of radio and checkbox inputs).
> It's not about being able to learn a framework without reading the documentation, it's about how many distinct concepts you have to read the documentation for to use the framework.
Sure, but looking at the right menu in the React documentation (https://reactjs.org/docs/getting-started.html), there are actually quite a lot of concepts and API details to understand in order to become proficient in writing React apps. I would be hard pressed to say that looks any lighter or simpler than Svelte (I would actually argue the opposite -- Svelte seems simpler and more straightforward).
> bind:group is not a "special string" but simply part of the API
Right, but the difference is in the API design. React gives you a small set of tools to implement whatever functionality you need. Svelte gives you specially-crafted tools which to handle specific scenarios. Svelte gives you a command to bind input groups to a stateful value, React gives you the tools to do it yourself. The difference is subtle but experience has lead me to vastly prefer the latter, mostly because you're less reliant on the framework designer getting everything "right".
I think React gives you more specially-crafted tools than you suggest and Svelte gives you fewer than you suggest. Even in this case, bind:group is just a shortcut -- Svelte also provides the tools to "do it yourself" if you need that ability in some special case (see https://svelte.dev/repl/3cffb15ef71f43b08872f72c527089a2?ver...).
I'm not sure you understood the article. The Svelte compiler does in fact generate code that performs "carefully crafted direct DOM mutations," though it is not hard to maintain, because the compiler handles it. Given code that already knows exactly which DOM updates to make, virtual DOM would indeed be pure overhead.
Typical React code does not know which updates to make. It always builds the Virtual DOM from scratch as is was the first time. It is the diff algorithm then figures out the set of changes.
If code knows which updates to make, it essentially embeds a particular form of the diff algorithm. That inevitably leads to more code to write as besides the initial construction of DOM one has to track changes. And such manual tracking is not necessary optimal as the diff algorithm has a global picture and can target the globally optimally set of mutations, while manual in-component tracking optimizes for a particular component.
> If code knows which updates to make, it essentially embeds a particular form of the diff algorithm.
Having an alternative means of identifying where to make targeted updates on data changes (i.e., via static analysis during a compilation step) is not the same thing as embedding "a particular form of the diff algorithm" (which would be a runtime operation). Svelte does not produce anything comparable to a diff algorithm.
> That inevitably leads to more code to write as besides the initial construction of DOM one has to track changes.
With Svelte, there is actually less code to write, as the compiler handles generation of the change tracking code. And even the generated code is minimal and generally leads to much smaller bundles, as no runtime gets shipped with the code. This leads to faster startup times, which is often the real performance bottleneck for SPAs.
> And such manual tracking is not necessary optimal as the diff algorithm has a global picture and can target the globally optimally set of mutations, while manual in-component tracking optimizes for a particular component.
Can you offer an example where a "globally optimal set of mutations" would be different from the set of mutations Svelte would make on a given change?
> Sure, you do a bit of it, and then you're often better doing something else, like enhancing developer experience for example.
Aside from its performance optimizations, arguably one of the biggest selling points of Svelte is its developer experience (which is enabled by it being a compiler). See https://svelte.dev/blog/svelte-3-rethinking-reactivity. And because only the features used in your components get included in the final bundle, the framework is free to add nice extras (like its transitions/animations system) without negatively impacting apps that don't need those extras.
> However, I've seen the types of transformations the Svelte compiler does and they tend to hide complexity, making it harder to trace and debug code at runtime.
Are you saying the original source code hides complexity that is present in the generated code? If so, I guess that's the whole point, but then a runtime framework also hides lots of complexity that your code doesn't have to manage (which, again, is the entire point of using a framework).
> It's much harder to debug code that doesn't resemble what you wrote in the first place.
With a runtime framework, there's lots of code running that isn't your code, which can also make debugging difficult. With Svelte, at least the generated code is fairly straightforward and easy to step through. In many case, I think it's actually easier, not harder to debug.
> There's a lot of what I'd consider to be non-trivial transformation going on between the code you pass to the Svelte compiler and what comes out of it and runs in the browser. Personally, I'm less comfortable with that compared to React's runtime library approach.
I initially had a similar concern, but so far, the opposite appears to be true. The Svelte compiled code is quite readable and easy to follow, and because there is no runtime, it's much easier to walk through exactly what is happening. With a complex runtime, it can sometimes be difficult to figure why something isn't working as expected without having a deep understanding of the runtime codebase.
> I'm saying that OP could do this without crapping all over React's contribution
What are some specific quotes from the article that you feel are "crapping all over React's contribution"? Genuinely curious, because I don't take the tone of the article that way at all.
> To readers considering Aurelia I would suggest trying Vue as well...
And if interested in Vue, check out Quasar [0], a UX framework for Vue (recently made compatible with Vue 2.0) that seems to have a lot of the same goals as Aurelia UX.
Use of the GPL doesn't merely prevent commercial developers from creating non-compatible formats -- it prevents them from using Concord at all. Let's say I want to build a commercial app that happens to use Concord, and I'm happy to use Concord as is (contributing back any patches or improvements I make) and even make the outlines exportable (assume outlining is just one feature in a much larger app, not the main focus). In that case, I'd have to make much or possibly all of the client-side code GPL compatible, so I can't use Concord, even though I'm not violating your rule about compatibility and am contributing back to the Concord community.
GPL seems like overkill given your goal. It will be limited to a niche of either fully open source public applications or completely private/internal applications.
