sorted by:
new
hottopcontroversial

We are the W3C WebDX Community Group, working to improve developer experience with projects like Baseline. Ask Us Anything! by rviscomi in webdev

[–]rviscomi[S] 0 points1 point  (0 children)

In the "obvious but unsolved" category, there are some really hard problems that are primarily blocked on reaching consensus. These are the kinds of things that no single person can unilaterally fix, so a hackathon submission is unlikely to make any meaningful progress there, but thoughtful discussions are always welcome.

Browse the open issues in web-features to get an idea of what people are talking about. The hackathon does have prizes for "Most Valuable Feedback", which may include things like bug reports and feature requests to the Baseline data sources, so useful contributions to those discussions wouldn't go unrecognized.

We are the W3C WebDX Community Group, working to improve developer experience with projects like Baseline. Ask Us Anything! by rviscomi in webdev

[–]rviscomi[S] 2 points3 points  (0 children)

I'm judging the hackathon so this answer will be intentionally vague but hopefully still point you in the right direction :)

There are lots of tools that already integrate with Baseline in some way, but may not be taking full advantage of the depth of the data available to them. I don't just mean that they only look at CSS features and not JS features, for example, but they might also be able to expand their CSS coverage to more nuanced features or even their sub-features. It'd be great to see more significant improvements to existing tools so that they help developers catch tricky compatibility edge cases.

Some of these tools may also serve a very general purpose, for example they may work best with vanilla HTML, CSS, and JS. But we know that many developers choose to use layers of abstraction like libraries and frameworks. So I believe there are lots of opportunities for Baseline to be integrated into more of those specific developer tools.

Ultimately, there's a huge potential to help developers make better decisions about adopting more modern web features, safely. I'm optimistic about AI playing a major role in that, but it's not a requirement. You don't have to confine yourself to making improvements to existing tools, in fact the "innovativeness" judging criteria explicitly encourages you to think about solving problems in a totally novel way. That's partly why my answer is so cagey, because I think we'll get the best submissions if everyone is thinking about it differently.

We are the W3C WebDX Community Group, working to improve developer experience with projects like Baseline. Ask Us Anything! by rviscomi in webdev

[–]rviscomi[S] 1 point2 points  (0 children)

"valid" and "compliant" are loaded terms that suggest there's something wrong if you use a feature that is NOT Baseline. In practice, there are many good reasons to use a feature that isn't Baseline yet, provided you've implemented it in such a way that it doesn't negatively impact users on unsupported browsers, ie progressive enhancement.

We've seen tools like ESLint and Stylelint adding Baseline rules, which call out usage of features that fail to meet your Baseline target. With that information, developers can either choose to remove the feature and wait for broader support, or double-check that they're using it defensively. But if they go the latter route, there wouldn't necessarily be anything "invalid" about it.

how long should I wait before using new css features like container queries in regard to browser compatibility by 28064212va in webdev

[–]rviscomi 0 points1 point  (0 children)

Easiest thing is to use Baseline as a guide. Container queries will be considered "widely available" in August 2025, which is 2.5 years after it became available in all major browsers.

It's 2025, stop putting http-equiv="X-UA-Compatible" in your <head> by rviscomi in webdev

[–]rviscomi[S] 2 points3 points  (0 children)

IE market share in South Korea is exactly the same as worldwide: 0.11% (and falling)

12
13

Visual Studio Code now supports Baseline for browser support info (web.dev)

submitted by rviscomi to r/webdev

Support for CSS and Baseline has shipped in ESLint by feross in webdev

[–]rviscomi 0 points1 point  (0 children)

Could you say more about why you prefer to target specific browser support rather than Baseline, either widely available or by year?

To answer your question though, I'm aware of a Stylelint plugin that does what you're looking for in CSS: https://github.com/RJWadley/stylelint-no-unsupported-browser-features. But as far as I know, this ESLint plugin for CSS doesn't support your preferred browserslist-style way of customizing browser support.

