HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
extensibleweb
manifesto
Web Development2013–2025
extensibleweb / manifesto

manifesto

The Extensible Web Manifesto

10Distinct people
19Mentions
0Explicit recommenders
335GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

The Extensible Web Manifesto

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year19 dated mentions

Observed mentions: 2013-06-10 23:19:11 UTC to 2025-09-15 21:03:13 UTC.

01232013-01-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20132014-01-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-01-01 00:00:00 UTC to 2016-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2016-01-01 00:00:00 UTC to 2017-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2017-01-01 00:00:00 UTC to 2018-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2018-01-01 00:00:00 UTC to 2019-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2019-01-01 00:00:00 UTC to 2020-01-01 00:00:00 UTC (exclusive): 1 mentions; 1 submissions, 0 comments20192020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2025

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20132013-01-01 00:00:00 UTC2014-01-01 00:00:00 UTC110
20142014-01-01 00:00:00 UTC2015-01-01 00:00:00 UTC000
20152015-01-01 00:00:00 UTC2016-01-01 00:00:00 UTC000
20162016-01-01 00:00:00 UTC2017-01-01 00:00:00 UTC101
20172017-01-01 00:00:00 UTC2018-01-01 00:00:00 UTC101
20182018-01-01 00:00:00 UTC2019-01-01 00:00:00 UTC202
20192019-01-01 00:00:00 UTC2020-01-01 00:00:00 UTC110
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC303
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC202
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC202
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC101
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC303
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC202

What Hacker News says

