HN user

macguillicuddy

479 karma
Posts5
Comments60
View on HN

I agree that devices should work independently. But I believe the fundamental baseline should be open interoperability. Yes, the dishwasher should allow a delayed start from the machine itself. But it should also have secure yet open interoperability so other authorised systems that care about the dishwasher can interact with it. I think there's ultimately a user experience benefit. I'm familiar with my phone, its UI paradigms etc. If I (or my gran) can use the dishwasher through an interface or voice assistant we're already familiar with then that's a win. Especially if the form factor of the device itself makes it challenging to deliver a great and intuitive interface in-situ.

In this regard CarPlay is evidence of success - a sufficiently interoperable car that allows users to bring their own context and ecosystems.

CarPlay is only evidence of failure if your expectation is that the car should provide a comparable ecosystem to Android or iOS - one that must also somehow follow you in your pocket when you leave the car.

I've always been interested in the concept of using the filesystem more thoroughly like this, but sometimes I wonder about the value of it, and if pulling on that thread could get us something even more interesting.

Take this, for example:

s3.put_object(bucket, key, data) -> cp file /s3fs/bucket/key

The S3 call is tooling over an already lower level operation - an HTTP PUT request. The function tooling is added /because/ it makes it easier to call correctly. You could choose to use the underlying HTTP request directly if you wanted to. The function approach may add type safety and additional client-side validation/logic that can't be expressed in the underlying API (HTTP or FS).

In some ways we can think about the FS as an RPC mechanism with service/resource discovery (LIST operations) and a fixed/limited set of functions (READ, WRITE, SEEK, etc). Perhaps a more interesting 'universal interface' would be a broadly supported RPC mechanism with the FS operations as an adoptable interface that any given resource could support. That way an S3 implementation could choose to implement the FS interface if it wanted to, and an AI agent could discover the additional functionality offered by the other interfaces it supports. Probably a pipedream .

Yes that's true, but there's effort to consider on both sides of design decisions like those TypeScript has made. Much of the compile time behaviour comes from the decision for TypeScript to be incremental on top of JavaScript. That allows you to start getting the benefit of TS without the effort of having to rewrite your entire codebase, for example. Having used TS for many years now I feel that the balance it strikes is incredibly productive. Maybe for other folks/projects the tradeoff is different - but for me I would hate going back to plain JS, and there's no alternative available with such tight integration with the rest of the web ecosystem.

Because adding types adds constraints across the codebase that detect a broader set of mistakes. It's like saying what's the point of putting seatbelts into a car if they only work when you're wearing them - yes you can use them wrong (perhaps even unknowingly), but the overall benefit is much greater. On balance I find that TypeScript gives me huge benefit.

No tool is perfect. What matters is if a tool is useful. I've found TypeScript to be incredibly useful. Is it possible to construct code that leads to runtime type errors? Yes. Does it go a long way towards reducing runtime type errors? Also yes.

Hey all! My team and I have been working on a fully integrated AI assistant for our Mattercraft tool. It's a 3D development environment for web content - our aim is to find an efficient and expressive intersection between the development experiences of game engines, and those of frontend web development. The AI assistant is a fully integrated 'Cursor-style' workflow that gets the benefit of additional knowledge and context that Mattercraft has about your project. Would love to get folks' thoughts! While Mattercraft itself is already general release, we're launching the AI assistant in a beta. If you'd like to try just drop me a line at connell <AT> zappar.com.

WASM 2.0 1 year ago

We do for some elements of our pipeline. WebGPU will give us more opporunity for this in the future too but right now we need broader device support unfortunately.

WASM 2.0 1 year ago

We have tight inner loops over large numbers of pixels - in some cases optimized to the level of careful register choice and SIMD

WASM 2.0 1 year ago

We do high performance computer vision in the browser (at 30/60 fps) that's an order of magnitude faster in WASM than JS. It simply would not be fast enough without WASM.

