peterhunt

When I was in elementary school in the 90s I was doing a project about this new (to me) thing called “the internet.” My mom helped me cold email Vint and he sent me a very nice reply. Never forgot that.

Let's see:

- Variable scoping https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere...

- Function definition and application https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere...

- Flow control https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere...

- Loops https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere...

- Module system https://developer.mozilla.org/en-US/docs/Web/XML/XSLT/Refere...

Yep, it's a programming language. And not a great one!

Now do it without Cloudflare :)

Just do it in person. The voter fills out the ballot in front of the buyer, seals and signs the envelope, and hands it to the buyer in exchange for cash. The buyer then puts it in the mail on the voter’s behalf.

The voter could go to a polling place afterwards and attempt to cast a provisional ballot but my understanding is that this is difficult, varies significantly state to state, and in many cases is not possible given that mail in ballots are detached from the voter identity ahead of Election Day in many states.

The same could be said of mail in paper ballots too, which have seen widespread adoption in the United States starting in 2020, so I don’t think this should be a knock against this system.

There's clearly something else going on here because I am having trouble following this argument.

You pretty clearly laid out what you meant by server rendered in your original comment:

Were I forced to write a website today, it’d still end up looking similar to a traditional Django server-side rendering system with pages, and deep links, and all that.

Nowhere did I advocate leaping to SPAs for no reason. I simply made the case - and stand by it - that building with the same set of technologies client and server side leads to more flexibility and less code.

Re: the comment about booting the app, I think that is one of the strongest arguments in favor of server rendered apps, which is why I qualified my comment to "interactions", which happen after the page loads.

I lived through the server-rendering-only days of the original Hotmail client, and the php-plus-jquery spaghetti era. They were terrible for developers and terrible for users. Going backwards would be a huge mistake.

Calling this argument a strawman is pretty dismissive and is not a technical arugment. There are lots of client side interactions that do not need to be blocked on data from the server. Popup menus, modals, collapsible lists, rich text editing etc.

Also think about what actually has to happen when you interact with a server rendered app vs a client rendered app. Once the client app is booted you don't have to pay network latency, html parsing, FOUC etc on every interaction as you would with a server rendered app.

The main benefit is the flexibility to seamlessly move this logic from server to client and vice versa without rewriting all of your code.

Purely server rendered apps tend to have much slower interactions and exhibit weird behaviors so it is valuable to be able to do some stuff on the client.

Dagster Labs | Software Engineers, Product Managers, Designers | SF, Minneapolis, NYC or Remote | Full-time | Open-source

Dagster is the data orchestration platform built for productivity. Data engineers all around the world, in every industry, use Dagster to build scalable and maintainable data applications like ETL pipelines, ML training pipelines, data integrations and similar systems.

Data applications are the true core of AI and ML training systems, and our goal is to make Dagster the de facto standard for structuring these systems.

We’re an early stage, well-funded startup team with a proven track record of shipping open source software with global adoption. We put a premium on respectful, clear, and complete communication, and we expect each other to be creative, curious, effective, and empathetic.

More info: https://www.dagster.io/careers

For all intents and purposes, Spirit is part of Boeing.

Spirit was Boeing Wichita until 2005, and today Boeing represents 85% of sales.

I’d add practical zero knowledge proof systems to the list.

I worked with these guys a long time ago at FB.

Their founder and CEO created The Algorithm at Instagram. Rest of the team is super strong too. Makes a lot of sense for OpenAI to acquire a team at the intersection of AI and consumer products.

Thanks for the kind words. I built it on a few cross-country plane rides and now I mostly just leave it alone. The infrastructure and tooling we have these days is so incredible.

Sure. The old one just splits the transcript into 5 minute chunks and summarizes those. The reason this sucks is because each 5 minute chunk could contain multiple topics, or the same topic could be repeated across multiple chunks.

This dumb technique is actually pretty useful for a lot of people though, and has the advantages of being super easy to parallelize and requiring only 1 pass through the data.

The more advanced technique does a pass through large chunks of the transcript to create lists of chapters in each chunk. Then it combines them to a single canonical chapter list with timestamps (it usually takes a few tries for the model to get it right). Then it does a second pass through the transcript, summarizing the content for each chapter.

The end result is a lot more useful, but is way slower and more expensive.

I built summarize.tech

Yes it's a great idea and I have a version that is basically a convolution over the transcript. It works much better than the current version - it can automatically create cohesive chapters and summaries of those chapters - however, it consumes an order of magnitude more ChatGPT API calls making it uneconomical (for now!)

Yeah totally agree. Most of the time branch deployments are short lived, single commit branches that live for the duration of the PR

I work on Dagster but I'm not the author.

Dagster is OSS and most folks do local development on their laptop which is quite fast. The speedups in this post are for production deployments (i.e. landing a commit in your master branch) and for branch deployments (the deployments that run on every pull request).

What type of heat pump do you have out of curiosity?

I’m talking about the ones sold in the United States in the last few years. Mine is a Carrier manufactured in 2022

