Note that this really isn’t anything except the agreement to send messages separated by 2 new lines. The SSE object in browsers is old and quirky; for example, it only supports GET requests, which means you’ll hit path length limits if you use it for something like LLM completion with large prompts.
Luckily since there’s nothing special about the browser support, you can very easily replace it with custom implementations. https://www.npmjs.com/package/@microsoft/fetch-event-source for example offers mostly the same API, but does offer POST requests and a bunch of other goodies.
There is this agreement, and also the fact that browsers can forget previous messages, unlike any xhr-based custom implementation since the EventSource object does not provide methods to access previous contents. I don't know how well this package handles this.
I agree with the note about the auto retry mechanism of EventSource. It does no good, is unavoidable and a big annoyance. The work we had to do to work around it in Tracim (previous job) [1] was pure madness. I see this part has not been touched since I left by the way.
This seems like a great solution for streaming responses scoped to a single request. Neat!
I've always used SSEs to open a more persistent comms channel to a browser which creates way more state and complexity both on the client and the server.
I'm currently working as a senior software engineer (SDE3) in Amazon AWS, working on distributed services built on top of AWS, both frontend and backend.
What I would love is something that can give alternative tube sizes.
My bike uses 22x3 tubes, which are unusual and hard to come by. However, there have been reports of 20x4 bike tubes or 18x3 motorcycle tubes also fitting.
A website that recommends more widely available or cheaper “this will also fit” tubes would be amazing.
What are those numbers in reference to? And what size tire do you have? Tubes can stretch to around 3x the size of a tire. A lot of enduro riders carry a 26" tube for their 29er to save some hip pack space.
They share the same purpose, but functionally they're quite different:
1) Origami is a visual programming tool where you connect functional nodes. Some nodes represent things on screen, some represent actions. You literally connect them to eachother (connect my swipe node to my feed node) to prototype your UI. You use origami in the same way you setup a modular synth, or use something like pure-data or MaxMSP. The end result is a UI prototype.
2) FramerJS is a javascript-based prototyping tool that has a DSL for programming the prototypes. You are very much writing javascript code to simulate the real interactions the user might have with your interface.
That's the big difference. If you are familiar with Javascript, you will certainly have an easier time writing code in Framer to represent animation and interactions (it will also translate more easily to final production code because in theory the algorithms for the interactions are similar). If you have no programming background (or just feel at ease with visual programming), you may prefer Origami.
(They're both great tools, and despite being quite accustomed to the latest Framer versions, I'm going to try out Origami 2.0 too. Seems like a big step from the previous version.)
The 50 bytes figure represents a compressed response. (We actually write all of our pages compressed to disk before serving them -- nothing is served dynamically. But that's for another post...)
The example below isn't the most scientific, but should give you a rough idea.
Test index page with different static URLs:
URLs as 4cdn.org -- 23261 bytes compressed
URLs as 4chan-cdn.org -- 23311 bytes compressed
URLs as 4chan.org (control) -- 23278 bytes compressed
Can someone with more ZIP-algorithm knowledge than me explain why a difference in word length of 5 characters can result in a difference of compressed result length of 50 characters? I mean, a reference to a 1000-character word takes as much space as a reference to a 1-character word?
All these faster speeds won't do anything really for heavily populated areas. The most important thing is total available bandwidth (bytes/sec/hz), and it's unclear how better that will get. LTE itself doesn't improve a lot over 3G techniques, the thing that's making LTE faster in saturated conditions right now is that there's just more bandwidth compared to 3G.
Off shore wind power is about 25% of the wind power capacity of Denmark, the rest are 'normal' wind turbines. However, they'll contribute more to the total energy output. Off-shore wind turbines generate about 35-50% of their maximum capacity on average, compared to 20-30% of normal wind turbines.
