migueloller

I find it amusing the level of engineering that seems to have gone into this hand contrasted with the absolute AI slop in this blog post.

Let’s not be silly. If there are 10 people each with 10% and the company grows by 93%, then everybody’s shares, including the founder’s, grows by 93%.

The square-cube law strikes again!

https://en.m.wikipedia.org/wiki/Square%E2%80%93cube_law

I believe their target price is $20k. No idea if it costs that right now, I doubt it.

https://status.stripe.com/

Matt Levine’s writing on this is right along this line. It delineates between liquidity and solvency problems. Worth a read. https://www.bloomberg.com/opinion/articles/2022-11-10/ftx-is...

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 started reading Crafting Interpreters [1]. It's great so far!

[1] https://craftinginterpreters.com/

Since segments are determined by folders, you should be able to do `/layout/page.js` for a `/layout` route.

I agree 100%. It can’t just be a UI on too of CSS. At that point just write the HTML and CSS...

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.

[1] https://nextjs.org/docs/advanced-features/custom-document

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?

[1] https://news.ycombinator.com/item?id=9224

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].

[1] https://twitter.com/0xca0a [2] https://twitter.com/0xca0a/status/1357346054635544584

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.

Kleppmann, et al.'s paper on OpSets [1], a specification for building CRDTs with support for an atomic tree move operation, was the best one for me.

Automerge [2] implements a variant of this.

[1] https://arxiv.org/abs/1805.04263

[2] https://github.com/automerge/automerge

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.

I mistakenly replied to the incorrect thread hah. Sorry for the confusion!

Improving performance is something we're actively working on!

The promise (and I understand it's something we have to prove) is that extensibility won't lock you down. The most succinct way I can put it is: component composition. We're making a bet on the idea of components as a composable visual entity that can be used for building websites.

By putting the abstraction layer, even with templates, at the component level instead of the page level like most builders do, we believe that all of these pain points Alan mentions in the article will be solved. The component you're using should be flexible enough to modify to your heart's content. And if it isn't, you can just find a third-party component to satisfy that. And if that component exist, then you should be able to make your own by just writing some React (or Vue, etc.), not interfacing with some bespoke API.

And becase these components compose, there shouldn't be a need for a "rescue". That's the vision.

Thanks!

Hah, all good. We give them _visual_ control of everything. But say you wanted to make a component that pull the last 10 tweets from an account or a Stripe Checkout button or some other custom component, then you can.

Any React component is already a Makeswift component, the question is, how do you get the props? Well we've got a whole bunch of what we call prop controllers for basic stuff like numbers, colors, images, padding, margin, etc. You can also make your own. For example, in the Twitter feed component, you might make a panel that lets you search for tweets and then once you pick the account it passes the Twitter username to the component as a prop. The component can then fetch the tweets using the Twitter API, etc.

We have plans to open source all of our components as a reference for third-party developers building their own custom Makeswift components. Also, if you're a company that already has an internal design system built in React, your marketing team can just drop those in to your Makeswift site (constrained by the props the developers decide to expose).

This is all internal right now, though. I can't wait until we can release this API to the public, haha.

I'm not sure I understand what you mean. Why would developers have to maintain a website that's not hosted by them?

If the issue is maintainability once the website has been extended (i.e., with custom code and integrations), then it's all about _that__ experience. I think in those cases, the mistake is to come up with some sort of bespoke abstraction that the developer now has to learn and that is different from everything else they're used to.

With the way we've designed Makeswift, once we open up extensibility, you'll just use regular old code (e.g., React, Vue, Angular components, or plan HTML and JS), in a repository that's version-controlled, that lives with the rest of the code.

To make that a bit more concrete, today, Makeswift components are just React components. So Makeswift's API is just passing props to your component. That's what we plan to open up eventually.

We're in the early days of Makeswift but extensibility is a big part of our vision. The way we've built the core technology of our product is such that every component used in the builder is just a React component (and could be a Vue component or Svelte component), and even the controls in the sidebar, which we call panels, are also just React components. With this architecture, we plan to expose a public API where developers can just build their own Makeswift components and share them with the world. Someone could build a Stripe Checkout component, for example. Somebody else could build a table component that pulls the rows from Google Sheets, or Airtable, or from a Zoho API?

We've spent a lot of time thinking about the right architecture to pull this off. Today, we're focusing on removing bottlenecks for marketers so that they can build beautiful websites with flexibility, fast. So because of that we are making all the components ourselves. In the future, though, we expect most components to be built by other people.

Of course! You can find my contact info in my HN profile. Feel free to reach out and I'll get you one :)

Internationalization is definitely a big one. It's a hard thing to do right for a website builder designed for non-technical people, though.

That being said, I'm proud to currently have customers that have built sites in over 5 different languages, that I know of.

-Output accessibility (eg for blind users)

This is something that's in our roadmap. Makeswift components are just React components and as only developers of those components at the moment we plan to follow accessibility best practices.

-Clean and efficient output html (every square space site I visit is slow as shit)

Again, because the components are just React components, it's a matter of keeping markup clean in the components themselves. This is something that I think we could do a better job at right now. But we will definitely improve and there's a clear path for it.

-No cdn resources. Allows you to pack your own fonts and assets.

We're currently focused on delivering a great out-of-the-box experience so we take care of that for all of our customers. In the future we plan to open up an API that will allow developers so extend Makeswift however they see fit, including writing their own components, panels, and integration with assets, etc. This would allow you to pick your own custom fonts and assets.

That being said, today we do support custom snippets that you can add to your pages as well as an Embed component. With these you can bring your own "anything".

I agree that there's a clear difference between the two. Makeswift sites aren't just a "presentation", though. They're hybrid (server-side rendered on first load and client-side rendered after) React apps. And because of that you can have components that do all sorts of things a "presentation" can't do. For example, you can pull in data from third party APIs, you can build dynamic UIs with dialogs, you can animate components, you can submit forms, etc.

Not all of this is exposed just yet, which is why we're in early access. But a Makeswift site couldn't be further away from a "presentation builder".

That being said, it does seem the way we're presenting ourselves leaves much to be desired. So I appreciate you pointing that you!

Hah! Nice catch there :)

This is actually not part of the core Makeswift code, but a custom snippet we added to this blog post to tweak the navigation. It sets a class on scroll, which is why you saw so many errors in the console.

I just fixed it. Thanks for letting us know!