What are your thoughts on the Fluent Forever method, specifically the part that going through the effort of creating your own study materials is an integral part of recall and internalizing new words/knowledge? It's definitely attractive to have a lot of the "manual work" be automated, but maybe it's a necessary effort to cross the chasm that is intermediate language learning and perhaps most people stay at intermediate levels not because of the lack of a tool but because there's a natural filter with how much effort is required to go from intermediate to fluent.
I've been "stuck" in intermediate Japanese for years now after being on and off multiple times. Got to 1.2k kanji, "ok" grammar and ~3k vocab words. Perhaps something like this is what's needed. I've been wanting an "instructor" that can do this sort of indexing for all sorts of content like TV shows, movies, books, articles, etc.
I believe you can still do this in Next.js with some extra work to exclude the JS bundle. For example, you can use a custom `_document` page and exclude the `NextScript` component [1]. It would be nice if this was supported as a first-class concept, though.
I know the HN comments section is notorious for criticizing solutions they don't like because they seem too complex or unnecessary for them [1] but I'm honestly surprised that's happening with Next.js/Vercel here.
So many are saying that this could've been a static site distributed by a CDN. That's what a Next.js app on Vercel does by default! Unless you use `getServerSideProps`, Next.js will create a static site at build time and when deployed to Vercel it will be hosted on their CDN. Spending just a bit of time to understand why Next.js is so popular would've made that clear to most people here. But I guess that's not as easy as just criticizing it for bloat without knowing how it works and moving on?
It was a static site. That's what Vercel and Next.js does by default. If you don't use `getServerSideProps`, Next.js will generate static pages at build time and Vercel will serve them from their CDN.
If you like this type of stuff, Paul Henschel shares similar content on Twitter [1] and it's absolutely amazing. For example, incredible stuff like this [2].
I was pleasantly surprised by the list of "fundamentals". Here I was, expecting something rather specific about the discipline. And I'm so happy whatever I was expecting wasn't what was there. The qualities described do seem like true "fundamentals". It's a human effort after all.
Well, I guess you could say that if the store was run by robots so you didn't have to pay employees and if the shirts were made out of thin air so that there are no COGS. I'm not trying to be facetious. I think the distinction between marginal and fixed costs is important here because it's all about the feedback loop for aggregators. And one can think of marginal costs as "friction" in this loop.
That being said, perhaps aggregation theory won't be complete until Ben considers fixed costs in addition to marginal costs, which I believe might be your argument?
It will give us the opportunity to let developers build their own components, allow us to use frameworks like Next.js to power our users' sites, and let us leverage the ecosystem to build cool components and integrations. So as far as the end-user is concerned this should result in better performance, more options for components, and easier extensibility if they are developers.
Email: [email protected] Twitter: @ollermi