I feel that this is orthogonal to my point - it's not about how generous or not a given mechanism is, more to question why the App Store is any different from other transactions we need to protect. You either have to argue that App Store transactions need more consumer friendly refunds than other credit card transactions for some reason, or otherwise that credit cards should have no-questions asked refunds.

As another commenter said, in some cases Apple's power in the relationship is detrimental to the consumer - if a user issues a chargeback then Apple can disable their entire Apple account.

The App Review Guidelines have been updated for compliance with a United States court decision regarding buttons, external links, and other calls to action in apps. These changes affect apps distributed on the United States storefront of the App Store, and are as follows:

...

3.1.3: The prohibition on encouraging users to use a purchasing method other than in-app purchase does not apply on the United States storefront.

3.1.3(a): The External Link Account entitlement is not required for apps on the United States storefront to include buttons, external links, or other calls to action.

My understanding is it depends on the amount of visibility, plus what type of approach they were on. One type of approach, an ILS, has big radio transmitters pointing from the runway into the air and allows the plane (either pilots or autopilot) to get close enough to the runway without visibility, and with enough precision, to land. In many circumstances ILS isn't available and an alternative is Required Navigation Performance (RNP) which uses GPS plus a ton of other inputs to give some amount of precision to the same end. If they're on an RNP approach but suffer a reduction in navigation accuracy then I imagine it's a policy 'go-around'. Even if there's enough visibility it allows the pilots to brief a 'visual' approach before attempting it.

It would be my pleasure :-)

Zapworks Designer - it's our no-code tool focussing on AR+VR. It's targeted at folks without scripting experience and is very much 'drag and drop'. Our customers typically use this for bringing simpler interactive content to, e.g. menus, posters and also for Learning & Development.

Mattercraft - this is our complete 3D development environment for the web. We took everything we'd learned from Studio and built MC from the ground up embracing the web ecosystem. It has a fully featured animation system, scripting, built-in bundler, live preview, collaborative editing - the works :-) Our customers use this for building high end campaigns and content for consumers.

Zapworks Studio - this is our previous generation of creative tooling. It was originally built to target native platforms but we ported its runtime to the web. Mattercraft is the 'spiritual successor' to this tool.

While Mattercraft has some drag and drop elements, it's predominantly a development environment for content, featuring TypeScript and NPM support. So it's a bit like a 'Unity for the web'. Many of the features (e.g. physics, particles) are provided as optional additional NPM modules. The 3D text support is included in the base 3D module because it only adds a few kb and Mattercraft's built-in bundler doesn't bundle it if your project doesn't use it. (My team and I run Mattercraft )

x86 ASM is text but we don't build software by copying and pasting it. While the underlying thing we ship is CSS, that doesn't mean we can't add tooling layers to make it easier or more efficient. While it's totally allowed to write by hand, most frontend web developers I know are very comfortable with NPM, and indeed having dependencies consumed from a package manager is often preferred.

It's my understanding that the browsers use a translation layer (such as ANGLE) between both WebGL and WebGPU and a preferred lower level native API (Vulkan or Metal). In this regard I don't believe WebGL has any more or less protection than WebGPU. It's not right to confuse abstraction with a layer of security.

Rotten Apple 2 years ago

It's a single data point but the Xbox Cloud Play (game streaming service) works on iOS through a PWA since Apple required that any service like that submit a seperate app for each game that it permitted to be streamed.

Shameless plug (my apologies it's my second this week ) - but we recently released our $80 headset. It's a plastic headset, with two bluetooth controllers, that you put your phone into 'Google Cardboard style'. We've released a Spatial TV app that lets you view spatial videos straight away. https://www.zappar.com/zapbox/

Those are very kind words - thank you! It's been a labour of love for us over the last few years but we're at a point where this product really works now and so it's great to see the positive response. That's a really interesting point re education. I know the team here are very much looking at that vertical and will pass on your note. One of things that's nice about Zapbox is that the controller inputs are Quest-compatible, so educational content built for Quest should be easy to port, allowing for use cases where there are a small number of higher-cost headsets used in tandem with a larger number of Zapboxes.