beeandapenguin

The question didn’t ask about production readiness. But I would say that it depends on your use case.

For example, I think Deno is an excellent alternative to Node for general purpose scripting, but that doesn’t require production readiness.

On the other hand, platforms like Slack[1] and Netlify[2] are betting on Deno for their next generation developer platforms. These platforms are still considered beta, but I think that’s a decent indicator to track status of production readiness.

- [1]: https://api.slack.com/future

- [2]: https://www.netlify.com/blog/announcing-serverless-compute-w...

In the JavaScript ecosystem, check out Deno. Built in formatting, type checking, test runner, benchmarker, and dependency management via web standards. Minimalism is pretty core to their philosophy.

I also use OpenWRT with SQM (using cake queuing discipline) on a CM4 Pi to address buffer bloat. I don’t see any red blips, my latency is consistently between 20-40ms on Wi-Fi.

What hardware do you have? SQM is pretty CPU intensive. Mine is just powerful enough to be able to use SQM. Try checking if your cpu usage spikes from softirq interrupts.

VR adds a third dimension compared to a typical remote meeting. For me, this gives a sense of locality, as if you’re sitting next to a specific person (not a bunch of tiles) and can communicate with them naturally. Features like breakout rooms are not required.

Any other remote meeting features like virtual whiteboards are usually the same level of convenience, or more so. It’s almost like progressive enhancement when the meeting has both VR and non-VR attendees.

One step further: serve the PWA from the plane’s LAN. Forgot to install the app before takeoff? No matter!

For any frontend folks looking to use packet-level throttling over simulation with lab testing tools such as Lighthouse, I highly recommend throttle from the sitespeed.io folks. Inspired by comcast, but installable in Node.

https://github.com/sitespeedio/throttle

Shop Pay by is powered by Stripe

Completely agree on the questioning of JS being futureproof. With the advent of WASM, JavaScript developers have been given foresight and "reskilling" might not be a bad idea (in the words of swyx [1])

[1]: https://twitter.com/swyx/status/1521973694414864385?s=20&t=I...

Good clarification. That said, the permissions are highly programmable on top of V8 behind specific calls, and it's better than root by default as with containers :)

Similar to Chromium, Deno's permissions model is embedded in their CLI crate. Would love to see this get extracted into their core crates so that custom JS runtimes can leverage it more easily.

It is WASM. This is implied in the post, even though the emphasis is on JS. WASM is still early and has a young ecosystem. Only now are we really starting to explore what WASM can do and I predict that will only accelerate.

There's a lot more to unpack from this concept than Ryan's post is letting on. I'm seeing a lot of negative sentiment, largely focused on negative opinions towards JavaScript.

This is entirely besides the point. The emphasis is mostly on V8, which we all know is first and foremost a JavaScript engine. But it is also a WebAssembly engine, meaning several languages beyond JavaScript can execute with the approach he's talking about.

What the post doesn't really go into detail on is how V8 is arguably the most secure runtime in the world. The browser runtime is one of the most battle tested pieces of software ever built. At its core, it enables remote code execution on anyone's machine. It has a robust security model. Your program can't do whatever it wants on the host operating system, unless granted by the user.

Docker Containers were an improvement over Virtual Machines by enabling dependency snapshots and compiled programs on top of an OS. V8 Isolates (translation: chrome tabs) are an improvement over Containers. Cloudflare's discovery here is what enabled them to build their edge network. With a containerized server deploy, you can execute dozens of concurrent, isolated V8 programs without needing to spin up a new container for each of them. The server also has complete control over execution time and memory. If a V8 program consumes more than its budget, it can easily be terminated.

Runtime performance concerns about JavaScript are also misguided. With Rust, it's easier than ever to write native functions that can be executed in JS or WASM. Extending the V8 codebase has historically been so difficult that most people don't even consider it a possibility. With Deno's V8 bindings, snapshots, and core crates, anyone can extend the language ecosystem with relative ease. Programs operating in this model on the edge have already shown to be significantly more performant than their traditional server deploy counterparts. End-to-end latency is all but eliminated, until that edge program needs to fetch data from a datacenter. And for that, the "global state" problem is aggressively being worked on by the major edge providers (sorry Cloudflare KV, we're having a hard time relating with you). Once this has been solved, the web is prepared for some serious optimization.

If you still think "the edge" is a fad in 2022, I'd recommend spending more time learning about it. It's not just JavaScript. Ironically, this architecture is the solution to the web's JavaScript problem, and will be the demise of heavy clients and SPAs.

IMO the silver lining to Deno is incredibly simple: it’s compatibility with the web platform. I’m not sure what you mean by not compatible with the larger ecosystem, as Deno is basically spec compliant except for the Deno namespace (which you can polyfill out).

