201–210 of 236 posts
Why didn't we think of this sooner? Because we did! For instance, this is exactly the approach that we have released back in 2009 with http://opalang.org Naturally, there are things we would implement differently today, but the OCaml codebase of the compiler is still, in my humble and biased opinion, pretty valid.
The precompilation is a nice idea, but I'm not buying the "vanilla JS" argument. The reason why React and other frameworks have a runtime is also because they optimize rendering. The Svelte doc says: every call to `component.set()` produces a synchronous DOM update. I can already see how this leads to very poor rendering performance in applications with a large number of nested components. React and the Virtual DOM s…
We'll publish some benchmarks soon showing how much better Svelte's performance is than React's. There's a lot of misconceptions around virtual DOM diffing.
Earlier quoted context omitted.
Currently JS frontend folks also classify MVC as "problematic", yet a lot of successful software was written that way. So along with J2EE folks, this isn't really the community to look for style standards by default.
Honestly, given that I know of no two developers that have the same understanding of what MVC is and how the code should be divided, I have a feeling there's something wrong with the pattern itself, too.
Earlier quoted context omitted.
But the google closure compiler have no concept of a tree of components and their lifecycle. The library is old, java-like and I never heard about someone using it :p
Don't quote me on this but I'm pretty sure gmail uses it. I'd say that's a pretty big endorsement.
It IS old (well, 2009 counts as old I guess), but it's still maintained, and still doing what it says on the tin. That's quite an achievement in and of itself.
Love it. I think the most discussion-worthy quote I found in the docs is this: > It's currently fashionable to avoid two-way binding on the grounds that it creates all sorts of hard-to-debug problems and slows your application down, and that a one-way top-down data flow is 'easier to reason about'. This is in fact high grade nonsense. It's true that two-way binding done badly has all sorts of issues, and that very la…
My understanding is that there are two issues with two-way binding that are structural, and will be difficult to fix no matter how you approach it. First is that if you look at the system as a graph of updates, automatically closing all cycles between variable update and widget means that any additional two-way binding links you add become a cycle, which makes it difficult to implement, model, and debug. If the frame…
Love it. I think the most discussion-worthy quote I found in the docs is this: > It's currently fashionable to avoid two-way binding on the grounds that it creates all sorts of hard-to-debug problems and slows your application down, and that a one-way top-down data flow is 'easier to reason about'. This is in fact high grade nonsense. It's true that two-way binding done badly has all sorts of issues, and that very la…
My understanding is that there are two issues with two-way binding that are structural, and will be difficult to fix no matter how you approach it. First is that if you look at the system as a graph of updates, automatically closing all cycles between variable update and widget means that any additional two-way binding links you add become a cycle, which makes it difficult to implement, model, and debug. If the frame…
Why didn't we think of this sooner? Because we did! For instance, this is exactly the approach that we have released back in 2009 with http://opalang.org Naturally, there are things we would implement differently today, but the OCaml codebase of the compiler is still, in my humble and biased opinion, pretty valid.
is opa still alive and being used? i was pretty excited about it when it was released (especially when it still had the ML syntax), but it never seemed to gain any traction.
I can not keep up with all the new X flavored js frameworks, where X is [React, Angular, Vue, Mithril, Redux, Mobx,...]. This is exactly why I chose Clojurescript for my pet stuff and with hopes, that I will be able to use it for making money too. Learning curve can be steep for someone not used to functional way and/or lisp, but at the end you get a very mature, simpler and consistent language with great tooling. Fi…
I cannot keep up with random javasscript frameworks... therefore I use [random framework in some other language]...
Earlier quoted context omitted.
The Svelte compiler uses some ES2015 features (for...of, etc) that aren't currently supported in all browsers. It's designed primarily for use in Node.
Also doesn't work on Safari 9. Why not transpile the Svelte compiler to ES5 so it will run on all browsers? Otherwise devs may get the impression Svelte generated applications will not work on all browsers.