profile
viewpoint
Jamie Kyle jamiebuilds Eventbrite Oakland, CA https://jamie.build/ Code Ruins Everything Around Me

pull request commentjamiebuilds/codeowners-enforcer

init azure pipelines

Oh neat.

What about with macros, I've had to do this a number of times:

#[macro_use]
extern crate clap;
jamiebuilds

comment created time in 5 hours

pull request commentjamiebuilds/codeowners-enforcer

init azure pipelines

Imma be real with you, I don't know what the point of extern crate is

jamiebuilds

comment created time in 6 hours

push eventjamiebuilds/codeowners-enforcer

Jamie Kyle

commit sha 84a174eaac61c98dd130af181d47a6ac493b28d5

fix license ref

view details

push time in a day

push eventjamiebuilds/codeowners-enforcer

Jamie Kyle

commit sha 14e218c89e96c6547dc5908736f62d33967e0837

fix tag code

view details

push time in a day

push eventjamiebuilds/codeowners-enforcer

Jamie Kyle

commit sha 32e8c729409255cfe20374005e707e7349df5779

clippy fixes

view details

push time in a day

push eventjamiebuilds/codeowners-enforcer

Jamie Kyle

commit sha 73d121c27443ebe654716e8a717ec5631b52334a

fix fmt

view details

push time in a day

push eventjamiebuilds/codeowners-enforcer

Jamie Kyle

commit sha b13d3620c3cba959871510cbb7200aff402269c5

remove rest of cargo generate steps

view details

push time in a day

push eventjamiebuilds/codeowners-enforcer

Jamie Kyle

commit sha 958872ccbab2bb8fd78a650bf8ea023954be727b

Remove cargo-generate step

view details

push time in a day

push eventjamiebuilds/codeowners-enforcer

Jamie Kyle

commit sha aa625a8aa0ce1424f26b492c35d9686bb91359ca

remove wrangler specific stuff

view details

push time in a day

push eventjamiebuilds/codeowners-enforcer

Jamie Kyle

commit sha a5c3637fce21d8a2e6653fbaf4acc9e7b5efc254

update deploy connection

view details

push time in a day

create barnchjamiebuilds/codeowners-enforcer

branch : azure-pipelines

created branch time in a day

delete branch jamiebuilds/codeowners-enforcer

delete branch : azure-pipelines

delete time in a day

push eventjamiebuilds/codeowners-enforcer

Jamie Kyle

commit sha bd6835070e949384ed9360e5fa45a391a7214c17

Set up CI with Azure Pipelines [skip ci]

view details

push time in a day

create barnchjamiebuilds/codeowners-enforcer

branch : azure-pipelines

created branch time in a day

create barnchjamiebuilds/codeowners-enforcer

branch : master

created branch time in a day

created repositoryjamiebuilds/codeowners-enforcer

Enforce CODEOWNERS files on your repo

created time in a day

issue commentjamiebuilds/unstated-next

Why performance better than Redux?

useSelector() will also subscribe to the Redux store, and run your selector whenever an action is dispatched.

Yes, it falls into the same pitfalls.

I don't see how Redux could ever fix this problem (without a major subtractive/breaking change). It's a problem with its core architecture.

AjaxSolutions

comment created time in 3 days

push eventjamiebuilds/the-super-tiny-compiler

Jamie Kyle

commit sha f0321d5b1d77c409f56cc393564d0b3ffbd5a855

Update README.md

view details

push time in 5 days

issue commentjamiebuilds/unstated-next

Why performance better than Redux?

I'm working on a blog post about this exact topic https://gist.github.com/jamiekyle-eb/47a2cbf47d05cfd53537dc49708481d4

It's not that Unstated Next can offer better performance, it's that Redux opts out of React's better performance (because it opts out of React's component model).

AjaxSolutions

comment created time in 5 days

pull request commentjamiebuilds/unstated-next

Translate to Thai

Awesome! Thanks!

naruepanart

comment created time in 7 days

push eventjamiebuilds/unstated-next

Naruepanart Siangsanan

commit sha 3f196b98097075b8372faa7a49e11c81f0609520