It is coordinated. In many states there are huge incentives [1] to disconnect your existing home from (and not connect new construction to) the natural gas infrastructure.

This is great for the climate but air source heat pump technology simply doesn't work well in cold climates. Most heat pumps in the United States have 100% efficiency down to about 20 degrees F. Below that they "lose efficiency."

What most people don't realize is that "lose efficiency" = blows cool or cold air. So if you live somewhere that routinely gets that low you are likely either going to be really cold, or have to engage aux heat (often natgas or oil-based heating or electric resistance heating).

Additionally, even when operating at 100% efficiency they don't blow air as hot as traditional heating sources. So if you have a poorly insulated room, large space, or even just an unusually cold day, it will often have a hard time keeping up.

I have found that I only use my air source heat pump a little bit during the fall in New England, and I have to run aux heat throughout basically all of winter. Talking to my friends in the region who have heat pumps, they all have similar experiences.

I think we are all very eager to get off of fossil fuels but the technology just isn't there yet, and I am concerned that most people installing heat pumps today don't know the risks associated with them in extreme weather events. If your heat pump can't keep up and you didn't install aux heating you can't live in your house, your pipes will freeze, and you will generally have a bad time. If you did install and use aux heating, you may be surprised at how expensive and inefficient resistive electric heating is as it may need to run all the time.

[1] Massachusetts will pay you $10k to install air source heat pumps and disconnect from natural gas https://www.masssave.com/en/residential/rebates-and-incentiv...

This is super interesting. Is there anywhere I can read more about this?

The template language doesn't compete with JSX. It competes with JSX + JavaScript, which is far more expressive.

I am against constrained DSLs in general unless it buys you something. In the general case, with a DSL you sacrifice expressivity in order to gain security guarantees or improved performance. In this case you are sacrificing expressivity to gain performance but I don't think the performance gains are meaningful enough to be worth sacrificing all of that expressivity. So to answer your question, I am generally opposed to constrained templating DSLs for web frontend applications overall.

The main divide I've observed is whether you are encouraged to use JavaScript's built-in control flow and code reuse mechanisms or a less expressive DSL.

Hooks are pretty sweet but I think they should have launched with higher order hooks that used the same lifecycle as original React. That way you wouldn't need to think too hard about things like object identity (which I think is the state management issue you're getting at -- it wasn't a huge issue in the pre hook days)

I think there are two things that are interesting about your point of view.

First, I think a mistake the react team made was not exerting more control over the ecosystem. I think a lot of questionable content marketing pieces ended up as “best practices” which we are still unwinding as a community.

Second, I totally buy the idea that there are multiple personas and that different tools speak to different personas. The sustained popularity of constrained dsls among subsets of the frontend community speaks to this.

SolidJS also sacrifices expressivity for performance (ie you need to do contortions like this[1] to build dynamic lists), so I prefer React to it. However, I like its approach more than Svelte because there’s less of a DSL to learn.

[1] https://www.solidjs.com/tutorial/flow_for

I'm quoted in this blog post so I figured I'd respond. I'm a former member of the React team but I haven't worked on it in a long time.

Largely I agree with everything in this article on a factual basis but I disagree on the framing of the trade-offs. Two points in particular:

1. Before open sourcing React we extensively measured performance on real world applications like mobile search and desktop ads management flows. While there are pathological cases where you can notice the overhead of the virtual DOM diff it's pretty rare that it meaningfully affects the user experience in practice, especially when compared to the overhead of downloading static resources like JS and rendering antipatterns like layout thrash. And in the situations where it is noticeable there are escape hatches to fix it (as mentioned in the article).

2. I disagree with the last sentence strongly. I would argue that Svelte makes huge sacrifices in expressive power, tooling and predictability in order to gain performance that is often not noticeable or is easily achieved with React's memoization features. React was always about enabling front-end engineers to take advantage of software engineering best practices so they could level up velocity and quality. I think Svelte's use of a constrained custom DSL is a big step backwards in that respect so while I appreciate the engineering behind it, it's not a technology I am interested in using.

Even though I disagree on these points I think it is a well-written article and is a pretty fair criticism of React outside of those two points, and I could see reasonable people disagreeing on these trade-offs.

The real answer is twofold:

1. Lots of batch jobs. Sometimes it's unclear how much value they produce / whether they're still used.

2. Twitter probably made a mistake early on in taking a fanout-on-write approach to populate feeds. This is super expensive and necessitates a lot of additional infrastructure. There is a good video about it here: https://www.youtube.com/watch?v=WEgCjwyXvwc

Not in the eyes of its creator https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...

IMO it’s two things.

1. REST positioned itself in opposition to RPC. The concept of RPC is a negative one in many engineers’ minds.

2. JSON-RPC isn’t that much better than passing your own JSON formatted messages over HTTP. So I don’t think it gets you too much incremental value these days.

With that said I love JSON-RPC and tend to reach for it pretty often for prototypes or greenfield projects.