As far as I can tell the formatting is standard `rustfmt`. Ships with the compiler.
1,959 karma · joined May 10, 2009
This is a reasonable assumption given what I've described. It's been almost two years but from what I remember the problem was updating what should have been the same reactive binding in two different locations. When trying to debug a problem I was stepping through the code and noticed that the indicies passed to `$$invalidate` were different. Checked for typos and shadowed declarations and found none. Rolled back to checkout and found the indicies matched. In the process of undoing/redoing my conclusion was that the introduction of an unrelated reactive binding was the difference. I could have been wrong; I was pretty exhausted at that point.
> It sounds also like you’re fighting the framework.
Sure. In this case it was getting a big chunk of JSON back from an endpoint I didn't control and trying to use a number of reactive variables to select out pieces for display. I've done similar things in a half dozen other reactive/FRP libraries without issue but I assumed I was off the beaten path in Svelte.
I realize that this is empty complaining about other peoples' hard work. I don't have the code any more and I don't have a reproducible test case so I have no problem with anybody waving this off.
I was advocating/piloting a new framework in the app and was unhappy with the output versus the input and perceived complexity. I spend a significant fraction of my time cleaning up performance issues. A good chunk of that is download size so I care in general about what I'm sending across the wire.
> Also, your component sounds cumbersome.
Sure. It was the classic feature creep scenario.
This is fine but having spent a decade of my career doing this, I would never advocate for it in an app with any kind of frontend complexity or a chance to grow into it. The frameworks mostly obviate the need to understand layout thrashing, resource cleanup, and retained state conflicts in the DOM. If you're doing simple stuff these don't matter but they're challenging to fix and more challenging to stay fixed when a group is contributing.
> Svelte has caught my attention and I want to give it a go, but if the output is bloaty then that’s a red flag for me
Your use case is a pretty good fit for Svelte and you're likely to get output you'd find acceptable and given your preferences I think you're more likely to prefer its sensibilities over other frameworks that could provide the perf you're looking for. The tradeoff is kind of like the tradeoff between monomorphization vs virtual dispatch. The Svelte compiler is basically inlining the update code instead of using shared code in a runtime.
Svelte trades off runtime size for component size. It was created in the context of infographics for the New York Times online and for projects that roughly line up with that it's pretty much the technically best option.
I like the Svelte authoring experience and introduced it for a few components in a React based low-code platform. The reason I phased it out was a chat component that was ~600 LoC and 50-something reactive variables in a moderately complex chain blew up into ~5k LoC of output. I also ran into what seemed to be some transient invalidation issues. I was short on time to debug this and engage with the Svelte community so I rewrote it in React to match the rest of the system. It's possible I was doing something wrong but I don't have enough confidence to bet on 3.x again. I'll take another look when 4.x comes around.
> Presumably if Svelte were the be-all-end-all of front-end frameworks, it would dominate soon enough?
There's significant network effects around the established frameworks. Nobody gets fired for picking React. I personally think Solid is the best overall technically but the ecosystem and mindshare is smaller and that matters to a company making a business and not necessarily technical decision.
Most other frameworks here (all? not sure about Vue) will invalidate and rebuild an entire component subtree if a piece of state in them changes. The solid runtime doesn't care about components so changing a piece of state high in a subtree will only update the piece of the DOM directly depending on that state and not any nodes that were authored as sub-components.
Low cost has never been the priority. If you don't value their service at $20/yr they have no problem with you going elsewhere.
I'm white, male, beardless, and 40 and am almost always the youngest when showing up at a recumbent meetup.
A lot of the current crop of recumbent riders (in the US at least) got into it in the late 90s and early 2000s. As the boomer cohort aged out of riding two wheeled recumbents there was a significant drop in demand for recumbent bicycles and a corresponding increase in recumbent tricycle demand. The companies making fast/racing recumbents stopped due to lack of demand (basically just Performer and Bacchetta are left) so there aren't a lot of us left in the fast recumbent bicycle crowd and almost everybody is running a 10+ year old bicycle. I have a 2009 Optima Baron, for example. More casual recumbent bicycles like LWBs or crank forwards are still around and seem to be more popular in the midwest than on the coasts. I live in NYC and recumbents are particularly rare here due to the downsides of recumbents in the city, mostly sight lines in traffic. I've seen 6 in the wild in the last 8 years and I usually see 4 or 5 recumbent trikes on mass rides like the 5 Boro but all the trikes have been from out of town.
I personally would say no. I like Svelte's dev experience but I don't like the output code and while it has smaller invalidation subsections than a full component there's not a 1 to 1 mapping between a piece of data changed and the exact piece of DOM getting updated.
> Or has the approach of Svelte also drawbacks that I am not aware of?
Svelte is superb for producing NYT infographics and other relatively lightweight experiences. I work on interface builders and when you're scaling up the number of components on a page and the complexity then having the reactivity code repeated in the components instead of shared in a library becomes a drawback. What pushed me off of of Svelte was a ~500 loc component that had ~40 reactions and resulted in a 4.1k LoC js file output. I looked through the output and didn't see any particularly egregious mis-compilations, just that the Svelte's approach resulted in verbose outputs. I don't think most people will have components this complex so I don't think Svelte is a bad choice and I do like the DX but that caused me to move on.
Of the current options, I recommend Solid. It has fine grained reactivity all the way down, better perf, similar bundle size, and the community is generally performance obsessed. They're currently experimenting with islands/partial hydration/mixed server+client rendering and preliminary results are halving the delivered JS. As an example, their movies demo [1] is ~15k.
[1] https://github.com/unocss/unocss
If you mean build your own design system then I've built four separate design systems in SCSS since 2009. I've been fine with switching to Tailwind instead because I can get similar results customizing the theme, it's more comprehensive than my systems, and the network effect advantages of somethign popular vs my one-off thing.
It tends to be. The only (popular) JS framework where it's a first class concept is with Svelte. There's a basic set of transitions and the framework handles the post-out-transition removal (which is annoying in a lot of frameworks) but there's also custom CSS animations where a JS-defined curve is rendered into CSS [1], semi-automated FLIP animations for non-transitioning nodes [2], and deferred transitions where the outro of one element is sync'd with the intro of another [3]. There's a few other things like springs and whatnot but I consider the package as a whole to be a significant advancement in the state of the art.
[1] https://svelte.dev/tutorial/custom-css-transitions [2] https://svelte.dev/tutorial/animate [3] https://svelte.dev/tutorial/deferred-transitions
The only other framework I know of that's tackled it in core is Inferno but I haven't read through their implementation in detail.
It's normal to get much worse performance than React if you layout thrash and it's very easy to layout thrash without batched updates. There's overhead in the vdom but getting all the updates batched tends to be a performance win in any decent sized app. This was an active area of library exploration/development in the 2008-2012 timeframe but the only framework actively promoting it was Sencha IIRC.
Self-adjusting computation is probably the closest term for what I call cell libraries but the only time I've seen it used outside academia is when Jane St announced their cell library. My understanding is that the term covers a wider variety of techniques than the three or four common variations I've seen in cell libs. Incremental computing seems to cover an even wider subset.
Wasn't aware of reactive demand programming. My quick skim over the top search hits has the authors insisting that there's upstream parameter passing as part of their model. I've seen that done once in a toy/weekend project as well as true bidirectional computation in Kris Zyp's Alkali (by defining a transformation function each way) but usually the only "upstream" information I've seen in other cell libs is a demand for computation if it's pull based instead of push based. Also wasn't aware of "incremental DAG" but searching for that term doesn't turn up anything at all.
Datalog is only tangentially related in that it seems to pretty much always be implemented incrementally. I'm not an expert but I'm pretty sure it's still datalog if your implementation is stupid.
There's other related fields of computing: most incremental computations can be modeled as unidirectional constraint solutions, timely dataflow allows for incremental computation (including cycles) across distributed nodes, databases perform view maintenance, lens libraries can be implemented incrementally and chained to accomplish similar things.
The JS community is the most prolific author of the libs I'm talking about, mostly because the size of the community, the direct demand for it (incremental UI updates), and the relative ease of implementation. The most common term I've seen for it is "reactivity" or a "reactivity system", which I simply don't like.
Edit: It occurred to me that I didn't mention the obviously related spreadsheet engine in this response. I've only looked at a handful of spreadsheet implementations but none use the function + heap allocation per computation step pattern (i.e. cell) that cell libs use. Their use patterns have a lot more cells and generally less control flow so the focus is generally on arrays and unconditional updates.
If you do want to jump on the trend while keeping your Vue knowledge, check out Astro [1]. I'm provisionally in the Marko [2] camp, not so much for the current Marko but because Marko 6 is looking good.
Historically there's been a significant performance difference between the FRP set and cell libraries. I haven't kept up with Rx so I don't know if that still holds but cell libraries have substantially fewer constraints on their use cases so I expect it to. If a compiler is involved, cell libraries can get big wins by compiling the reactive updates to JS functions and getting boosted by the engine JIT.
Cell libraries have been around for a while. Knockout popularized them but I'm sure someone wrote one before that point. I glanced through the README and didn't see anything particularly novel about this implementation.
The area you're covering is closely related to an active area of development within the JS frontend framework community. They consider it hydration perf work and the working terminology is partial hydration or resumption/resuming rendering (there's a couple approaches/tradeoffs). In particular, the Marko team has a system under development that works this way without explicitly defined client/server pieces. They're mostly solving it on the server and streaming the HTML down since they have a priority on page load perf but the models look very close to me. I don't have a definitive piece to link as an intro and the concepts haven't made their way into the broader JS community but I thought you might be interested.
I'm happy that hyperfiddle is still going, I recall the Clojure NYC presentation and this is looking a lot more polished.
Astro, for example, is very conceptually close to PHP. Your code runs on the server, there's a code section where you grab content from the DB and a markup section where you template out the page, the lifetime of everything is one request, etc. What's changed is that you can put an attr on a component indicating you want that component sent to the client. No attr, it's old PHP, attr it's jQuery, and further the send can be triggered can be when the element enters the viewport or when it's clicked.
In the in-development Marko 6 runtime distinguishes between url/db derived "settled" data and client side/event handler state and only sends the latter to the client. If you have a paged list (for example) you can set up the prev/next page buttons to be links and you wouldn't have any JS sent down to the client despite the app being written with current SPA component ergonomics. If you'd rather have the data fetch and render client side you switch the data declaration from a const (dervied/settled) to a let (state) and all the rendering JS gets sent down.
I'm simplifying/omitting stuff but these are new and useful takes on old ideas. I think better takes on old ideas are some of the more effective advances in the state of the art.
For a decent fraction of applications a large chunk of the code that's written is to generate non-interactive parts of the app (data fetching, wrappers, component markup, CSS) and the actual code for event handling is relatively small. Hacker News, for example, is a pretty common framework demo since it's simple to write. You need a bit of JS on the comments page for the vote buttons and the comment collapse but if you write HN in a natural way in most component oriented frameworks the bundle coming down is considerably larger and includes all the code for rendering the comments (for example) even though the comments never change and most hydration approaches will put the comments in both the markup and embed a JSON/JS chunk in the page so hydration and the client side render can happen with consistent data. This doubles the size of the page with the overhead of the data half running through some subset of the JS code machinery.
In the case of Qwik, the idea is to do a server side render and then lazy load everything on the client as it's needed. At least that's my understanding, I haven't used the framework beyond a toy project. There are other approaches but to use the HN example, you'd never download the comment collapsing code if you didn't click a collapse button.
SpaceX doesn't catch anything at the moment.
The first stage lands itself either at the launch site or on the autonomous barge at sea.
The fairings for the second stage get pulled out of the ocean by ship after they splash down. They used to try to catch these and that's what you're thinking of but they weren't that successful at it. I believe they redesigned the fairings to be okay spending a short amount of time in salt water and they seem to be having a pretty good success rate for this.
The second stage of the Falcon burns up in the atmosphere. Their Starship project is attempting to fix this.
The advantage of this approach for Rocket Lab is that they'll be able to re-use the first stage. At the moment SpaceX is the only one doing that and it's why they have such a commanding position in the market. I haven't seen an explanation for why (I'm sure it's out there, I just haven't seen it) but my guess is that the Electron is a much smaller rocket than the Falcon and they can't spare the lift capacity to propulsively land the vehicle.
I could see an argument for that given the time/resources invested compared to the results but ULA's future and a large fraction of Project Kupier's planned launches are tied to the success of the BE-4 so they do have immediate ambitions beyond suborbital tourist hops.
I've been semi-tracking them because they're a local NYC Clojure shop and had wondered how they were handling the social network name overlap. Glad to hear they're still around.
[1] https://remix.run/ [2] https://github.com/BuilderIO/qwik [3] https://markojs.com/
Scheme itself means the same thing but it's fallen out of use and the only times I've encountered it is when the speaker wants to distance themself from it: get rich quick scheme, hare-brained scheme, nefarious scheme, malicious scheme, etc.