Update thai language (#36)

view details

push time in 7 days

PR closed jamiebuilds/unstated-next

Separate the useContainer

Separate the useContainer function from the object. Reduce redundant code.

+8 -12

1 comment

1 changed file

TheBegining

pr closed time in 11 days

pull request commentjamiebuilds/unstated-next

Separate the useContainer

I don't want to make the context part of the public API. That would actually make the API have larger surface area.

TheBegining

comment created time in 11 days

issue commentsindresorhus/refined-github

Compact Discussions

So what if it looked something like this:

Screen Shot 2019-06-14 at 10 39 22 AM

jamiebuilds

comment created time in 12 days

delete branch jamiebuilds/ci-parallel-vars

delete branch : jamiebuilds-patch-1

delete time in 13 days

pull request commentjamiebuilds/ci-parallel-vars

Update README.md

bors r+

jamiebuilds

comment created time in 13 days

create barnchjamiebuilds/ci-parallel-vars

branch : jamiebuilds-patch-1

created branch time in 13 days

push eventjamiebuilds/scritch

Jamie Kyle

commit sha 46725c9ad684f1a11a751b914a0bff3856c47ad5

1.3.0

view details

push time in 13 days

created tagjamiebuilds/scritch

tagv1.3.0

A small CLI to help you write sharable scripts for your team

created time in 13 days

push eventjamiebuilds/scritch

Jamie Kyle

commit sha 9facf123bc2f385743871a65a2c9f8c323271469

switch to supports-color

view details

push time in 13 days

push eventjamiebuilds/scritch

Jamie Kyle

commit sha 34f0c0f2c23bc4bbcf22b85ed61f2a20778212db

1.2.0

view details

push time in 13 days

created tagjamiebuilds/scritch

tagv1.2.0

A small CLI to help you write sharable scripts for your team

created time in 13 days

push eventjamiebuilds/scritch

Kyle Welch

commit sha 7a50b35900a0cd7abbc5476dad5a8f835c0b8b5f

strip ansi escape codes on CI (#3)

view details

push time in 13 days

PR merged jamiebuilds/scritch

Strip ansi escape codes on CI

Personally, not a huge fan of the if/else, but the other option was ternary for the stdio.

+121 -3

0 comment

5 changed files

kwelch

pr closed time in 13 days

push eventjamiebuilds/ci-parallel-vars

Eric Nikolay Katz

commit sha 452c7cb7157dfc11aa3d8fd7f538906731118828

Add Semaphore Parallel Vars As documented in https://semaphoreci.com/docs/available-environment-variables.html

view details

push time in 14 days

PR merged jamiebuilds/ci-parallel-vars

Add Semaphore Parallel Vars

Add variables as documented in https://semaphoreci.com/docs/available-environment-variables.html

+5 -0

0 comment

1 changed file

ericnkatz

pr closed time in 14 days

issue commentsindresorhus/refined-github

Compact Discussions

There are better ways of achieving that. They don't do a particularly good job of it now anyways

jamiebuilds

comment created time in 15 days

issue commentjamiebuilds/unstated-next

multiple containers - Provider Inject

My advice is to avoid putting everything at the top-level of your app unless it actually needs to be there.

But if this is actually a problem, you can do this:

function compose(...containers) {
  return function Component(props) {
    return containers.reduceRight((children, Container) => {
      return <Container.Provider>{children}</Container.Provider>
    }, props.children)
  }
}

Of course this still produces a fairly large tree. But I don't want to build anything more complex in, and until/unless React gives us a useProvider(...) or a way to provide multiple contexts at once, that problem is gonna stick around.

neckaros

comment created time in 17 days

issue openedsindresorhus/refined-github

Compact Discussions

Problem

Right now on GitHub there is tons of visual noise around even a single inline comment on a diff:

Screen Shot 2019-06-09 at 12 20 55 PM

Proposed Changes

Like why do we need double borders:

Screen Shot 2019-06-09 at 12 21 12 PM

Why does "Resolve Conversation" need its own line:

Screen Shot 2019-06-09 at 12 21 37 PM

If there's only a single comment, why even have the reply line? Just turn it into a button (reactions are already there...):

Screen Shot 2019-06-09 at 12 22 55 PM

Resolve Conversations could also be a button or it could get the dropdown treatment:

Screen Shot 2019-06-09 at 12 23 53 PM

This change would take the above comment from taking up 240px of vertical space to 120px.

On a pull request with 40 comments, this makes a huge difference.

created time in 17 days

create barnchjamiebuilds/the-perfect-test-framework

branch : master

created branch time in 19 days

created repositoryjamiebuilds/the-perfect-test-framework

The Perfect Test Framework

created time in 19 days

push eventboltpkg/bolt

Jamie Kyle

commit sha 0e249732f0a6edab1ddfceb8bf9802f670f60016

0.23.4

view details

push time in 19 days

created tagboltpkg/bolt

tagv0.23.4

⚡️ Super-powered JavaScript project management

created time in 19 days

delete branch boltpkg/bolt

delete branch : fix-npm-registry-default

delete time in 19 days

push eventboltpkg/bolt

Jamie Kyle

commit sha e105df43c711c7bb0e7441ffc52b9cf0d13b5167

Fix fix for yarn setting an npm_config_registry (#234) * Fix fix for yarn setting an npm_config_registry * Fix test * Fix fix fix * Correctly test the fix fix fix

view details

push time in 19 days

PR merged boltpkg/bolt

Fix fix for yarn setting an npm_config_registry

Fixes https://github.com/boltpkg/bolt/pull/190#issuecomment-499965466

The problem with the original fix is that it makes the same mistake Yarn did by overwriting all registry configs. So I changed this to do the minimal amount of work to revert Yarn's incorrect behavior.

Note: Setting an env variable to undefined just completely eliminates it, which will cause npm to use its default behavior. Only when npm_config_registry has been set to something other than registry.yarnpkg.com should we respect it.

+17 -5

0 comment

2 changed files

jamiebuilds

pr closed time in 19 days

push eventboltpkg/bolt

Jamie Kyle

commit sha 0bb02d86841aaa33f9a3949d0e7374b7b065ddbf

Correctly test the fix fix fix

view details

push time in 19 days

push eventboltpkg/bolt

Jamie Kyle

commit sha baed212213c94e55d64df8bfa6a3449d6f005918

Fix fix fix

view details

push time in 19 days

push eventboltpkg/bolt

Jamie Kyle

commit sha 4db5b19cb9ac92d1935e4908bf264edef2626c62

Fix test

view details

push time in 19 days

PR opened boltpkg/bolt

Fix fix for yarn setting an npm_config_registry

Fixes https://github.com/boltpkg/bolt/pull/190#issuecomment-499965466

The problem with the original fix is that it makes the same mistake Yarn did by overwriting all registry configs. So I changed this to do the minimal amount of work to revert Yarn's incorrect behavior.

Note: Setting an env variable to undefined just completely eliminates it, which will cause npm to use its default behavior. Only when npm_config_registry has been set to something other than registry.yarnpkg.com should we respect it.

+6 -4

0 comment

1 changed file

pr created time in 19 days

create barnchboltpkg/bolt

branch : fix-npm-registry-default

created branch time in 19 days

pull request commentboltpkg/bolt

Fixes bug when running publish using bolt or yarn

Err... This causes the registry to always be set to https://registry.npmjs.org/ so if you are trying to publish to a private internal registry, you can't.

lukebatchelor

comment created time in 19 days

PR closed jamiebuilds/create-react-context

Publish current version to npm

Hello,

The current version (v0.2.3) has not been published to NPM yet. Can you please do so? 😋

+1 -1

0 comment

1 changed file

gregorym

pr closed time in 21 days

push eventjamiebuilds/create-react-context

Jamie Kyle

commit sha 81e8d508497e6fcbc97295bb7fdd04b41ca09883

0.3.0

view details

push time in 21 days

created tagjamiebuilds/create-react-context

tagv0.3.0

Polyfill for the proposed React context API

created time in 21 days

push eventjamiebuilds/create-react-context

Rouven Weßling

commit sha b04abbb240ad222abe30b58ef9a6242097aecdcb

Use the warning package instead of fbjs

view details

push time in 21 days

PR merged jamiebuilds/create-react-context

Use the warning package instead of fbjs

React recently removed the dependency of fbjs (https://github.com/facebook/react/pull/13069, not yet released). It's always been recommended that other packages shouldn't rely on it either.

At this point it'd pull in quite a bit of code so I simply exchanged it for the warning package.

Note I had to use version 3 of warning as 4 seems to have a bug with additional arguments.

+11 -4

6 comments

3 changed files

realityking

pr closed time in 21 days

push eventjamiebuilds/unstated-next

Barend

commit sha 3d58ed4a41bd0f225336801df0366aaf41634415

docs: Fix Chinese "Introducing Hooks" link (#34)

view details

push time in 21 days

push eventjamiebuilds/purposefile

Jamie Kyle

commit sha fa631a997c761a565dc239c2f814afc23b136e86

update cli

view details

Jamie Kyle

commit sha 6c0c46f4b5a8c6a33b6c83146113eddba9dd604c

1.2.0

view details

push time in 21 days

created tagjamiebuilds/purposefile

tagv1.2.0

Make sure every file in your repo is exactly where it should be

created time in 21 days

push eventjamiebuilds/react-loadable

Daniel Juhl

commit sha 040dffdc0f3177e11d9e3e07aae3f3471d15d303

Add Akutbolig.dk to users (#189)

view details

push time in 22 days

push eventjamiebuilds/react-loadable

Mostafa Nawara

commit sha 7838712eb166d3bd64c65f4ce14cf49b2d5e4855

Add “WUZZUF.NET” to users (#188)

view details

push time in 22 days

issue commentjamiebuilds/unstated-next

Support Storybook

I don't use Storybook for performance reasons, so I'm not sure how to debug this for you without seeing some code. Mind showing me what you mean?

liywjl

comment created time in 22 days

issue commentjamiebuilds/unstated-next

[Question] Advantage of Unstated over Context

Unstated Next is that exact pattern but wrapped up as a library for convenience and a better shared understanding. When you call UnstatedNext.createContainer() you are creating that "controller" component (which I just reused the name Container.Provider) and when you call Container.useContainer() you're effectively calling useContext().

hypervillain

comment created time in 22 days

issue openedgithub/semantic

Package managers

Are there any plans to put semantic on any common system package managers (i.e. apt, brew, etc)?

It's quite a long from-source install right now, and it would be really useful if there was some sort of distributed binary that could be installed faster.

created time in 23 days

issue commentmicrosoft/TypeScript

Inferring "this" from arrow function is {}

this isn't quite a parameter, it's very close to one, but it does have distinctions. We would not want to conflate this as parameters = [this, ...arguments].

You can always infer types for this, args, and the return type. And while ((a, b) => {}).bind(_, a) transforms the inferred args from [a, b] to [b], you don't transform this into non-existence, you still have to be able to infer a type, and representing that type as unknown to signify "non-existence" is changing the meaning of unknown.

this: t => .bind(t) => ?
parameters: [a, b] => .bind(_, a) => [b]
return: x => n/a => x

It's a weird edge case, but ? has to be something. Whether that's:

  • {}
  • any
  • unknown
  • never
  • T where T is the type of this internally
  • A compiler error banning you from inferring this from bound/arrow functions

{} is obviously incorrect, it implies that T is {}, but while it could be, that's not why TypeScript is giving it to you.

I would argue that unknown falls into the same bucket. It implies that T is unknown when it is not.

jamiebuilds

comment created time in 24 days

issue commentmicrosoft/TypeScript

Inferring "this" from arrow function is {}

For quux, we can we pass literally anything in as an argument and it will simply be ignored since the function doesn't have a binding slot for it.

This doesn't really matter, but that's now how .bind() works:

let a = (...args) => { console.log(...args) })
let b = a.bind(null, 1, 2, 3)
b(4, 5, 6)
// > 1 2 3 4 5 6

All functions in JavaScript, including arrow functions, have a this parameter that gets captured from different places. Saying

function outer() { return () => console.log(this) }
let inner = outer.call("foo")
inner() // "foo"

The inner arrow function captures a this context that it holds onto for its lifetime. To describe the this as unknown is inaccurate. It is known, it is a very specific thing, and it matters that TypeScript know that inside of the arrow function and outside of it.

function outer1(report) { return () => report(this) }
function outer2(report) { return function(this: unknown) { report(this) }.bind(this) }

To say that these are the same is inaccurate. And I don't think anyone would suggest that they should be the same. So what's different when we are inferring the type of an arrow function, why would we report it differently just because we're outside the arrow function? What values does that provide, the this isn't private to that function, it's not an implementation detail.

jamiebuilds

comment created time in 24 days

issue commentmicrosoft/TypeScript

Inferring "this" from arrow function is {}

I was thinking about that. But I think that unknown would also be incorrect. Think about it this way:

interface MyThis { property: boolean }

function context(this: MyThis) {
  let a = () => { console.log(this.property) }
  let b = function(this: MyThis) { console.log(this.property) }.bind(this)
}

Should the inferred types of a and b be interchangeable (at least in the context of this)?

I would say yes, they should be.

jamiebuilds

comment created time in 25 days

issue commentmicrosoft/TypeScript

Inferring "this" from arrow function is {}

@kitsonk Yes I understand how arrow functions work and I understand how TypeScript inference works. I understand that a this type in an arrow function doesn't make much sense. However, the bug that I am reporting is that TypeScript does produce a type for this in an arrow function, and that type is incorrectly.

TypeScript could (and in fact does appear to in some cases) store the this context for an arrow function from its definition, and then it can later use that this type to fix this inference bug that I am reporting.

If TypeScript wants to change that type to any or something, that would also be fine, but right now I am able to produce correct JavaScript code that TypeScript reports as incorrect and this is the underlying cause.

I don't need you to explain JavaScript to me, I worked on Babel, TC39, and Flow.

jamiebuilds

comment created time in 25 days

issue commentmicrosoft/TypeScript

Inferring "this" from arrow function is {}

That's incorrect, they always utilize the this of context they are defined in, which is why TypeScript is already able to lookup the this of arrow functions:

https://www.typescriptlang.org/play/index.html#src=let%20returnsThis%20%3D%20()%20%3D%3E%20this%0D%0Alet%20value%3A%20%22wrong%22%20%3D%20returnsThis()

jamiebuilds

comment created time in 25 days

issue openedmicrosoft/TypeScript

Inferring "this" from arrow function is {}

TypeScript Version: Version 3.6.0-dev.20190601 Search Terms: This, Arrow, Functions, Infer, Inference, Empty, Object, Incorrect, Any

Code

type FunctionThisType<T extends (...args: any[]) => any> =
  T extends (this: infer R, ...args: any[]) => any ? R : any

let fn = () => {}
let value: FunctionThisType<typeof fn> = "wrong"

Expected behavior:

error TS2322: Type '"wrong"' is not assignable to type 'typeof globalThis'.

Found 1 error.

Actual behavior:

No errors found.

Playground Link: Playground

Related Issues: None found.

created time in 25 days

issue commentgoogle/WebFundamentals

Remove article on SSR with puppeteer?

The target audience was never the thousands/millions pages use case. It's the SPA dev, writing a JS-driven app that has zero SEO.

These things aren't mutually exclusive. You can have a SPA with thousands/millions of pages, with parts of that app needing SEO and others not needing it.

I don't think that because existing solutions exist means that this isn't worth exploring. There are lots of documented problems with every solution out there, many of which become dramatically more problematic the larger the organization.

We use react-dom/server today, and there are many fundamental problems with that approach.

The best solution outside of a headless browser would be using the client-side rendering path on top of jsdom. But even that would require a lot of optimizations to be reasonable, and those optimizations are much harder to do without some of the APIs that Puppeteer provides for you. And you quickly end up supporting a much more complex environment which is always going to be poorly documented.

jakearchibald

comment created time in a month

issue commentjamiebuilds/unstated-next

Anyway to use Apollo Queries inside containers?

Hooks can only be used at the top level of a component or another hook. See https://reactjs.org/docs/hooks-rules.html

But yes, you can call any hook inside of your container hook.

function useCurrentUser() {
  let { data } = useQuery(...)
  ...
}

let CurrentUser = createContainer(useCurrentUser)

As for using a hook inside a callback: you can't. But I assume a graphql hook library would have a way of dealing with that

Jbern16

comment created time in a month

issue commentjamiebuilds/unstated-next

Double references necessary?

You can have multiple instances of the same state container in different React subtrees.

This works the same way as context in React, when you .useContainer() you're pulling from the closest Provider.

There are many cases where you just want to share your container globally and will only need one Provider, but if you need separate states you can use multiple (and instantiate them with different initialState)

kluplau

comment created time in a month

issue commentgoogle/WebFundamentals

Remove article on SSR with puppeteer?

If you've got thousands/millions of pages, your workarounds don't scale.

It's dependent on the site.

A website like Reddit may have tens (if not hundreds) of millions of pages, but a very high percentage of the traffic/second is only to a tiny subset of those pages, while tens of millions go unvisited for weeks or months at a time.

Where a website like Wikipedia has millions of pages, and it's likely that the traffic to those pages is far more evenly distributed.

jakearchibald

comment created time in a month

issue commentgoogle/WebFundamentals

Remove article on SSR with puppeteer?

Prerendering at build time with Puppeteer is really great if you are able to do it, but if you're in a scenario where there are too many unique pages (thousands, millions, etc) or that update as data changes, then rendering "lazily" (at first request) is the only realistic option.

It's also really difficult to get an engineering org of dozens or hundreds of engineers to regularly support both a browser environment and node environment (including with jsdom in place). There's always one environment that ends up suffering. You might run all your test suites in both places, but developers still all work in a browser and things slip through.

There's also the problem that engineers have a lot more difficulty trying to optimize their pages when they have to take SSR into account. Often people will create unique SSR bundles that bundle modules differently. For example, often people will bundle their apps without any code splitting for SSR. Which was a common problem I heard from my work on react-loadable which tries to send down all the relevant bundles for a page at once by recording what happened during SSR.

I think that by putting a full browser on the server that we can greatly simplify these and many other problems around SSR. I think that the performance problems of doing that can be mitigated.

jakearchibald

comment created time in a month

push eventjamiebuilds/unstated-next

Jamie Kyle

commit sha aecd4dd0d6394051da05b545704205ad88cba0fd

Update README.md

view details

push time in a month

push eventjamiebuilds/purposefile

Jamie Kyle

commit sha 9e651b5725c1e4145a48ffe76d5afad0af3a851a

add library and ! patterns

view details

push time in a month

create barnchjamiebuilds/globby

branch : gitignore-stats

created branch time in a month

create barnchjamiebuilds/globby

branch : upgrade-ignore

created branch time in a month

fork jamiebuilds/globby

User-friendly glob matching

fork in a month

startedforsigner/gql-tag

started time in a month

create barnchjamiebuilds/testing-github-dependents

branch : master

created branch time in a month

created repositoryjamiebuilds/testing-github-dependents

created time in a month

PR opened babel/babel

Change root package.json#name

I'm pretty sure GitHub's new Dependants feature is based on this package.json. I'm updating it here so it will reflect the new name for the core package.

D680031B-947A-4DCB-9160-51C628EFD805

+1 -1

0 comment

1 changed file

pr created time in a month

push eventjamiebuilds/bbl

Jamie Kyle

commit sha 08d0be69506077f20782db16b69c6e6c337c0feb

Change root package.json#name I'm pretty sure GitHub's new Dependants feature is based on this package.json. I'm updating it here so it will reflect the new name for the core package.

view details

push time in a month

issue commentjamiebuilds/unstated-next

wait until state changed ?

Note that you could use useEffect to be notified whenever the component updates though. And by specifying deps it will only run when one of the values you care about have changed and the component has rendered

littlee

comment created time in a month

issue closedjamiebuilds/unstated-next

wait until state changed ?

in unstated, we can use await to wait for state change, like this

class CounterContainer extends Container {
  state = { count: 0 };
  increment = async () => {
    await this.setState({ count: 1 });
    console.log(this.state.count); // 1
  };
}

how do I do something similar in unstated-next ?

function useCounter(initialState = 0) {
  let [count, setCount] = useState(initialState)
  let decrement = () => setCount(count - 1)
  let increment = () => setCount(count + 1)
  return { count, decrement, increment }
}

let Counter = createContainer(useCounter)

function CounterDisplay() {
  let counter = Counter.useContainer()
  return (
    <div>
      <button onClick={() => {
        counter.increment();
        console.log(counter.count); // old value
      }}>-</button>
      <span>{counter.count}</span>
      <button onClick={counter.increment}>+</button>
    </div>
  )
}

closed time in a month

littlee

issue commentjamiebuilds/unstated-next

wait until state changed ?

React Hooks don't provide any way of doing this. So it's not possible

littlee

comment created time in a month

issue commentgoogle/WebFundamentals

Remove article on SSR with puppeteer?

I'll experiment with building a library for it

jakearchibald

comment created time in a month

issue commentgoogle/WebFundamentals

Remove article on SSR with puppeteer?

When we're comparing against real-time rendering via SSR with jsdom or framework functionality, there isn't as huge of a difference doing the same with puppeteer.

It's mostly the same JavaScript code, which in both cases is being executed in V8. Of course that still leaves a lot of overhead, but when you address each bit of overhead piece by piece, the vast majority of it can be eliminated.

Whether you're SSR-ing with Node or Chromium, both cases would still benefit greatly from many of the same things. Maybe that in itself should be a blog post here (which I'd also be happy to contribute to).

Maybe the warnings and best practices warrant more than just a single blog post. I see that Google has also built Rendertron which seems to be trying to fill the same place.

Maybe a library is a better fit for guiding people on how to correctly use Puppeteer for SSR. Expanding the functionality there, doubling down on optimization strategies, and writing about how appropriately use it (in a way that scales reasonably well) would be a better resource for the web community.

jakearchibald

comment created time in a month

more