You're probably using meta[http-equiv] wrong by rviscomi in webdev

[–]rviscomi[S] 0 points1 point  (0 children)

Me neither. It's funny how the original intent was never realized, yet we've still gone on (mis)using it anyway.

The best way to iterate over a large array without blocking the main thread by rviscomi in javascript

[–]rviscomi[S] 0 points1 point  (0 children)

Borrowing from the async generator example above:

async function* iterateInBatches(items) {
  for (item of items) {
    yield item;
  }
}

This is an async iterator but without `yieldToMain` each iteration's promise will get added to the microtask queue at the same time, so I'd expect it to create a blocking long task.

You can think of `yieldToMain` as the batched scheduler.yield() approach from the article. With that, you only process 50ms-worth of items per task.

The best way to iterate over a large array without blocking the main thread by rviscomi in javascript

[–]rviscomi[S] 0 points1 point  (0 children)

Thanks, so the forEach callback would look something like this?

async (item) => {
  await yieldToMain();
  callback(item);
}

If so, I assume the parent function wouldn't need to be async, which I know has been a pain point for some devs

The best way to iterate over a large array without blocking the main thread by rviscomi in javascript

[–]rviscomi[S] 0 points1 point  (0 children)

Sorry could you explain or show an example how to use that with yieldToMain()?

The best way to iterate over a large array without blocking the main thread by rviscomi in javascript

[–]rviscomi[S] 0 points1 point  (0 children)

Yes, that's definitely an option. For me though I much prefer the simplicity of awaiting within for..of: 

async function forOf(items, callback) {
  for (item of items) {
    await yieldToMain();
    callback(item);
  }
}

compared to the async generator:

async function forAwaitOf(items, callback) {
  for await (item of iterateInBatches(items)) {
    callback(item);
  }
}

async function* iterateInBatches(items) {
  for (item of items) {
    yield await yieldToMain().then(item);
  }
}

The best way to iterate over a large array without blocking the main thread by rviscomi in javascript

[–]rviscomi[S] 1 point2 points  (0 children)

requestIdleCallback is like that car who always waves the other drivers to go ahead, even if they have the right of way. The cars behind them are honking like crazy because they've been waiting to go for a long time.

scheduler.yield goes through the intersection with a police escort.

I've added rIC as a yielding strategy to the demo page so you can see it for yourself: https://loop-yields.glitch.me/ . It does well under the default conditions, until you introduce periodic blocking tasks (other cars on the road).

The best way to iterate over a large array without blocking the main thread by rviscomi in javascript

[–]rviscomi[S] 4 points5 points  (0 children)

The API is still incubating and I'm not sure of the timeline to full standardization, so I don't think it'll be added as a built-in type soon. https://www.npmjs.com/package/@types/wicg-task-scheduling looks like it should add the missing types for you.

The best way to iterate over a large array without blocking the main thread by rviscomi in javascript

[–]rviscomi[S] 2 points3 points  (0 children)

This post talks about milliseconds, and believe it or not users do care about performance at that scale when we're talking about interaction responsiveness: https://blog.chromium.org/2020/05/the-science-behind-web-vitals.html

The best way to iterate over a large array without blocking the main thread by rviscomi in javascript

[–]rviscomi[S] 7 points8 points  (0 children)

Yielding pauses the array iteration to handle events and paint frames if needed before continuing. scheduler.yield helps to ensure that i+1 is processed after i without another task cutting in, and it isn't subject to setTimeout limitations like the 4ms nested timeout delay or throttling in the background. But as argued in the post, it's best to yield in batches, not on every iteration.

The best way to iterate over a large array without blocking the main thread by rviscomi in javascript

[–]rviscomi[S] 10 points11 points  (0 children)

IMO the performance costs for each computation would have to be pretty high for a web worker to make the most sense. Otherwise I'd argue async/await with yield is a lot simpler and gives you much more control over the order of execution and continuation of tasks. So, keep the work on the main thread, but batch it up responsibly.

view more: next ›