HN Theater @HNTheaterMonth

There was an idea for this in 2011: "Atlantis"

https://www.microsoft.com/en-us/research/publication/atlanti...

https://scholar.harvard.edu/files/mickens/files/atlantis.pdf

https://www.youtube.com/watch?v=1uflg7LDmzI

I used to get really angry at CSS because of all of the things that made it a bad fit with component-based systems like React. It made me so unhappy that I worked full-time for about nine months on this project, which was a React-like component system that rendered to canvas. https://github.com/maxharris9/layout

I got pretty far! But I gave up working on it when I realized that I was going to be pushing this boulder uphill for years.

So what changed? I picked up Swift and SwiftUI, and it turns out that some of the ideas that I had were the same ones the SwiftUI folks went with!

For all the web has given us, I think its APIs are holding us back now. I still think we need something open and decentralized that competes with the App store and Play store, but one that offers apps that use basically the same APIs and technology that the native apps use.

Last thing: I know Apple cripples browsers on their platforms. I've run into all those issues personally in my work! That still doesn't make the web the right thing. Here's James Mickens telling us how to fix the browser's busted architecture: https://www.youtube.com/watch?v=1uflg7LDmzI

⬐ yagodragon

> I still think we need something open and decentralized that competes with the App store and Play store, but one that offers apps that use basically the same APIs and technology that the native apps use.

Take a look at Flutter(which is similar to swiftUI). I know Google is behind it but it's so damn good. The JS community spends so much time creating new tools on top of older tools to achieve simple things that should be trivial in 2020. Meanwhile, flutter is typescript+react+webpack+component library + a bunch of npm dependencies(because dart has a proper standard library) + advanced styling/layout and animation primitives inside the programming language + amazing IDE support + compiler that generates optimized AOT native code.

Flutter Web is a huge bet though because it completely throws away every web tech and builds UIs on top of <canvas>. That way you get the same API's you get on mobiles. The results are not good right now but alongside Microsoft's Blazor they are the only technologies competing with the broken web landscape.

⬐ untog

Improvements like web components encapsulating CSS make it a much better fit for component development. Just a shame React doesn’t support the API like other frameworks do.

⬐ runawaybottle

I thought React team was working to support web components?

⬐ untog

I hadn’t heard that. Very positive development if so.

⬐ filleduchaos

This is part of why it bemuses me to see web developers cling so hard to using HTML/CSS beyond the browser. I'd much sooner tangle with a proper UI SDK designed from the start to support applications than fight with a layout/painting engine that relies on a document model. The sheer inability of CSS to handle dynamic heights should be frustration enough for anyone.

⬐ deergomoo

