It's true that in the demo video, it's only called out that a third party dependency was removed from the client bundle. And it's true that these types of "infra" dependencies don't make up a large % of your codebase to begin with.
But there's another angle to consider. In thick client apps, product code (everything else) tends to take up the majority of the size of the client bundle. There's a real opportunity here to move some of that into Server Components which would help reduce that footprint significantly. For example consider the case of deeply wrapped components that ultimately render to a single <div>. Server Components could help remove that abstraction tax.
Netflix | Senior Frontend Engineer | Los Gatos, CA | ONSITE, FULL TIME | We pay top of market
How do you spark joy in hundreds of millions of people? It starts with a vision—that technology can give voice to stories around the world. Netflix empowers a small band of creatives to do what no studio has ever done—tell hundreds of stories you fall in love with and stay up watching.
As an engineer on the Studio Engineering team, you’ll help us reinvent the way TV and movies are made on a global scale. If you have an eye for software design, a mind for asking questions and synthesizing information into actionable work, and the personality to want to learn from AND teach your teammates - we would like to talk to you.
Our culture is unique. It's not for everyone, but if it sounds like you, and describes the people you want to work with, you'll thrive at Netflix. https://jobs.netflix.com/culture
Netflix | Senior Software Engineer | Los Gatos, CA | ONSITE, FULL TIME | We pay top of market
How do you spark joy in hundreds of millions of people? It starts with a vision—that technology can give voice to stories around the world. Netflix empowers a small band of creatives to do what no studio has ever done—tell hundreds of stories you fall in love with and stay up watching.
As an engineer on the Studio Engineering team, you’ll help us build the future of how Netflix will create and produce shows on a global scale. If you have an eye for software design, a mind for asking questions and synthesizing information into actionable work, and the personality to want to learn from AND teach your teammates - we would like to talk to you.
Our culture is unique. It's not for everyone, but if it sounds like you, and describes the people you want to work with, you'll thrive at Netflix. https://jobs.netflix.com/culture
* Senior Rubyist/Polyglot with experience in building reliable, data-intensive applications in a microservices context - https://jobs.netflix.com/jobs/864653
Reach out to me directly if you have questions - laurent (@) netflix.com
Netflix | Senior Software Engineer | Los Gatos, CA | ONSITE, FULL TIME | We pay top of market
How do you spark joy in hundreds of millions of people? It starts with a vision—that technology can give voice to stories around the world. Netflix empowers a small band of creatives to do what no studio has ever done—tell hundreds of stories you fall in love with and stay up watching.
As an engineer on the Studio Engineering team, you’ll help us build the future of how Netflix will create and produce shows on a global scale. If you have an eye for software design, a mind for asking questions and synthesizing information into actionable work, and the personality to want to learn from AND teach your teammates - we would like to talk to you.
Our culture is unique. It's not for everyone, but if it sounds like you, and describes the people you want to work with,
you'll thrive at Netflix. https://jobs.netflix.com/culture
* Senior Rubyist/Polyglot with experience in building reliable, data-intensive applications in a microservices context - https://jobs.netflix.com/jobs/864653
Reach out to me directly if you have questions - laurent (@) netflix.com
I'd like to make a suggestion for a cool feature: being able to clone someone else's recipe and put my own 'twist' on it. Almost like a git fork, if you want to use that analogy. You could also submit pull requests... you get the idea.
We had a feature – “create a variation”. Unfortunately the feature did not work well in the real world and we had to pull the plug.
Literature cannot be forked the way we think about it in code. My variation of the potpie isn’t simply a fork of the ingredients and editing lines. It’s “likely” a different style altogether and in most cases required the new author to write something ground up. We tried fixing this but the edge cases became too complex to handle.
>My variation of the potpie isn’t simply a fork of the ingredients and editing lines. //
There's a few recipes I've used for which this is the case. Same for my mum - I've got magazine clipped recipes of hers that say something along the lines of "add cherries at the end, use sultanas instead of currants; I add a dash of brandy" or others that say "you need to cook for about 45 mins, not 30".
I think variations allow for a sort of evolution of a recipe towards your own personal preference.
But of course that doesn't take account of the actual implementation of such a feature being possible to do in a way that works well and fits with the aims of this site.
I'd be interested to know what sort of edge cases make it complex. Surely it's just a pre-filled version of a page, that one edits and optionally has a link saying "based on $recipe". I could see it getting abused for people wanting to link their recipes to popular ones (like youtube response vids that aren't really responses) but beyond that sort of thing it seems pretty basic. Were you trying to digest the multiple variations to offer options within a recipe or something?
I guess the use case you mentioned is more to adding variations like an alternate ingredient, or a tip to a step or something like alternative to what is suggested in the original recipe.
We have a wish list in our mind where we can add structured annotations (tips/alt ingredient/photo) to the original literature and have a repository of such stuff residing on top of the original recipe itself.
This way it can become a far more richer data, set in the original context and offer mutual learning to all.
But there's another angle to consider. In thick client apps, product code (everything else) tends to take up the majority of the size of the client bundle. There's a real opportunity here to move some of that into Server Components which would help reduce that footprint significantly. For example consider the case of deeply wrapped components that ultimately render to a single <div>. Server Components could help remove that abstraction tax.