19 sources
To some degree, and to madlib your statement, alike how: C code is never going to be good as embracing the built-in features of the x86 asmcode and using minimal code to accomplish what you need. Which is to say, that isn't really a goal or objective, imo: it's an unhealthy prediction for misoptimizations, to worship the vanilla.js performance above all past. More-so, there were so many very very very unperformant web apps before React. So many incredibly bad ways to manipulate DOM. And the spiralling combinatorial possibilities of updating state yourself were gnarly, create enormous cognitive load on every dev in the org. I know I've just written a pretty big anti- post. But I feel both sides really strong. I don't want either extreme to be accepted. Inner Platform I see as good and necessary. But also I definitely hope for better someda
Read the rest
y, see us making lots of Inner Platforms, that might be much smaller / better organically interweaving Inner Platforms. Reacts flaws are significant, a full extra DOM, diffs, coarse grained updates (which I think maybe React Compiler tries to seek out?) all do so much but are a huge abstracting for an Inner Platforms, not necessary imo to what Inner Platforms would have to be. It's amazing how much React gets us, how much consistency & clarity of code & it's purpose (with its immediate mode ish rendering scheme), and the performance is overall stunningly good. But there certainly is significant overhead, lots of code to load & execution time for it. Rather than looking to return back, I want to look onwards. The "Inner Platform" idea is an amazing & useful framing. I want WebComponents to let us escape this, to be some common system we can agree too, but I suspect even with WebComponents—if they get any broader traction—we will eventually see "inner platforms", paradigms for use and interlinkage that go beyond the very basics of HTML (although Invokers radically and excitingly open up the space of component interacting with components in standard ways!). Maybe it's not so clear cut a decade+ later, but pieces like The Extensible Web Manifesto speak to a clear loud vocal acceptance of the web as a lower level platform, as a tool that can have higher level expressions built stop it. Theres an expectation of going further, architectures above. https://github.com/extensibleweb/manifesto Imo it sucks that we near a decade of React Uber Alles, stealing the oxygen that would nourish the web's flourishing. And there's hope for using more of the putter platform: that React as an Inner Platform does a lot of reinvention that maybe ought not be necessary. I guess the question I want to ask is, how little can we make our Inner Platforms, while still retaining the legibility of architecture? Can we decompose that Inner Platform into smaller interoperable pieces, protocols, for how things signal and flow, rather than it being a monolithic platform? What of the Outter Platform could be better used for performance and inter-op, to de-interiorize? It is dangerous and bad to me to demonize Inner Platforms, to attend only to notions of pure performance as the guiding factor. The karmic wheel imo needs to be going around faster harder, creating and destroying the inner platforms. We have a lot more to explore, have only a couple examples of what web architecture could be and right now the React Inner Platform is a thick boy of an Inner Platform. But it's not just getting rid of Inner Platform that's the goal.
In React is winning by default and slowing innovation
I think servo and ladybird are a testament to people believing in the web, not intent on throwing out the existing designs and beginning something new & different. Gemini and gopher both seem semi competitive with the web in that they target users. (Ipfs is just a transport; there's value there of course but it leaves more questions than suggestions.) But I really doubt the web is going to be disrupted or even budged by efforts that are so explicitly ultra-minimal, so bare bones text. Folks complain about the document model of the web being used for apps, which I personally feel is incredibly silly, that hypermedia being able to sing & dance like it does & having so many different framework styles validated the Extensible Web Manifesto https://github.com/extensibleweb/manifesto idea of HTML + platform APIs as a low level platform, putty w
Read the rest
e can forever reshape & mold to different architecture & use. If folks really want to get beyond the web though, the answer is definitely not just chopping off the capabilities, doing drastically less. We'd need a more bold encompassing media form, that's obviously better. I'm curious as hell to find out what that might look like but I see very few such bold ideas. Its crazy to me that the only vision, the only rabble rousing of note seems to be to do vastly less. Maybe we could ask Flutter why they think they deserve to be the future, why the apps their are better than web, but I expect more revolting disgusting "it's better for devs" "pixel perfect" answers without any actual progress for the user, with a status quo of what software is, and no principles & or fundamental enablement or interconnection wins. Its not gonna weave something better than the www. Too many visions are inwards, retreating, and so few imagine better connecting, richer media forms, looking outward beyond the singular developer distilled down app experience that made the web the force that rewrote computing that it is, that makes the web so utterly unique & special (& something great wealth should be funding & cherishing).
In Google Being Forced to Sell Chrome Is Not Good for the Web
> Browsers are massive, complex, and resource hungry. Sure, I'll just run my application inside another complex application inside a complex OS. What's another layer? But actually, raw JS, HTML, and CSS are too slow to work with, so I'll add another layer and do it with React. That's just your opinion, and you're overgeneralizing one framework as the only way. A 2009 mobile phone did pretty damned awesome with the web. The web is quite fast if you use it well. Sites like GitHub and YouTube use web components & can be extremely fast & featureful. Folks complain about layers of web tech but what's available out of box is incredible. And it's a strength not a weakness that there are many many ways to do webdev, that we have good options & keep refining or making new attempts. The web keeps enduring, having strong fundamentals that allow iter
Read the rest
ation & exploration. The Extensible Web Manifesto is alive and well, is the cornerstone supporting many different keystone styles of development. https://github.com/extensibleweb/manifesto It's just your opinion again and again that the web so bad and ke, all without evidence. It's dirty shitty heresay. Native OSes are massive, complex, and resource hungry and better replaced by the universal hypermedia. We should get rid of the extra layers of non-web that don't help, that are complex and bloated.
In WASM Is the New CGI
Ah yes, another web-grumbler, here to tell us to abandon the connected platform available on all devices that is hugely successful. It's just your opinion that the web isn't great for UI. It doesn't have much evidence (and you certainly aren't making any testable assertions). If the web was so bad you'd think native apps would be ruling the planet, would be vastly more popular & loved & be what everyone is trying to ship. But that's not the case. The web is everywhere and companies have full faith in the web and it's working. > But the web isn't great for building input UX (it's all bloat + jank and you have to completely reimplement the input elements to do anything useful, on top of shifting sand) Theres a school of thought that wants a complete & total solution, handed to them, that does everything, that everyone uses. These people are
Read the rest
ideologically going to hate the web. Even though there are countless really really good well made component libraries out there, the fact that it's not all baked in upsets a certain type a lot. But, this is the strength of the web. The web is free to shift & change & emerge new patterns & ideas, is free to have new and different components emerge. This is a strength, this is why the ecosystem keeps steamrolling everyone else: everyone else is singular & tries to be complete, and the web is legion & perpetually innovating on the edge in a way classic platforms never can. Some people see weakness, but the ideas of the low level Web Extensibility Manifesto keep the web buoyant & iterating for developer and user happiness in ways no other system has remotely been able to achieve. https://github.com/extensibleweb/manifesto The other good news is that the OpenUI community group got formed & is upstreaming into HTML more components. Popovers and dialogs are both about to be fully usable by anyone. There's a ton of drive to improve the core elements available on the web. While also not harming that extensibility. https://open-ui.org/ > the data can be shared or backed up somehow sure; that's just file hosting with a collaboration layer maybe. Being connected software is the new base expectation, is table stakes. You have to have connected software to succeed. And the desktop doesn't have this. It's all special snowflake systems, all build it yourself. It's the default for software to be connected on the web. And on the web it's the default that it'll run on you desktop, your phone, your tv, your fridge, and all your neighbors friends and coworkers device. For something like a notion clone here, I think most users would have an enormous enormous expectation that this kind of groupware be on the web. Trying to reinvent a collaborative knowledge capture paradigm on desktop sounds absurd & sounds like folly. The desktop has no starting place for developers nor users. When I think of performance specifically, I think of how much opportunity the web has. Any popular software platform is going to have an absolutely gobsmackingly huge amount of really bad software written for it. And that challenge is magnified greatly in the connected age where vastly more data lives outside of your computer than on it, where your computer is at best a local cache. We will always be beset by unideal software, by bad architectures, by poor data remoting practices. But that doesn't make me sad or want to go run away to the many different native platforms, to go trip over all the same data syncing & data architecture problems there. It makes me excited to see us iterate and improve, makes me so happy there are brave people cranking out Svelte and Stencil and Lit, makes me happy we are moving forward speccing out signals and observables (although having two similar but different async data constructs maybe is a misfire, IMHO), makes me happy we are getting wasm and still so early but wading slowly off the main thread and into workers. There's so much opportunity here to iterate & improve & grow, even with what we have, and there's been such strong help & improvement ongoinglg given to the platform layer from such a wide coalition of spec authors and passionate wicg.io community members. World wide web on & on.
In Install Docmost – open-source Notion Clone
I don't see why Origin Private File System needs some fully virtualized nonsense. You can just create some fuck off far out directory for the site for this cause. Should be fine. There's already pretty safe secure & altogether sensible options for giving websites access to files. Alas it's all via even slower even worse abominations that File Access Handles, because spec authors swear it would be hell on earth if they didn't quintuple buffer every read or write, will swear we could never ever trust devs to ever possibly do a good thing. There's been such a constant hedging that being slow & adding layers of safety to io is necessary and it's taken literally decades to get even these crap ass concessions. I know this is impolite and I'm sorry but what cowardice, what unrelenting sad clutching of pearls. What utter betrayal of Extensibile W
Read the rest
In How we sped up Notion in the browser with WASM SQLite
PPK (whom you cite) is an extreme conservative for the web, as are many many forces about. I don't think it's possible to have this conversation. People have a deep belief about what they want from the web, and a ton of people want it small & tiny & less than it is. People are desperate to believe Google has some huge weird agenda. The agenda seems pretty obvious: build a great hypermedium. Build the best protocol for information the world has. Because Google already is everywhere, already has the best search engine, already has a great first party relationship with users, as they start every journey into the web. Google' agenda isn't to block out or hurt other people, it's to be better & do better than all the native apps, to make the connected online experience simply better. And they're winning. They're doing it: they're making the con
Read the rest
nected hypermedia world the best option for computing, by having great capabilities, by making it easy for webdevs to do amazing things quickly, by having a good low-level capabilities that endless frameworks can arrange as they see fit, pursuant to the ideals of the Extensible Web Manifesto. https://github.com/extensibleweb/manifesto They're not being mean or unfair at all. Chrome has the most fair, reasonable, upstream-first, pro-social way of developing software the world has ever seen. https://www.chromium.org/blink/launching-features/ is higher responsibility, more responsive & shared-early, with more safeguards than almost everyone else on the planet, and they do it in public. Their works are specified, they seek review early, they get architecture & security group reviews. It's unprecedented in extreme how far Google goes to make sure web development is open. But people just cannot possibly imagine there's not some secret cause. Everything is met with hostility, weird personal attacks, & debasement. You basically never hear anyone who is critical but also reasonable or sympathetic or understanding: this is the tell. Almost all the negative feedback against Google & Chrome is to the wall outrage, is 100% on one side, lacking in nuance or balance. There's no recognition of good, no appreciation of the attempt at process. This is a cruel & savage thing the internet has ganged up to do, to be so lopsidedly angry and mean, with so little willingness to recognize optimism, growth, hope, trying, and effort, which have already been such an amazing boon to us.
In Baseline: a unified view of stable web features
But your services have to support the Connect protocol. You can also ship services that support gRPC-Web directly too & run without a proxy. This is definitely a step up, nicely convenient. But also, it has downsides too. gRPC is incredibly well supported by a huge number of observability tools and service-layers/service-mesh systems. Few have support for gRPC-Web. Which if any have support for Connect-Web? In general, it's just massively sad that the browser never got around to making HTTP Push useful for protocols. gRPC should have been positioned to do great things, was a very common-sense overlay atop HTTP2 that provided just a little more semantics to say how things ought work. It triangulated nicely on where we were going, at it's inception, back in 2014/2015. But the browser basically never evolved, never gave developers access to
Read the rest
do the good stuff we thought we'd start to have access to. I still see brand new specs that shout out to the Low Level Extensibility Manifesto[1], but for some reason, in terms of the most base layer of the web, HTTP, this simple guidance has been roundly ignored & the capabilities were never delivered. So gRPC has been stuck with a pretty ok protocol, & frustratingly discompatible browser. [1] https://github.com/extensibleweb/manifesto
In Connect-Web: TypeScript library for calling RPC servers from web browsers
> I just wish WebRTC wasn't so prescriptive of DTLS/SRTP. There was a webrtc-webtransport spec, but it got renamed/retasked to p2p-webtransport[1]. It got renamed/rebuild ~1 year ago[2]. Feels like a pretty strong indicator of webrtc being deconstructed, but whose to say this goes anywhere. We'd also need webcodecs. It's somewhat scary & also somewhat exciting thinking of the one good, working, browser supported standard being ripped into pieces (p2p-webtransport, webcodecs, more) & being user-implemented. Having the browser & servers have a well-known target is both great but also perhaps confining. If we leave it up to each site/library to DIY their solution, figure out how to balance the p2p feeds, it'll be a long long time before the Rest of the World (other than the very big few) have reasonable tech again. WebRTC is quite capable &
Read the rest
a nice even playing field, with lots of well-known rules to enable creative interopation. We'd be throwing away a lot. I'd hoped for webrtc-webtransport, to at least keep some order & regularity, but that seems out, at the moment. But Webrtc-nv is still ultra-formative; anything could happen. The rest of the transport stack is also undergoing massive seismic shifts. I feel like we're in for a lot of years of running QUIC or HTTP3 over WebRTC Data-Channels and over WebTransport, so we can explore solutions the new capabilities while not having to ram each & every change through with the browser implementers. It feels like a less visible but far more massive Web Extensibility Manifesto moment ("Browser vendors should provide new low-level capabilities that expose the possibilities of the underlying platform as closely as possible."), only at sub-HTML levels[3]. The browsers refused to let us play with HTTP Push, never let appdevs know realtime resources had been pushed at the browser, so we're still debating terrible WebSocket vs SSE choices; terrible. I think of gRPC-web & what an abomination that is, how sad & pointless that effort is; all because the browser is a mere glimmer of the underlying transport. I feel like a lot of experimentation & exploration is going to happen if we start exploring QUIC or HTTP3 over WebTransport. Attempts to reimagine alternatives to WebRTC are also possible if we had specs like p2p-webtransport, or just did QUIC over DataChannels. Running modern protocols in the client, not the browser, seems like a semi-cursed future, but necessary, at least for a while, while we don't yet know what we could do. The browsers are super laggy, slow to expose capabilities. [1] https://github.com/w3c/p2p-webtransport [2] https://github.com/w3c/p2p-webtransport/commit/63370be4bb61a... [3] https://github.com/extensibleweb/manifesto
In Video Live Streaming: Notes on RTMP, HLS, and WebRTC
I can't help but feel like this is the worst. Every time we step away from HTML & the DOM & into a further farther reach of abstraction, into something custom crafted & artisinal, we lose our valuable common heritage. We flea from common understandability & recurse into something ever more unique & virtual. In the process- as is the case with Google Docs[1]- we lose things like the ability for web extensions to work, if this is a web hosted vscode instance (vscode server, openvscode, code-server, others). Running a debugger against this part of vscode- web or native- now yields only garbage junk information. The author of this VSCode Canvas renderer chimed in in the Google Docs canvas thread to talk about some of the challenges here[2], which I think still undersells how dangerous this plan is, & also doesn't discuss how far (or not) we'v
Read the rest
e gone to optimize the DOM renderers. Right now this is just the terminal. I think- "it could be worse". But it chills me deeply that the terminal is now no longer real information. It's now just a happenstance jumble of pixels, powered by only it's own inner logic & a unique maze of libraries. Big tech keeps optimizing and optimizing, & the motive we keep being sold- this is for your good, this helps you- is one I frankly have a very hard time negotiating with myself. De-webbifying the web, de-commonizing the common platform- as Facebook has done by virtualizing the DOM- feels like this ever-running big-bang from a truthful original universe into a sparse, cold, expanding universe where each little fragment defines itself, where the common hypertext medium no longer means anything. I keep waiting for some moments of contraction, some coming back together, for things to make more sense again, to recontract into something more solid. React's first WebComponents PR[3] is a notable re-contracting, re-platforming- a powerful act I frankly didn't expect, so rare as to feel practically unprecedented. I realize much of this flexibility, the demonstrated versatility of the web & usage of the various pieces of it represents much of it's strength. The platform being a low-level platform where higher level platforms can be created is amazing; the Extensible Web Manifesto[4] speaks to that emergence of newer higher levels systems. And right now we're in early days, just starting a precambrian explosion of higher level web, as technology like WebAssembly only just begins to become real- still so early, still way pre-pre- Interface Types[5]/Host Bindings, only just the crudest emulation beginning in via projects like Rust's wasm-bindgen / web-sys. I am happy we are still exploding. We have so much more to exlpore. But gee I also question so much when big enterprises turn hypertext into pixels. To move compute into webassembly is a bold leap but the hypertext can survive, the DOM is still truth. It's so uncertain to me, feels like so much might be lost when giants like Microsoft or Google yank out the HTML & replace it with pixels, pushed into our faces. It feels like betrayal, like sabotage, like we're giving up truth. [1] https://workspaceupdates.googleblog.com/2021/05/Google-Docs-... [2] https://news.ycombinator.com/item?id=27131659 [3] https://github.com/facebook/react/pull/22184 https://news.ycombinator.com/item?id=29505332 (16 days, 0 comments) [4] https://github.com/extensibleweb/manifesto [5] https://github.com/WebAssembly/interface-types/blob/main/pro...
In VSCode terminal from DOM to <canvas>
The main problem isn't CPU and GPU performance, those problems had (to some extent) already been solved with asm.js and WebGL, at least for some types of games. It's all the other APIs and the general "feature churn" in browsers which are problematic for games. Some examples: - The fullscreen and pointerlock APIs show popup warnings which behave entirely differently between browsers. - Timer precision has been reduced to around 1ms post-Spectre/Meltdown, and jittered on top. This makes it very hard to avoid microstuttering (we don't even need a high-precision timer, just a way to query the display refresh rate... but guess what, there is no way to query the display refresh rate) - WebAudio is ... I don't even know what... all we need is simple buffer streaming but we got this monstrosity of a node-based audio API. And the only two ways to
Read the rest
do this in WebAudio are either deprecated (ScriptProcessorNode) or not usable without proper threading (audio worklets), and guess what, threading is also disabled or behind HTTP response headers post-Spectre. - Games need UDP style non-guaranteed networking, but we only get this as a tiny part of WebRTC (DataChannels). ...and the list goes on. In theory there are web APIs useful for gaming, but in practice those APIs have been designed for entirely different and very specific high-level use cases (such as creating an audio synthesizer in a webpage, or creating a video chat solution for browsers), and those rigid high-level APIs are not flexible enough to be reassigned to different use cases (like games). The web needs a "game mode", or better a "DirectX initiative", a set of low level APIs and features similar to WASM and WebGL/WebGPU, and if not designed specifically for games, than at least low-level and generic enough to be useful for games. This isn't a new idea, see the Extensible Web Manifesto: https://extensiblewebmanifesto.org/ (backup: https://github.com/extensibleweb/manifesto) But the ideas presented there didn't seem to have much of an impact with the web people (with the notable exception of WebGPU).
In First Public Working Drafts: WebGPU and WebGPU Shading Language
Part of AMP (1) is a web component library grounded in the extensible web manifesto (2). The plan was that the browser vendors give developers deeper access so that they could test new elements/standards through web components and polyfills. The AMP component library is one example of this, and stories are one of their forms. So basically if you use their tags to structure your content, it creates a ig/sc style Web Story. The structure that they have is (3): Story -> Pages -> Layers -> Elements Each page represents a tappable screen, Layers occupy the full screen, stack and have layout defaults like fill or lower-third and Elements can be regular html elements or other AMP components. I think that it's a neat way of organizing pages of information and made a clojure wrapper around it here: https://github.com/rainbow-bamboo/sargam 1. http
Read the rest
In Google Stories
Agreed. And importantly, the fragmentation of the Javacript ecosystem is on purpose: https://github.com/extensibleweb/manifesto I think about the fragmentation that shows up in the form of multiple frameworks and patterns as a necessary part of that. It's not something that I want to fix. So to draw a line and say, "extending core Javascript features is fine, but compiling into Javascript isn't" -- I just don't get that. Typescript is a testing ground not just for typed programming in general, but also for features like decorators and meta-programming features. It's good to have a diversity in what people are building and using, that's how we get real world data on what works.
In TypeScript is weakening the JavaScript ecosystem
Nonetheless, its still mildly concerning that smaller players in the browser space are finding it difficult to keep pace with all the new APIs being introduced to the web these days. Even Microsoft sort of gave up and killed their browser engine in favor of a Chromium fork. It's a tricky situation with no obvious solutions. The Pale Moon dev's plea to slow down isn't going to work; devs want these new features and they're not going to stop using them just because a smaller browser developer with no significant market share can't keep up. There is, perhaps, the beginnings of a solution with the Extensible Web Manifesto[1], which aims to shift the focus of browsers from implementation of many high-level features to instead focus on smaller, simpler low-level features which high-level features can then be built on top of. (Though ironically
Read the rest
, web components are a part of this movement.) CSS Houdini[2] is one such feature which seems like it might be relevant in this specific situation (though whether it's helpful I have no idea; in the short term I suspect it might just translate to a lot more work). [1]: https://github.com/extensibleweb/manifesto [2]: https://developer.mozilla.org/en-US/docs/Web/Houdini
In Please consider not adopting Google WebComponents
> Technically, this can be implemented already. However, for successful adoption, a standard interface has to be defined. This is literally the opposite of how the web works. The web is based on the Extensible Web Manifesto[0], where first we come to a consensus and see widespread adoption, and then we make a standard that reflects that consensus. > We have a fantastic and highly secure execution environment from a host perspective. But from the guest perspective, that very same environment looks like MS-DOS, where memory is a giant playground with no rules. Well, yeah. Add me to the list of people who are just kind of confused about why fixing C's problems is the responsibility of the browser, and why people thought that it was ever a priority for WASM. WASM is a VM-like isolation chamber for low-level code. It's not designed to make you
Read the rest
r code safe, it's designed to protect the host environment from unsafe code. I've seen multiple people make the argument that manually laying out memory in WASM is a design flaw rather than one of the biggest points of the entire implementation. Manually laying out memory with close to zero restrictions or paradigms or safeguards is the thing that makes WASM good. I feel like I missed something, I don't know where people got this idea that WASM was trying to be a higher level tool. It's an extremely low-level language-agnostic compile target for both safe and unsafe languages, and languages that care about safety should add their own safeguards as they see fit. [0]: https://github.com/extensibleweb/manifesto
In WebAssembly doesn’t make unsafe languages safe

Showing the 15 most recent of 19 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.