<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0">
  <channel>
    <title>links.lmorchard.com - #pubsub</title>
    <link>/tags/pubsub/</link>
    <description>Recent bookmarks tagged #pubsub</description>
    <lastBuildDate>Mon, 02 Nov 2026 08:24:52 +0000</lastBuildDate>
    <item>
      <title>Server-Sent Events Beat WebSockets for 95% of Real-Time Apps (Here&#39;s Why) - DEV Community</title>
      <link>https://dev.to/polliog/server-sent-events-beat-websockets-for-95-of-real-time-apps-heres-why-a4l?context=digest</link>
      <description>Everyone defaults to WebSockets for real-time features. Most shouldn&#39;t.&#xA;&#xA;The reality: 95% of &#34;real-time&#34; applications only need server → client updates. Chat notifications. Live dashboards. Stock tickers. Log streams. AI responses.&#xA;&#xA;WebSockets give you bidirectional communication. But bidirectional comes with a tax: complexity, resource overhead, scaling challenges, debugging nightmares.&#xA;&#xA;Server-Sent Events (SSE) do one thing: stream data from server to client. They do it brilliantly. And for most applications, that&#39;s all you need.&lt;br/&gt;&#xA;&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #events #http #pubsub #sse #webdev&lt;/p&gt;</description>
      <pubDate>Fri, 06 Feb 2026 00:51:51 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:38283</guid>
      <category>events</category>
      <category>http</category>
      <category>pubsub</category>
      <category>sse</category>
      <category>webdev</category>
      <enclosure url="https://links.lmorchard.com/static/27c95dfb95baeb4be52f775fd2bb0915.webp" type="image/webp"></enclosure>
    </item>
    <item>
      <title>Broadcast Channel API - Web APIs | MDN</title>
      <link>https://developer.mozilla.org/en-US/docs/Web/API/Broadcast_Channel_API</link>
      <description>The Broadcast Channel API allows basic communication between browsing contexts (that is, windows, tabs, frames, or iframes) and workers on the same origin.&#xA;&#xA;By creating a BroadcastChannel object, you can receive any messages that are posted to it. You don&#39;t have to maintain a reference to the frames or workers you wish to communicate with: they can &#34;subscribe&#34; to a particular channel by constructing their own BroadcastChannel with the same name, and have bi-directional communication between all of them.&lt;br/&gt;&#xA;&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #pubsub #webdev&lt;/p&gt;</description>
      <pubDate>Wed, 28 Jan 2026 23:52:25 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:38261</guid>
      <category>pubsub</category>
      <category>webdev</category>
    </item>
    <item>
      <title>Client-side Messaging Essentials</title>
      <link>http://freshbrewedcode.com/jimcowart/2013/02/07/client-side-messaging-essentials/</link>
      <description>&#34;Most people throw around the term “pub/sub” to describe any kind of eventing/messaging – but I think this term fails to adequately communicate the abstraction. Yes, ultimately, something is subscribing to what something else is publishing. But the level at which publishers and subscribers are encapsulated has the power to make a good pattern turn to the dark side. So, what’s the difference?&#34;&lt;br/&gt;&#xA;&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #imported:pinboard #js #messaging #pubsub #webdev&lt;/p&gt;</description>
      <pubDate>Fri, 15 Feb 2013 16:59:50 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:32484</guid>
      <category>imported:pinboard</category>
      <category>js</category>
      <category>messaging</category>
      <category>pubsub</category>
      <category>webdev</category>
    </item>
    <item>
      <title>Client-side Messaging Essentials</title>
      <link>http://freshbrewedcode.com/jimcowart/2013/02/07/client-side-messaging-essentials</link>
      <description>&#34;Most people throw around the term “pub/sub” to describe any kind of eventing/messaging – but I think this term fails to adequately communicate the abstraction. Yes, ultimately, something is subscribing to what something else is publishing. But the level at which publishers and subscribers are encapsulated has the power to make a good pattern turn to the dark side. So, what’s the difference?&#34;&lt;br/&gt;&#xA;&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #js #messaging #pubsub #webdev&lt;/p&gt;</description>
      <pubDate>Fri, 15 Feb 2013 16:59:50 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:23271</guid>
      <category>js</category>
      <category>messaging</category>
      <category>pubsub</category>
      <category>webdev</category>
    </item>
    <item>
      <title>mod_pubsub Project FAQ</title>
      <link>http://www.mod-pubsub.org/kn_docs/faq.html</link>
      <description>&lt;p&gt;&lt;strong&gt;Tags:&lt;/strong&gt; #pubsub #www&lt;/p&gt;</description>
      <pubDate>Wed, 19 Nov 2003 21:04:45 +0000</pubDate>
      <guid isPermaLink="false">linkding-ssg:bookmark:910</guid>
      <category>pubsub</category>
      <category>www</category>
    </item>
  </channel>
</rss>
