61–70 of 186 posts
It's an amazing reflection on the velocity of the web & JS ecosystem that React APIs prior to hooks, which were shipped all of 3 months ago, can be sincerely referred to now as 'classical' :-)
Earlier quoted context omitted.
Thanks Jeremy! As I've expressed elsewhere, observablehq.com provided important inspiration. I've also been influenced by your own comments in the past about a language for building web apps. It's exactly that — there's so much tooling in the JS ecosystem that we can lean on, and by inventing new syntax we'd be throwing all that away. It'd be great if we could do `prop answer = 42` and `a <= b`, but it's just not wor…
> I've also been influenced by your own comments in the past about a language for building web apps Hey Rich have you seen Imba? http://imba.io/ It's not reactive, but it doesn't need to since everything is memoized. I think it's interesting that they made their own language to solve the front end problem. They used it to build https://scrimba.com/ which is pretty awesome.
Memoization certainly makes Imba a lot faster than VDOM-based frameworks. Of course, it's only really beneficial when not many things have changed!
Congratulations on the launch, Rich! It's looking like we're really starting to approach the form and function of what "a language to build the web" ought to be. One small question about some of the pragmatic choices in Svelte 3: What was the decision process behind choosing to smuggle the new reactive features under a "standard" JavaScript skin? ($:, export let, etc.) Is it just to avoid needing to rewrite all exist…
Thanks Jeremy! As I've expressed elsewhere, observablehq.com provided important inspiration. I've also been influenced by your own comments in the past about a language for building web apps. It's exactly that — there's so much tooling in the JS ecosystem that we can lean on, and by inventing new syntax we'd be throwing all that away. It'd be great if we could do `prop answer = 42` and `a <= b`, but it's just not wor…
Your article says about `count += 1` that "we can do all this without the overhead and complexity of using proxies or accessors. It's just a variable."
But it's not just a variable; it's a magic variable that $$invalidates its contents. I'd be much happier to write `state.count += 1` and allow my debugger to step into the proxy in dev mode, but then have the production compiler convert the proxy into a direct call to $$invalidate to minimize runtime overhead and support legacy non-proxy browsers.
Their interactive tutorial with sandboxes is really impressive. That's a great onramp into actual usage. It might also be cool to have a good way to "eject" the sandbox into a functional local build.
So, Svelte is compiled into web assembly? If not, given the emitted imperative code is less efficient than emitted web assembly and the emitted imperative code is less concise than the original declarative code, then what would be the advantage of an imperative translation of the declarative Javascript code compared to emitted web assembly or the original?
One area where the virtual DOM seems to be important is for rich text editors, where the VDOM can basically take the input, diff it using an immutable structure, then render it to properly structured HTML. An example use case where this would be valuable: a user hightlights text, bolds it, then highlights it again plus some more text, and bolds it. A naive approach would have: This text is bolded plus I bolded this w…
A good editor would be standalone, with wrappers to make it callable from a framework of your choosing.
Most good rich editors implement their own internal Dom to achieve uniformity across browsers. DraftJs, Quill, Trix... use this strategy. There's nothing unique to react-Dom that benefits rich text editing
Earlier quoted context omitted.
Thanks Jeremy! As I've expressed elsewhere, observablehq.com provided important inspiration. I've also been influenced by your own comments in the past about a language for building web apps. It's exactly that — there's so much tooling in the JS ecosystem that we can lean on, and by inventing new syntax we'd be throwing all that away. It'd be great if we could do `prop answer = 42` and `a <= b`, but it's just not wor…
Can you say more about this? Your article says about `count += 1` that "we can do all this without the overhead and complexity of using proxies or accessors. It's just a variable." But it's not just a variable; it's a magic variable that $$invalidates its contents. I'd be much happier to write `state.count += 1` and allow my debugger to step into the proxy in dev mode, but then have the production compiler convert th…
You can easily debug reactive variables, either using the `{@debug ...}` tag in the template (https://svelte.dev/examples#debug) or by using `debugger` in your script tag (https://svelte.dev/repl?version=3.0.0&gist=adc35e969343aad60...).
This is really cool. That said, I noticed that it cites performance vs vdom as a selling point. Something I've been wondering lately is how big of an issue is UI performance for most web apps really? So many of the little apps and prototypes I develop aren't hurting for performance. It seems to me the industry made a huge leap from JQuery/Backbone/etc to reactive/vdom. But declarative UIs and virtual doms don't solve…
A frequent argument for the use of vdom has been that it reduces Dom trashing. I am willing to bet that if a vdom library has figured out what elements don't need updating, the browser's Dom implementation tuned over decades has that logic built-in. So go ahead and trash the Dom, but batch your updates and the browser's logic will likely not trash more than necessary. And since that logic is implemented in an AOT compiled language, it probably is much faster than a js v-dom