Are web-compat builtins actually a goal?

[bengl]

It seems to me that given an adequate lower-level interface, there's not much need for things like URL, fetch, etc. to be provided as builtins. I know this topic has been played out quite a bit in Node.js, but since this is a greenfield approach/project, I think this warrants of its own discussion.

I'm (at the moment) non-blockingly opposed (i.e. a -0 I guess) for adding WHATWG/W3C-specific builtins to the runtime as a base layer. I think it absolutely should be trivial to add such functionality and create environments that look enough like browsers to make browser code work.

[MylesBorins]

@bengl I guess one solution to split the difference here could be limiting the builtins that we ship in jstime_core, making other builtins available as their own crates, and then making the jstime CLI perhaps vendor enough things to make it a bit more useful off the shelf.

That way jstime_core can focus on supporting the API surface to be extensible and we can also ship a number of off the shelf built ins folks can include if they want. Could be an interesting place to explore collaboration with deno, it sounds like they might be starting to break out / vendor some of their builtins

[bengl]

That all pretty much sounds good. 👍

It sounds like the real win in #54 will be figuring out how to make jstime_core dead-simple to extend.

[MylesBorins]

I opened #56 to discuss modularizing builtins... I really like to idea of us making it dead simple to write extensions to jstime that are exposed as crates for easy consumption. If we do this we may want to even tease out console + queue_microtask and literally ship with 0 builtins

[jlengstorf]

a potential counterpoint to "ship with 0 builtins" is potential confusion for new devs. I see a lot of devs get overwhelmed and bail when it feels like there's a ton of config to add/things to install just to get to the point where they can start writing code (e.g. webpack, babel), so there's also a lot of value in having things Just Work™

that being said, I love the idea of modularizing builtins because that paves the way for really cool stuff around opting into future specs

and I guess one cool thing would be that you could create a "power user" option (no builtins) and a "happy path" option (comes with web compat builtins already) if things are modular anyways

[MylesBorins]

@jlengstorf I think the big difference here will be what is part of jstime cli (e.g. when they install jstime) vs what they get when they embed jstime_core.

I would imagine that jstime cli would ship with a bunch of built ins to make it useful, but jstime core could perhaps ship with only an interface for defining built ins and we ship the built ins separately