vehicle.software | pacific timezone | full-time | software engineer

vehicle.software is creating a new infotainment platform to redefine the in-car experience. We are focused on bringing excellent user experience to electric vehicles: beautiful visualizations, deep integration of connected services, and continuous improvements via regular software updates. Over the last decade, our team led development of Tesla's award-winning car software, widely adopted smartphone system software, and more. We are based in Palo Alto, California, and our customers are established car companies all over the world.

We are super excited to be using Rust, and we are hiring software engineers, for more details please visit https://vehicle.software/careers/

Totally agree; it's really fun to hear how things like autocorrect evolved over the development of the iPhone, and really how the designers and engineers thought about their work at the time. It's also nuts to think that so much of the iPhone software and experience was done inside of 18 months.

When the basic essential interactions like "select" feel natural and unambiguous -- holding your hand in place for Kinect wasn't a good replacement for "click"/"tap".

The future is fingerguns. "Pew pew to open program".

The recall problem was caused by software -- where are the software gods who write machine code instead of using compilers? ;)

I like the joke, but I feel I should say software is still a craft and not automated. Just that the tools have improved.

Yeah and if you have to drive a nail, you should use your fist instead of a hammer.

If you only have a hammer everything looks like a nail.

The best programmers I know all find an excuse to write some assembly every so often, even if just as an exercise.

By some wonderful coincidence I need to implement antialiased line rendering this afternoon. Previously I'd done the 6-triangle method (but I also rasterized any kind of path with all sorts of fancy fills, and it made more sense for that).

Thanks for such a clear write-up and all the links.

Shadow DOM is a DOM structure that's hidden under a tag (for example, the <video> tag has a Shadow DOM which provides the controls and timecode UI).

Virtual DOM is (typically) a pure JavaScript object-based DOM representation that gets somehow flushed to actual DOM (or to WebGL or anything else). You as the programmer use the Virtual DOM directly and try to avoid talking to the real DOM underneath. Virtual DOM has a few advantages, but the one that stands out in today's browsers is limiting DOM thrashing where you query the DOM (requiring an expensive recalc) and then modify the DOM (invalidating what was recalc'd) in a loop.

The license is Apache 2, so go for it! Thanks for the pointers on uiscript and uilang; I'll check them out. GSS is also on my list :).

Thanks!

Regarding your point on declarative vs imperative I think it depends on your pain threshold--you can't accomplish everything you want with CSS layout, but that doesn't mean not very useful. Crucially CSS has the escape hatches that you need to go and do your own layout if you need to (the escape hatches in CSS aren't very good, IMO, but they're there).

So I do believe that this work could be broadly useful. I frequently use apps where the panels don't incorporate momentum properly, or the motion feels disconnected from my actions.

If I were to build on this work, then I'd want to create a system where it's easier to do something pretty good than not, but you can still escape and grab full imperative control if you need to.

Thanks!. For now the source of the examples is the best reference (and is commented with the intent of the constraints):

https://github.com/iamralpht/iamralpht.github.io/tree/master...

I will do some proper documentation and package Slalom up as a library in the future.

I hope you'll find time to package both this and your javascript physics code.

Your constraints abstraction looks very promising. Now all you need is to package it up. The examples are excellent.

Thanks! It's a really fun problem space to work in.

As I mentioned, this work was borne out of my frustration from writing a bunch of touch handlers (taking days/weeks for the tricky ones, to get all the weird wobbles out, and do the right thing with momentum in pagers, etc). I could have saved a bunch of time if I'd had something like this earlier! :).