Even layout aside (I'm hoping Houdini will eventually bring some form of constraint-based layout to browsers), HTML is the lamest UI toolkit going.

We've got a handful of basic form inputs, incredibly inflexible tables, and some semantic rectangles. That's basically it.

Even the form inputs can be a pain. It's insane to me that the only way to change the background colour of a checkbox is to hide it and build your own with CSS hacks (pseudo-elements etc.).

I guess the fact that any element needs to function purely from markup without any code severely hampers them, but I can't believe how much time we're all wasting having to build things as basic as pop-out menus by hand.

⬐ Vrondi

Somebody is showing their ignorance of what HTML is.

⬐ deergomoo

I know exactly what HTML is, I’m just not happy that we have to use it for something it’s very obviously not suitable for.

⬐ danShumway

> HTML is the lamest UI toolkit going

I will die on this hill. HTML is not a UI toolkit or an SDK. It is a user-facing interface.

I know it gets presented as a toolkit, I know that on some level it overlaps with a toolkit/layout language. But the most important thing HTML does is it provides a plain-text user-facing interface for an app.

Complaints like this are kind of like arguing that the terminal is a bad layout tool. I guess? But many of the things that would make the terminal into a better layout tool would get in the way of forcing developers to provide a pure-text interface for their apps.

In the same way, many of the features people want to pull into HTML (data-bindings for tables, content reflow between arbitrary elements, arguably a lot of the custom element/template work that Google is doing) are kind of counterproductive once you start looking at HTML as an interface instead of as a programming tool.

⬐ deergomoo

This is exactly my point though. It’s not a UI toolkit, but if you want to write applications for the web you have to awkwardly shoehorn it into one. There is no alternative.

It’s not fit for the purpose of building applications. I strongly support the idea of an alternative.

⬐ danShumway

> but if you want to write applications for the web you have to awkwardly shoehorn it into one.

No, you have to treat it like a render target. You can write your applications with another UI toolkit, you just have to be able to render to DOM.

To go back to the terminal analogy, the terminal is the end-user interface. It's not a framework or a toolkit. What you're complaining about isn't that the terminal is a bad UI toolkit, you're just complaining about supporting the terminal in general.

> I strongly support the idea of an alternative.

The only way that alternative would be easier to work with is if it didn't force you to render your visual state to a pure-text XML-based UI. But getting rid of that requirement would be bad for the end user.

It's annoying on purpose, because the default render target for not just your documents, but also your applications, should mostly be a pure-text XML-based tree representing your current state. It's a user feature, not a developer feature.

I mean, I can think of a lot of ways to make web programming easier if we don't care about the format of the end-user UI. It would simplify things dramatically if we didn't need to care about stuff like responsive design or resizable text. But the beauty of HTML is that by default, the easiest way to build a web application just happens to be the way that supports screenreaders, adblockers, scraping, graceful degradation, responsive layouts, etc...

HTML encourages even junior developers to fall into a pit of success by forcing them to think about the accessible text interface first, before they're allowed to think about what the pixels on the screen will look like.

⬐ deergomoo

> To go back to the terminal analogy, the terminal is the end-user interface. It's not a framework or a toolkit. What you're complaining about isn't that the terminal is a bad UI toolkit, you're just complaining about supporting the terminal in general.

If I wanted to write something like a high quality drawing tool and my only option was to use the terminal, you’re damn right I would be complaining about it.

Now I understand saying “my only option” is somewhat facetious, as if I care about it so deeply, obviously I should just write native software. But we are clearly moving to a web-first future, and I just don’t think the platform is a good foundation for application UI.

You’re implying that there’s ultimately no difference between a UI library that renders to HTML and one that renders to a grid of pixels in a native app; I am making the argument that HTML is sufficiently poorly suited for non-document purposes that it drags the overall quality of software down.

> The only way that alternative would be easier to work with is if it didn't force you to render your visual state to a pure-text XML-based UI

That is exactly what I’m suggesting.

> It's annoying on purpose, because the default render target for not just your documents, but also your applications, should mostly be a pure-text XML-based tree representing your current state

Why? I am not convinced there are significant benefits to a text-based format over a binary one, other than ease of reverse engineering. I would also argue that HTML doesn’t represent your current state, it represents the state when the page loads. That state is then modified, often in a rather opaque manner, by JavaScript. If we’re going to stick with something text based, clear data binding as part of the markup would be much more beneficial imo. Again: I feel the principle holds just fine for documents, but not application UI.

> But the beauty of HTML is that by default, the easiest way to build a web application just happens to be the way that supports screenreaders, adblockers, scraping, graceful degradation, responsive layouts, etc

It’s the easiest way to build a web app because it’s the only way to build a web app. And while I will grant you that scraping and adblocking is fairly unique to the web, any “native” UI target worth its salt has great accessibility support. As for responsive layout, how long have we had resizable windows where the contents adapt? This is not something the web pioneered.

> HTML encourages even junior developers to fall into a pit of success by forcing them to think about the accessible text interface first

I guarantee you that junior developers are not writing accessible web apps without significant effort. Maybe if they start off with something fairly document-like, sure. But once you start adding modals, popovers, and other controls that the browser doesn’t provide, things get difficult to do right pretty quickly.

⬐ danShumway

It's worth pointing out, there is an escape hatch on the web: Canvas.

Canvas isn't the default because most apps don't need that escape hatch -- I will make a strong claim that the majority of native apps are just interactive documents and could easily represent their states in XML. I will make a stronger claim that the majority of native apps that require pixel-level control workarounds only need them for a couple of sections of the app, and the surrounding interface is just an interactive document. If you're building a drawing app, yes, you need an pixel buffer that you can render to. But the rest of your menus and main interface are probably just XML.

This is another hill I'm willing to die on; application UI isn't special. Yes, having some control over stuff like Canvas is important. And there are categories of apps like games that genuinely don't fit into a document model. But for the most part people should be able to represent their state as a plain-text interface, it's kind of weird to me if they can't. For the most part, most application UI state is not that complicated.

> I would also argue that HTML doesn’t represent your current state, it represents the state when the page loads. That state is then modified, often in a rather opaque manner, by JavaScript.

The Javascript is not important. When that state gets modified, it gets rendered to the DOM. The idea behind the web, even for web-apps, is that if you open the inspector in your browser, that should be the current user-facing state at that specific moment.

> Why? I am not convinced there are significant benefits to a text-based format over a binary one other than ease of reverse engineering

The only way a screenreader works is by reading your interface out loud. If your interface can't be entirely represented as a series of words, then how are you making it accessible?

The browser forcing you to target text (Canvas aside) is important because it means the text interface and visual interface can't be separated. That makes it harder for you to split your app into two separate interfaces that might diverge in features and abilities. By default, the functionality you offer is available to everyone, even users who aren't consuming your app using the visual interface.

As a side note, I think ease of reverse engineering is a big deal that shouldn't be discounted. We should be trying to make it easier to reverse engineer native apps.

> how long have we had resizable windows where the contents adapt?

Then why haven't native developers found out how to do it yet? Why do all of the Linux apps I run have terrible HDPI support? Why has it taken us so long to get something incredibly simple and straightforward like fractional scaling working on the Linux desktop?

> But once you start adding modals, popovers, and other controls that the browser doesn’t provide, things get difficult to do right pretty quickly.

Well... use a framework for that. Use a React modal, they'll be accessible. The point I've been getting at is that you shouldn't think of HTML as the thing you write your app in, you should think of HTML/DOM as the thing your app renders to. It's fine to use a UI toolkit on top of that, in the same way that it's fine to use a framework that runs on top of something like X11.

The browser doesn't provide popovers and modals for the same reason that OpenGL doesn't provide those things. Browser elements are primitives, they just happen to be easy enough to use that you could theoretically target them directly. Junior developers don't need to write advanced popovers, and the goal isn't to force them to do that. It's to provide a common set of user-accessible elements that advanced popovers are built out of, regardless of what UI toolkit you're using.

⬐ deergomoo

The problem with canvas is that being purely graphical, it's too far in the opposite direction—it's just a bitmap. It's akin to shipping a native app where the UI is just a JPEG that matches clicks on a co-ordinate with actions. The sweet spot is somewhere in between.

> The idea behind the web, even for web-apps, is that if you open the inspector in your browser, that should be the current user-facing state at that specific moment.

There's absolutely nothing there that requires UI to be delivered as a textual XML tree to work. The browser will end up rendering a tree of nodes regardless of its representation, and there's no reason that can't be inspected. For example, in Xcode I can pause execution of an iOS app and poke around the view stack to see what's going on.

> The only way a screenreader works is by reading your interface out loud. If your interface can't be entirely represented as a series of words, then how are you making it accessible?

As above. I'm not suggesting we render text by blasting pixels into a bitmap; with this imaginary alternative to HTML we would still tell the browser to render some text, which can then expose the necessary accessibility hooks. Again look to iOS; it has arguably best-in-class accessibility support.

> That makes it harder for you to split your app into two separate interfaces that might diverge in features and abilities. By default, the functionality you offer is available to everyone, even users who aren't consuming your app using the visual interface.

If I'm honest I'm not sure what you mean here, can you clarify?

> As a side note, I think ease of reverse engineering is a big deal that shouldn't be discounted. We should be trying to make it easier to reverse engineer native apps.

Agreed.

> Then why haven't native developers found out how to do it yet? Why do all of the Linux apps I run have terrible HDPI support? Why has it taken us so long to get something incredibly simple and straightforward like fractional scaling working on the Linux desktop?

¯\_(ツ)_/¯ Lack of interest? Lack of commercial incentive? HiDPI works flawlessly on macOS and has for years. Not to mention that the web doesn't really fix that problem. If the browser was poorly written and had bad HiDPI support, then so would all your web apps.

> The point I've been getting at is that you shouldn't think of HTML as the thing you write your app in, you should think of HTML/DOM as the thing your app renders to

Okay, I'm really not disagreeing with you here. My argument is that HTML/DOM as a render target is annoyingly limited in many small ways that waste developer time and create a worse overall product.

> The browser doesn't provide popovers and modals for the same reason that OpenGL doesn't provide those things. Browser elements are primitives, they just happen to be easy enough to use that you could theoretically target them directly

I don't think this argument stands up at all. Does OpenGL provide form inputs? Buttons? Semantic content regions? The crux of my argument is that HTML elements are neither primitive nor flexible enough to be a good basis for UI frameworks, nor rich enough to not require UI toolkits. It's stuck in between, which is why I called it a lame UI toolkit to begin with.

I fear you may think I'm arguing in favour of something I'm not. I don't think we should be replacing web apps with a big list of drawing instructions, I'm merely saying there are a lot of things that have been par for the course in GUIs for 20-30 years that are significantly harder than they should be to achieve with HTML+CSS. I mean hell, I don't really care if some alternative platform is text-based or not, I just think text has minimal benefits and binary would be more efficient.

⬐ danShumway

> The browser will end up rendering a tree of nodes regardless of its representation, and there's no reason that can't be inspected.

Well, wait, how much do we disagree here?

When I talk about HTML, the tree representation is the part I care about. I'm not delivering new HTML documents for every change when I write an app, I'm using something like JSX, or Hyperscript, or even in a pinch the core DOM manipulation libraries. I can still define my interface inside JS, and in the future once the bindings get set up I'll be able to define it using WASM in any language.

> I'm not sure what you mean here, can you clarify?

If an app has an accessible view and a visual view, it's possible for the features that each "version" supports to diverge. Blind users will often be given a lower quality alternative as an afterthought rather than a full-featured application.

By forcing the visual representation of the app to be based on top of the accessible (text-based) representation of the app, we can (mostly) force the two experiences to be the same. Escape hatches aside, the developer can't neglect the accessible interface, because adding features to the accessible interface is the only way to get them into the visual interface.

> Not to mention that the web doesn't really fix that problem. If the browser was poorly written and had bad HiDPI support, then so would all your web apps.

Doesn't it? It's not that the browser is scaling the web page, it's that CSS by default handles HDPI and reflow properly. Any browser that implements CSS properly will have good HDPI support, the spec is good at scaling and handling content reflow at its core.

When I call out Linux, I'm specifically calling out the idea that we needed a special Gnome mode that rendered our applications to a separate buffer, resized that buffer, and then printed it to the screen. To me, that means the GUI toolkits these apps were based on aren't being used in a way that can handle multiple font sizes, device orientations, input methods.

> I fear you may think I'm arguing in favour of something I'm not.

Maybe I do?

You bring up Swift UI, but Swift UI is a declarative, tree-based user interface that's accessible by default. Part of the reason accessibility works on iOS is because of the design patterns that I'm talking about above; design patterns that came from the web.

Swift exposes a set of common semantic components that developers are forced to use, those components have common controls built into all of them like standard ways to adjust sliders. And what limited styling options that Swift offers look a heck of lot like CSS -- just a bit more limited and managed through attributes. I'm immediately reminded of something like D3 when I look at example Swift UI code.

So when you look at Swift's declarative UI vs something like the DOM/CSS, what's the core difference that you see? What's the thing that you wish the DOM was copying from Swift?

To me, the big difference between Swift and the DOM is just the abstraction level. Swift's declarative UI is a higher-level framework that forces more visual consistency and provides more high-level tools, at the cost of being much less customizable. But one of the big ideas behind systems like React and Components is that you can write interfaces using high-level components that conform to a specific style guide -- you don't have to work directly with divs.

So if the problem just boils down to "HTML should have more high-level components like modals and popups", that's something that we try to handle in userspace, because (frankly) the web has a much wider reach and platform support than Swift does, and standardization of how everything looks and acts is a harder problem to solve on the web for high-level components than it is on iOS.

That being said, the tree-based, semantic, final interface is the part of HTML I care about. If someone thinks we can do better, and they think there are better primitives we could expose, I'm not opposed to that. I don't think HTML is perfect, and I certainly don't think CSS is perfect.

If the disagreement boils down to that, then... I dunno, maybe there's not as much disagreement then. Typically when I talk to people about this, they are arguing that we should be replacing web apps with drawing instructions. Look at the linked talk from maxharris you originally applied to -- it's explicitly talking about getting rid of a standardized, semantic tree-based text representation of the current state and handling interfaces by pushing pixel buffers.

But it kind of sounds like that's not what you want, it seems like you want a different set of HTML tags and a different document reflow model in CSS? If so, that's a position that I'm much more sympathetic towards, even if I would want to hear more details before jumping on board.

⬐ filleduchaos

> It would simplify things dramatically if we didn't need to care about stuff like responsive design or resizable text.

...sincere question, have you ever actually used a native UI SDK?

⬐ danShumway

Yes.

Now, I have not used Flutter in specific, but from what I can see from its documentation, it doesn't support `em` units, so I can't base widths off of the current font size. The recommendations I'm seeing online for doing responsive design are to do device queries for the layout or to do percentage-based box sizes.

Again, I haven't used Flutter, so maybe it's better than the online tutorials I'm looking at give the impression of. But I'm having a real hard time imagining how I would recreate the functionality of CSS Grids or Flexbox using that kind of system.

Some native frameworks do a much better job. I think GTK is pretty good (although, suspiciously, GTK has ended up copying a lot of CSS features, so take from that what you will). But even there, it's worth noting that the developers behind most of the apps I'm familiar with aren't really taking advantage of modern GTK features.

I have an Arch install with the desktop split between a 4K monitor and a normal 1920x1080. I also maintain a Manjaro install on an HDPI Surface laptop with an odd aspect ratio. By and large, the native apps I use are mostly terrible at handling these scenarios. In comparison, most websites I visit are handling weird aspect ratios and 2x scaling pretty well.

I'll also give a shoutout to Mac, which I'm not familiar with a developer platform because heck that, but I assume has decent UI frameworks because more of the apps I use on Mac actually handle resizing nicely.

In any case, the point I was making was not just that the web is uniquely good at responsive design. Responsive design is one of the easiest problems that the web is solving. Now show me a native toolkit that can match the web at allowing users to override styles or block/replace UI elements. The significant problem that the web is solving is forcing state to be represented in an XML tree. That's the important part, responsive design is just one of the advantages that come from that.

⬐ dragonwriter

> Now, I have not used Flutter in specific, but from what I can see from its documentation, it doesn't support `em` units, so I can't base widths off of the current font size

Can't you just use the fontSize property and multiply it by whatever number you were going to use for ems (or maybe multiply fontSize by textScaleFactor first, depending on how rigorously you want to lock to text.)

⬐ danShumway

Is the `fontSize` property in Flutter user-customizable? If so, yes that would work fine.

But it would be a weird argument to say that Flutter represents an evolution over CSS if right from the start I'm being forced to manually reinvent a core UI primitive.

⬐ maxharris

Why not just learn Flutter or SwiftUI? These systems are only going to continue to get more popular through the decade.

⬐ franga2000

One big reason I often go with HTML rather than any kind of actual UI framework, especially for prototypes or ad-hoc interfaces, is that's it makes it so much easier to do dumb things that weren't intended, aren't versitile or accessible, but I don't care.

I can put a div in a div, border-radius=50%, position=relative,absolute, add a single event handler and that's a digital joystick. Run a local single-exe websocketify and you can control anything from a CNC router to an army of drones.

I dislike Electron* as much as the next guy and steer clear of npm like my life depends on it, but there's no single thing that's more universal and easy to hack on than a simple HTML file.

⬐ filleduchaos

> I can put a div in a div, border-radius=50%, position=relative,absolute, add a single event handler and that's a digital joystick

Are you implying that this is somehow unique to the web or HTML? Because I can assure you that it is not.

⬐ franga2000

It's true that it's been a while since I've tried doing horrible things in an actual UI framework, but last time I did it was only very easy in QML, which is (was?) a royal pain in the ass to build for Android.

James Mickens has a talk about doing exactly this [1]. It's a perfectly sensible proposal and the talk is well worth the time to listen to. He makes a solid argument for why this should be done.

Problem: in reality, it is unworkable and will never happen, and even if it did the actual level of "development" that we actually see in the real world would end up in a situation just as bad as the situation we are in now.

[1] https://www.youtube.com/watch?v=1uflg7LDmzI

I'm working on a new framework that attempts to take what I think are the best ideas from the web (zero installation, easy to lay things out without tracking measurements yourself) and combines them with the best ideas from React (functions as components, ideally no mutable state). I want to solve what I see as the original sin of the web: inept separation of presentation from content.

The other thing I aim to solve is the issue of the browser and corresponding web standards being a monolith so large that only Google and Apple can afford to implement them. By wrestling back control over layout, I hope to show that a next-generation browser could be much more like what James Mickens laid out with the research he presented in this talk: https://www.youtube.com/watch?v=1uflg7LDmzI

I decided to prototype it in JavaScript, and right now it just renders into a canvas element. I love working on it, because all the unit tests run really fast. It can do that because there's no browser in the way - node-canvas is much lighter weight. Once the design is settled down, I'd like to rewrite it in Rust. The other advantage of this is that it is incremental. It'll run in any existing web browser, and building a cut-down browser that isn't web-compatible is doable in a few weekends.

The best way to see its capabilities so far is to look at the test screenshots: https://github.com/maxharris9/layout/tree/master/test/screen... - see especially text-actual.png, text-concave-cutout-actual.png, text-diamond-actual.png. I fell down a rabbit-hole with that a bit and made it wrap text around arbitrary polygons, hyphenating on syllable breaks and everything.

I just lost my job a couple of weeks ago, and I've been taking time off to work more on this thing. Tomorrow I hope to get mouse click events tracked through the component tree. And at some point in a week or two, when that's done, I really should write the application that I had in mind for it!

I know a lot of people have concerns about accessibility with the approach I've taken, and all I can say to that is, please help me work on that instead of criticizing me. I know there is talk about an accessibility DOM coming in browsers, but I fear that I'll just have to fall back to rendering plain HTML in order to drive screen readers, which is a terribly inefficient and indirect way of doing things. Also I don't even know where to begin with screen readers, what's the most popular software for that, etc.

I always like to refer to Ian Hickson's Requirements for Replacing the Web [0] when this topic comes up. They seems to encapsulate well the social, technological and economic dynamics required when discussing replacing the Web. However, few attempts (Crockford's Seif Project [2], MS's Project Atlantis and Project Gazelle [2][3][4][5]) seemed have to heed this wisdom.

[0] https://webcache.googleusercontent.com/search?q=cache:8zGGJQ...

[1] http://seif.place/

[2] https://youtu.be/1uflg7LDmzI

[3] https://mickens.seas.harvard.edu/publications/atlantis-robus...

[4] https://www.microsoft.com/en-us/research/wp-content/uploads/...

[5] https://www.microsoft.com/en-us/research/blog/browser-not-br...

⬐ jancsika

> I always like to refer to Ian Hickson's Requirements for Replacing the Web [0] when this topic comes up.

It's not that hard. Just iterate on any idea old that's even slightly more appealing to hack on than a full-blown browser. That includes... let's see... nearly anything!

Then just be smart and dedicated about specifying the behavior of the new thing and figuring out workarounds for the awful parts.

Ian Hickson did it[0].

[0] https://webcache.googleusercontent.com/search?q=cache:8zGGJQ...

James Mickens at Microsoft Research presents Atlantis, which I definitely think this still the most forward-looking browser architecture out there: https://www.youtube.com/watch?v=1uflg7LDmzI

Ideas from this effort are going to be trickling into browsers for years to come. For example, if you squint a bit, you might see a conceptual resemblance between the Syphon interpreter in Atlantis and WASM in shipping browsers.

> Doesn't every freaking mainstream technology suck? I regularly come across rants from significant developers regarding this issue. There probably is no way to prevent this from happening. Because worse is unfortunately better.

Web technology is fundamentally different in that you have a big standards body regulating everything from layout down to color blending, then leave it up to multiple vendors to implement all that stuff at great expense and with long delay. Worse, it's all shoehorned on top of some "document model" than was never designed with applications in mind. It's a waste.

To see what a better platform could look like, consider this:

https://mickens.seas.harvard.edu/publications/atlantis-robus...

https://www.youtube.com/watch?v=1uflg7LDmzI

The key here is reducing surface area. It's entirely possible that WASM will bring us closer to that, but the web developers of today probably won't like that.

> I regularly and seriously consider to leave software development because of this (as I'm really suffering) but then I remember how much power it gives me despite the horrible faults it has.

I don't know what you do, but I find web development to be significantly more frustrating than other areas. That doesn't mean there isn't frustration elsewhere though and it's definitely part of the job.

James Mickens gave a great talk about how we could build a better browser: https://www.youtube.com/watch?v=1uflg7LDmzI

⬐ herogreen

Amazing talk, thanks!

⬐ AlexCoventry

You're right, this is great. Is the Atlantis source code available?

⬐ VarFarYonder

I've looked for it previously and not found anything. I'm hoping that MS are working on it in secret, but seems unlikely.

The presentation Building a Better Web Browser[0] by James Mickens is worth watching.

[0] https://www.youtube.com/watch?v=1uflg7LDmzI

James Mickens gave an interesting talk on what we could do to build a better browser: https://www.youtube.com/watch?v=1uflg7LDmzI

I'm hoping that WebAssembly might be a route towards allowing something like this to happen. If an alternative to HTML/CSS/JS could be developed in WebAssembly, then we could have a situation where HTML has competition, rather than being the only way to build a website. And browsers can become simpler as the rendering duties are moved out of the browser and to the website itself.

James Mickens presents something like this idea: https://www.youtube.com/watch?v=1uflg7LDmzI

⬐ jerf

Yes, I had the pleasure of seeing him present that live once, though not at that one. I think he was disappointed that people weren't helping him work on it, but I still think that long term the pressures are absolutely inevitable in that direction. It's just that the world at large can't jump there in one shot, it has to get there one very laboriously-worked-out technology at a time first. He's gotten a bit more famous for his sense of humor, but I can attest that he knows his stuff.

⬐ jpfed

It's a very persuasive idea. I also wonder whether Atlantis's stripped-down API could enable a lighter alternative to Electron.