> it’s not an angle of HCI I’ve examined explicitly, at least for very long
If you're looking for additional reading then it's arguable that Reacts matches this viewpoint but any web framework from the past few years using signals (re-popularized by Solid) is explicitly this approach. Most frameworks don't opt for graphical node editors and I've never liked the approach but I've seen a number of those as well.
More generally this falls into dataflow programming which has had a number of published papers starting in the late 80s I believe.
If you're looking for a similar computer sciency approach to UI structure you can look up statecharts which is an older idea that formed the conceptual basis for Ember Router and, in turn, most js framework routers in the past decade.
No. Signals work with a weak map of references, not a graph. So in my Pizza example, when pizza changes, totalPrice would recalculate twice: once on a signal from pizza, once on a signal from tip. Explicitly constructing the graph dramatically reduces needless recalculation in bigger systems.
Rivendell, Velo Orange, Rene Hearse and I'm sure I'm forgetting someone else in that group more or less do this.
I'm nowhere near an expert but I think most small (or steel) bike brands never moved off english threaded bottom brackets so I think that's mostly a major manufacturer issue. The brakes are frame dependent but calpier and cantilever arms are fairly simple/available or flatmount if discs (ignoring that Shimano just kind of decided they didn't like post mount). Finally, if you're comfortable with (ratcheted) friction shifting then most drivetrain compatibility issues are covered.
The components themselves tend to be pricier since they're targeting a niche market but there are people serving it.
I just purchased a kit to convert the 10/11 speed SRAM brifters to 12 speed from Ratio in the UK [0], and there is a set of instructions in the community for turning the front shifter into a dropper lever.
I love how much people hack this stuff to overcome corporate shenanigans!
I love Rene Herse stuff (tires mostly), but ... they're niche of niche.
(Seriously, the complete bikes they sold are literally more expensive than any car I've ever bought. Not that I wouldn't like one, they're even roughly the style of bike I like, but I wouldn't use one enough to justify it. Their parts though, they're heirloom quality solid performance.)
There's a ton of custom and semi custom manufacturers out there of parts and frames, some of which are even affordable. A quick perusal of the Radavist will give pointers galore. Some of them even do production runs to make frame prices under 2k.
Personally, I like the look of the Crust Lightning bolt, but it's seriously pricey to import to the EU, so maybe something more like the Brother Mr. Wooden is next in line for me.
To be clear, I was intending my post to be exclusively about components. I was assuming people would get their preferred niche frames to put them on.
If I'm going to pick a fancy niche frame I don't want to afford I'd opt for a Jones LWB space frame. I'm actually a recumbent rider so the more likely expensive cycling purchase would be a velomobile.
> maybe someone can shed some light into the downsides of Svelte
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.
> I also ran into what seemed to be some transient invalidation issues.
It sounds to me like you didn’t understand the details of Svelte’s reactivity model, which are very important, and fairly straightforward to learn, but different from what people are commonly used to—and so even if you theoretically learn the model, it may take time in more complex cases for it to come naturally. The crux of these sorts of problems tends to be that reactivity is a property of bindings, not data; and as a secondary effect, mutation is therefore rather hazardous.
> 50-something reactive variables in a moderately complex chain
It sounds also like you’re fighting the framework. I’ve seen stuff like what you describe in some React libraries (e.g. mirroring something DOMmy in React—common, but I hate it because it’s so much mindless duplication, among other faults), but in Svelte at this scale you’re likely to get better results from seeing if you can bag things together (e.g. let x = {a, b, c} rather than let a, b, c), or passing through components rather than reactive variables. But these are vague concepts which may not actually be relevant or applicable.
Svelte is a framework that definitely requires that you work with it, or you’ll have a miserable time, whereas with React you can, to a much greater extent, do awful things and get away with it.
And when you speak of 3.x and 4.x and such—there’s basically no chance any of this stuff will ever change in Svelte, it’s too fundamental. In some cases you might end up with better compiler warnings, but that’ll likely be the extent of it.
> It sounds to me like you didn’t understand the details of Svelte’s reactivity model
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’m mainly a C++ developer, not a frontend developer (though I dabble), and when I have a choice of multiple approaches the first thing I do is go to godbolt.org, implement MWEs and compare the assembly.
I also do a lot of code generation, and my absolute goal is to have it write code that I’d write if I were doing it by hand. That’s pretty key for me. If the output is better, then good. If the output is doing a bunch of stuff it doesn’t need to be doing because it’s taking my specific use case and making it conform with its own model for doing generic things, I don’t like it.
I was a web developer back when tables for layout, HTML attribute soup for styling, and applets for interactivity were going out of fashion. Semantic HTML and CSS for layout and styling and JS for interactivity were coming into fashion. Divs for layout, class soup for styling, and JS frameworks for interactivity hadn’t yet become mainstream when I stopped.
So my default is lean HTML, lean CSS, raw JS. Maybe JQuery if needs be. It’s an outdated default, but it’s mine. The thing is, I get great load times and performance for what I need. What I need is normal dashboard stuff - though because of the nature of the field I work in, it condenses a lot of information onto a page and that information is updating many times per second.
I don’t seem to get enough performance from the frontend frameworks I’ve tried. I don’t know if it comes from code bloat, or deep call stacks through god knows how many levels of indirection, the way DOM updates are issued, or something else - but it has just never seemed worth the learning curve to end up with something I can’t do myself with admittedly a lot of work.
As such, I find this review helpful. 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. If it’s bloaty because it isn’t doing backflips through the call stack, but is inlining code - that’s familiar territory and certainly something I can deal with.
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.
Because the article makes it sound like your application code will be smaller because you don't need to ship the change detection library/framework.
But in a big enough application, the explicit change detection code added by the compiler adds up to more lines of code than most frameworks.
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.
Solid works differently in that the output is implemented as a side effect of a subscription to a piece of state. Simplified, think of a signal as an event emitter and a variable with a getter and a setter. Using the getter adds its downstream effects–most notably adding/modifying DOM nodes–as an event listener. Using the setter updates the state and triggers the event listeners.
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.
I worked for Squarespace 2010-2012 and the focus from management was mainly on keeping customers happy. It's not like it's ad focused and there's a need to extract maximum value from the userbase. It's possible that's changed in the last decade but Anthony (CEO) was really into having a premium product and a quick glance at the about page shows that most of the senior leadership hasn't changed so I don't see why they'd change direction.
going public and focusing on building a "platform" has definitely changed sqsp, although i wouldn't say they don't care about the customer experience anymore.
This comes up all the time when registrars come up...
"I just want a non-scummy registrar that doesn't try and upsell me, has support when I need it, and generally isn't shit."
"Why is this non-shitty registrar $20/yr instead of $10/yr like everyone else! Hell, I can go to Joe's Discount Domain Emporium and get this for _$8_!"
I guess I'd just really like to know, for the people that are looking at it like this... how many domains y'all buying? Because I have to assume it's "lots and lots" or else I don't know how to make sense of any of this.
The $10 difference literally couldn't get me a Big Mac meal these days. Maybe I'm just the super-privileged class to be able to afford an extra 83 cents a month, but I happily pay more for my domains to buy from non-scummy companies.
I pay AWS $13/yr when I could be paying... well, I can't even easily figure out what I'm spending elsewhere.
Godaddy is telling me $0.01 if I register three years up front, and it looks like year two and beyond are $23/yr? But if I bundle this with my other couple domains I get some sort of discount? Also they add the ICAAN fees and stuff after? So something like $16/yr over three years?
Domains.com looks like $10.99/yr once I managed to strip out the upsells.
Namecheap is telling me $6.98/yr with promo code FLASHCOM and I _think_ $13.98/yr after that?
Hover is still playing games but at least it's kind of clear--$14.99/yr up front, $16.99/yr after that.
Name.com is $10.99/yr, $12.99 renewal and they're pushing me to some sort of bundle discounts.
Spaceship is $7.88/yr, and I _think_ $8.80/yr on renewals?
Just trying to figure out the damn pricing on these sites is already stressing me out more than the loss of potentially around $6/yr.
Add to that that AWS isn't really a "registrar", they're a cloud company that lets you register domains. Their support isn't budgeted on the revenue from domain sales, it's budgeted on the $80b in cloud revenue. I've dealt with them before. They're excellent. AWS also has a pretty solid track record of supporting their products long term (SimpleDB is still here) so I have zero concern about waking up tomorrow and finding out that my registrar is shutting down.
My domain is what my entire online identity is tied to (via email). It sits between me and a bunch of (self-hosted) services I rely on. Even without the frustrating pricing and stuff, the $6 is worth it as insurance.
So no, I'm not overpaying. I'm paying a small premium for a product with a better process and better support and me not having to waste valuable brain space thinking about it or staying on top of whatever the hell my pricing is doing this year (though I guess I kinda messed that up getting into this conversation). If it weren't AWS, I'd have no problem paying Gandi $17/yr or Squarespace $20/yr.
Having a premium web hosting and web building service is great. Squarespace makes nice looking pages. But they are offering nothing special for the $20 premium for domain hosting. And really there is nothing to offer. Their DNS management UI is worse than Google's, and Google's is nothing special. I'm already in the process of moving domains - I don't want to be around for the transition.
As a longtime Reddit user, I immediately disliked the redesign but since I've been on the other side I decided it give it a month. I now deliberately dislike the redesign. I get most of my value out of reddit in the text subreddits and the conversation view in the redesign is awful. Things are highly collapsed and following a conversation requires repeated expansions. The comment count without loading more is extremely limited and when you scroll down there's an interstitial callout about the subreddit's all time popular posts. The redesign is fine for top level content in the picture/video/meme subreddits. Content emphasis aside, it feels incredibly slow. Waterfall loading and 2-300ms response times. I've spent quite a bit of time reflecting on design decisions and I think the design brief/product vision is simply opposed to my interests. I feel bad about complaining about another team's work but my complaints aren't the knee-jerk reaction you're complaining about.
- It inserts "ads" for other Reddit posts in the middle of a comment section. If you're not paying very close attention, it's easy to miss that you're literally not seeing all the comments on a post, because you have to scroll down past the "recommended reading" or whatever they call it and expand the comments below the fold.
- it often makes it impossible to see NSFW content on mobile websites without using the app, which is annoying if you click through from a Google search result on your phone. This applies to text posts too, which is all the more annoying because despite the name, the NSFW tag is used to tag more than just porn (hide spoilers for TV shows, punchlines of jokes, etc.)
I personally think reddit is an example of an actual bad redesign, so I'm not saying this is true for all redesigns. I do however think it was true for Fark, at least from how I remember it.
With that said, I don't think old.reddit is that good either unless you only want to read text-only posts, and it's pretty much unusable on mobile.
> With that said, I don't think old.reddit is that good either unless you only want to read text-only posts, and it's pretty much unusable on mobile.
Old Reddit is nearly unusable on mobile, but it's still better than the new Reddit on mobile, which is... actually quite impressive (and not in a good way).
> The average Recumbentist is a White Male, Typically with a beard >50 years old, 30% are overweigth, 30% are average build, 30% look semi/more-fit, 10% are female.
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.
> Is Svelte and in extension SvelteKit somehow the next step in the evolution of frontend frameworks?
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.
I've been laughing about this for years. I showed it to my graphic designer in 2014. She was delighted and did a small t-shirt run so I have the face on page 23 center row far right printed on a shirt.
If you're looking for additional reading then it's arguable that Reacts matches this viewpoint but any web framework from the past few years using signals (re-popularized by Solid) is explicitly this approach. Most frameworks don't opt for graphical node editors and I've never liked the approach but I've seen a number of those as well.
More generally this falls into dataflow programming which has had a number of published papers starting in the late 80s I believe.
If you're looking for a similar computer sciency approach to UI structure you can look up statecharts which is an older idea that formed the conceptual basis for Ember Router and, in turn, most js framework routers in the past decade.