If you haven’t experienced any pain authoring isomorphic JS with Node, that’s great! My experience has been the opposite of that. But with Deno, everything feels completely web native. You never need to worry about modules, syntax, platform features (even localStorage!), or packages… it just works.

On top of that, all the built-in tooling is high quality and I’ve never felt the need to replace them. A formatter, test runner, bundler, type checker, doc generator, benchmarker, and even the built in deployment platform. In fact, I’ve never experienced a more smooth deployment experience anywhere. There is nothing this cohesive in Node.

If you need one more reason, Deno is arguably the most secure runtime in the world. I would not be surprised to see more corporations start to use Deno for user submitted programs as we’ve seen recently with Supabase and Slack, for this reason.

I’m a textual person 90% of the time for the speed and flexibility. But I’ve found visualizations of my textual thoughts — after writing them — in the form of a mind map to be quite valuable in some circumstances. Mostly to communicate vision in a way that’s not top down.

At the end of the data, an endlessly tab indented text file is no different than a mind map. Instead of text files I use infinite list tools such as Dynalist, which have a great feature to convert your list instantly into alternative views such as mind maps.

https://help.dynalist.io/article/84-switch-to-another-view

You are right — because they built their trace data using the same data model as the error data (everything is an "event"), they are now running into difficulties with high quality trace data.

See here: https://develop.sentry.dev/sdk/research/performance/

Last year I spent some time integrating OpenTelemetry into a large monolithic frontend, using opentelemetry-js [1], which supports both node and web. At the time the spec was not 1.0 and the library was under active development. It required some effort contributing, but we're happy we went with OpenTelemetry instead of OpenTracing or OpenCensus.

There are a relatively large number of packages to install to get a basic setup (see the examples [2]). However, it's pretty straightforward. In short, you'll need to:

1. Instantiate the WebTracerProvider which allows traces to be created

2. Instantiate a span processor (such as BatchSpanProcessor) and a span exporter into the tracer provider. In the browser, you'll likely use @opentelemetry/exporter-otlp-http for the span exporter, which can be configured to send traces to any backend (e.g. Jaegar, Honeycomb, Lightstep, or DataDog).

3. Configure a context manager for tracing across async callstacks. This is the most complex part of tracing in my opinion, but it makes the trace data — specifically for JS — significantly more powerful. Since JS does not have thread local storage, they use a package called zone.js to make this possible. It is currently the *only* solution for this problem in browser JS. Node has the luxury of the standard library async_hooks. This was attempted to be standardized, but the effort has stalled [3].

4. Register automatic instrumentations. For example, you can automatically trace all XHR requests, fetch requests, page loads, and user interactions. With distributed tracing, you should always prefer automatic instrumentation whenever possible to reduce maintenance and leverage existing conventions. The document load instrumentation allows you to treat the server as the parent span to a given page load, from which the client will then be the root span to everything in the server. This is an extremely powerful concept that allows traces to viewed from the perspective of the user, encapsulating all requests and user interactions in a single trace with no manual instrumentation!

We also trialed Sentry's APM tool (also marketed as a distributed tracing tool). While it had pretty charts, dashboards, niceties like core web vitals, and integrated well with Sentry's error product, its utility as a distributed tracing tool is significantly less powerful than tools like Honeycomb. You will end up using a large amount of your user's bandwidth sending telemetry data that can't fully be leveraged in the Sentry UI. When I last used (in April 2021), the spans of a given trace could only be viewed in a specific part the UI and they couldn't be searched for in queries or used in charts. I'm unsure if this has been updated. But this is not the worse part. Because Sentry uses its own data model for traces, it is not compatible with open source standards such as OpenTelemetry or OpenTracing! The sales team will not tell you this during the trial. This means our entire backend, which was already instrumented with OpenTracing, would now also need to instrument Sentry's tracing (...if they supported the language) in order to connect frontend traces to backend traces. If your company uses Sentry everywhere, then this may be less of a problem. Each team I met with their sales team, I said the same thing: support OpenTelemetry, otherwise you are asking for us to further isolate our backend and frontend teams.

It looks like they have heard this opinion, as they have recently published a blog post about the evolution of the distributed tracing API, citing incompatibility with OpenTelemetry due to their data model. It will require a very large change for them to support this. Meanwhile, OpenTelemetry can be used with any tracing vendor, a large number of languages, the other major instrumentation standards (OpenTracing, OpenCensus), and any trace propagation format.

- [1]: https://github.com/open-telemetry/opentelemetry-js

- [2]: https://github.com/open-telemetry/opentelemetry-js/tree/main...

- [3]: https://github.com/legendecas/zones

- [4]: https://develop.sentry.dev/sdk/research/performance/

You are misreading. He's saying that rollup[1] was the only other option for bundling static assets besides webpack until esbuild was created. Rollup was created by Rich.

- [1]: https://rollupjs.org/guide/en/

