Waiting on https://github.com/scala-js/scala-js-dom/milestone/2.

https://developer.mozilla.org/en-US/docs/Web/API/EventSource

It seems that in Node.js 18 fetch is now in the global scope.

https://nodejs.org/en/blog/announcements/v18-release-announce/#fetch-experimental

Personally, I'd still recommend ember-client for Node.js, but since this is a potential usecase of http4s-dom would be good to test it. Unfortunately, this might be annoying to setup since our current test infrastructure is very geared for browsers.

I was just checking out what ServiceWorker provides and noticed it hardcodes IO and requires IORuntime. Could this be replaced with F[_]: Async and creating a dispatcher? Or was it the entire point to keep SyncIO so that you can safely run the effect synchronously?

Considering that:

1. these modules depend on http4s 1.0 milestones
2. they're been previously published under those versions

As reported by discord friends.

Linking to:

• scalameta/mdoc#577
• scalameta/mdoc#579

It's easy enough to add a check to CI that the JS artifact is below some threshold. But it would be more meaningful longterm if these numbers could go somewhere and be tracked.

Personally I think a small example in the README would be sufficient, demonstrating the FetchClient. Then just point to the http4s client docs or something.

Documenting the service-worker integration is a bit trickier. An example certainly wouldn't hurt, but to actually get a service worker running needs several moving parts. See https://developers.google.com/web/fundamentals/primers/service-workers.

Tracking @RaasAhsan's work upstream in http4s/http4s#5227.

This is assuming that http4s/http4s#5285 is imminent. I think having a (stable) release against a stable http4s version will be a big deal and help win over some of the naysayers e.g. keynmol/http4s-laminar-stack#7 (comment) 😉

However, this opens a pandora's box of versioning problems (see also #2). I'm also acutely aware of the upcoming scala-js-dom v2.0.0 release, which will hopefully land sometime in October. Unfortunately, I think it's important that we support both while the ecosystem upgrades.

My proposal:

1. Start http4s-dom series/0.1 against http4s 0.23.x and scala-js-dom 1.x.
2. When scala-js-dom 2.0.0 arrives, start http4s-dom series/0.2.
3. Continue publishing 1.0 milestones against http4s 1.0 milestones and scala-js-dom 2.x. If we don't keep our milestone numbers in sync with upstream http4s this will get really confusing, but it also prevents us from releasing on our own cadence. (Would it be weird to have minor milestone releases? e.g. 1.0.0-M28.1)
4. Pray that there's never a http4s 0.24.x.

We are testing http4s for our scala.js browser app and it seems to produce a fairly big increase on the scala.js produced by scala.js. One of the contributors is the very large MimeDB which maybe not needed on the typical frontend app

Should we split MimeDB into jvm and js versions, with the latter having a minimal or empty set of mime types?

Reported by @buntec:

I now run into a “maximum call stack size exceeded” exception in one of the projects at work using ff4s when making a simple GET request using ‘client.expect’. The source map points to line 255 in ‘MediaType.scala’, which looks innocuous to me. According to the call stack this seems to happen during entity decoding. I’m using 0.23.11. Strangely enough, this only occurs in the fully optimized js bundle; not during development when using fastOpt.

This sounds a lot like:

• #33

If we look at the reported line:

object MediaType extends MimeDB {

https://github.com/http4s/http4s/blob/v0.23.11/core/shared/src/main/scala/org/http4s/MediaType.scala#L255

It leads us to our old friend:

• #30

The current workaround is to disable GCC in fullOptJS with:

scalaJSLinkerConfig ~= { _.withClosureCompilerIfAvailable(false) }

I would like to explore alternative minimizers to GCC such as ESBuild:
https://esbuild.github.io/api/#minify

I also have a plan to fix #30 in http4s/http4s#5273. It is quite a bit of work to do binary-compatibly, but feasible I think.

Sorry for the hassle!

Why, when we already have http4s-circe from the main repo already crossing for Scala.js?

Because http4s-circe uses Jawn for parsing. This makes sense there, because it enables a pure cross and also supports fancy features like parsing streams etc.

But, a Jawn dependency is bloat and almost definitely less performant. The idea here is to offer a light-weight circe integration module that uses JS-native JSON.parse instead (via circe-parser).

Considerations:

1. Does Jawn measurably increase JS size or hurt performance? Probably, but would be good to actually verify this.
2. Does this module even belong in dom? Browsers care most about JS size, but everyone cares about performance, which is also at issue. There's an argument this belongs upstream.

See:

• djspiewak/sbt-spiewak#76

https://developer.chrome.com/articles/fetch-streaming-requests/

This will require some sort of feature test:

 const supportsRequestStreams = (() => {
    let duplexAccessed = false;
    
    const hasContentType = new Request('', {
      body: new ReadableStream(),
      method: 'POST',
      get duplex() {
        duplexAccessed = true;
        return 'half';
      },
    }).headers.has('Content-Type');
    
    console.log({ duplexAccessed, hasContentType });
    
    return duplexAccessed && !hasContentType;
  })();

The microsite is currently built only with Scala 2.12 in order to unblock the Scala.js 1.8 update. As it stands, the site will not build with Scala 2.13 or 3 due to the problems summarized in:

• scalameta/mdoc#601

For example, check out this example of using a service worker to serve requests from the browser cache API.

self.addEventListener('fetch', function(event) {
  event.respondWith(
    caches.match(event.request)
      .then(function(response) {
        // Cache hit - return response
        if (response) {
          return response;
        }
        return fetch(event.request);
      }
    )
  );
});

Instead of requiring it to be run externally via a Python script.

This was the fix applied in #45 for #33. Hopefully it works, except now the site load an 11mb JS file which is ... not ideal. So we are still seeking a better solution to this problem (see #33 for more details).