For the long running scenario, why not use Links? The specification describes[1] a similar scenario and how links can be leveraged to causally relate spans even across trace boundaries.

As for the crashing scenario, this seems like an application-level concern. Ideally it is not waiting until the crash to send traces. Depending on the environment, the application could handle the crash and deliver the telemetry leading up to it before shutting down.

[1]: https://github.com/open-telemetry/opentelemetry-specificatio...

Khan Academy did a great writeup on their experience (including thoughts about HTTP/2) with various strategies for serving JS, such as:

- Single bundle

- No bundles (all separate files)

- Hybrid

https://blog.khanacademy.org/forgo-js-packaging-not-so-fast/

> I occasionally do high altitude climbs, and hikes, so I'm looking forward to upgrading to a newer model with continuous elevation readouts and SpO2 readings.

I also use it for this reason, but I've found that these activities can often be much longer than my the battery can last on my S6 in airplane mode with an activity running (~6 hours).

For this reason I'm considering a watch with better battery life built for this purpose such as Garmin or Coros. The recently announced Coros Vertix 2 has a mind-blowing 140 hours battery life with full GPS tracking [1].

I don't foresee Apple reaching this level of battery performance anytime soon, specifically because of the other reasons you list why the Apple Watch is useful. I wonder if we'll see a trend of people owning multiple wearables for specific reasons, with the Apple Watch being a daily driver.

- [1]: https://mobile.coros.com/vertix2/

VR has given me a new sense of imagination and creativity, similar to what some might experience with 3D printing.

Being able to perceive a digital space in three dimensions is a significantly different human-computer interface than a 2D screen. It feels like so much more is possible once you break into the extra dimension.

From the outside, VR definitely has a dystopian look to it. But from the inside, it can give a sense of "creativity unlocked" once you start thinking about how to build immersive experiences. This liberating mindset, in some ways, is the opposite of what it appears to be on the outside.

There seems to be a misconception that the Lighthouse score is linked to the page experience search rank update. Higher Lighthouse scores won't give you better SEO. Only better results from field data (albeit only Chrome field data) will impact your search results [1].

Lighthouse is only intended to be a guide (name checks out) for developers to identify potential opportunities to improve real-user performance. Core Web Vitals is how Google has decided to align lab and field data in a more unified way. Historically, this has been pretty difficult, particularly with interactivity measurements. For example, Total Blocking Time (TBT) is a lab proxy metric for First Input Delay (FID) — they don't measure the same thing. The team at Google has frequently communicated that the only true way to know is from measuring on real users [2].

While the metrics aren't perfect, they are taking in feedback to adjust how metrics are measured and weighted, such as with the windowed CLS update [3]. I for one have found the tools and browser support for measuring performance to have improved significantly, even in the last few years. Kudos to the Web Perf community, who I'm sure would appreciate any feedback.

[1]: https://support.google.com/webmasters/thread/104436075/core-...

[2]: https://web.dev/vitals-tools/#crux

[3]: https://blog.webpagetest.org/posts/understanding-the-new-cum...

Anyone know why the Spotify Web Playback SDK isn't supported on mobile?

The docs [1] say "It’s the same technology we use to power our Web Player experience", which seems to work fine on my mobile browsers. However, mobile browsers are explicitly listed as unsupported.

The docs also clarify it's powered by Encrypted Media Extensions, which is supported natively back to iOS11 and Chrome 42 [2]. There's also an actively maintained polyfill [3].

[1]: https://developer.spotify.com/documentation/web-playback-sdk...

[2]: https://caniuse.com/eme

[3]: https://github.com/google/eme-encryption-scheme-polyfill

I have to admit, this was first time I've considered trialing Apple Music after being a longtime Spotify customer.

Lack of browser support in a Spotify Web API providing free advertising for Apple Music. The irony!

+1 Would be super cool if this integrated with the Battery Status API for even more realism!

Looks like the spec is getting updated with more modern security and privacy practices.

https://www.w3.org/TR/battery-status/

In general, the term 'metaverse' is commonly used in the AR/VR space to describe virtual worlds. Today, in (virtual) reality it feels somewhat analogous to an "immersive operating system". It's the entry point for doing other things on a VR system.

Some examples: Roblox, Facebook Horizon, VRChat, NEOS

Another example is optical zooming.

Companies like Mojo Vision have already built a contact lens prototype that could power “superhuman” traits like this.

https://m.youtube.com/watch?v=pV52DF5IrEc

In Safari the reader view was able to hide them all for me. Not an ad blocker but definitely enhances the reading experience.

Sounds like you caught a drift of the Tetris Effect.

https://en.wikipedia.org/wiki/Tetris_effect

How do you connect to Bryant Park - 42nd street from Times Square? I have always walked above ground.

From the MDN docs:

"In ECMAScript 2015, let bindings are not subject to Variable Hoisting, which means that let declarations do not move to the top of the current execution context."

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...