We do plan to do some tests, to the extent that we're able. We can A/B test much of the UI but we can't A/B test the insurance terms that we give people because that would require different pricing and thus different rating, which needs to be the same for everyone legally (also any pricing changes require approvals regardless of A/B testing or not).
Don't take this too literally as I'm just a developer, not a licensed insurance agent. But this kind of thing is harder in a heavily regulated business such as ours.
It could be, along with say family size. But the UX cost of asking such questions is real, especially on an insurance application form. People get worried why we want to know such things so early on.
Today we're able to provide a pretty good estimate with no personal details, nothing but a zip code in fact. We might work the zip code into temp housing default at some point, but it's not without issues. Changes to the property <> temp housing link built into our rating require solid data and regulatory approvals.
What I'm saying is outside of the virtual DOM paradigm you might not need to diff any elements at all, real or virtual, and so you wouldn't care about the performance of DOM reads, as you're not doing them.
Then it becomes a matter of DOM write performance, but that is the same for everyone assuming the native DOM API commands issued by the libraries are the same, which is a more or less reasonable assumption for well optimized libraries even if they use different paradigms to calculate what those commands should be.
Well... faster than what exactly? You have to do the virtual DOM pattern (generating new DOM state and then diffing with old state) with virtual elements. You can't compare proper virtual dom to using real DOM elements instead of virtual ones in a virtual dom pattern, it wouldn't make any sense.
But there are other non-virtual-DOM ways to manage DOM state efficiently and in a maintainable manner. For example, my own library uses Observables to drive precise DOM updates and works with trees holding real (not virtual) DOM elements, so it doesn't need to do any diffing at all: https://github.com/raquo/Laminar
I don't think it's a given which of these techniques would be faster, it depends heavily on the particular use case and the implementation of diffing (for virtual DOM) and Observables (for my pattern). If both are well optimized I'd expect virtual DOM to lose in a lot of cases.
> Oh wow. You just described the existing imperative DOM APIs, haven't you? Inflexible implementation wasting everyone's time.
Existing DOM APIs are very simple, low level and unopinionated. A pleasure to build libraries on. That's what durable platform APIs should look like.
It is very easy to build virtual dom and importantly other DOM management paradigms on top of those low level APIs.
The same can not be said about virtual dom - it's a very opinionated, very rigid paradigm. I know because I built FRP UI libraries based on Snabbdom and on native DOM APIs. The latter is much simpler to deal with and more performant. Virtual DOM only works well if that's exactly what you want. It has no place among browser APIs, at least not in any recognizeable shape or form.
Regarding performance, the whole point of the virtual dom is that the diffing engine does not know which elements changed or didn't change. It gets a new virtual subtree and has to diff it with the previous one. The browser would be doing all the same diffing work, just closer to the metal. But we will soon be able to do the same with just WASM.
> Why waste time implementing and “reducing it even further” and not just implement it in the browser?
Because the browser should not offer inflexible implementations of complex, highly opinionated and currently overhyped paradigms, because those standardized APIs will stay with us for much longer than they will be useful, wasting everyone's time.
We're only talking about virtual dom here because it's a popular concept with good library implementations. We don't need to reimplement it in all major browsers because we already have it working well.
Even aside from that, it is easier to build one library than implement the same spec in all major browsers. Moreover, library designs compete with each other, and can be improved faster than APIs baked into a browser which will have to be maintained in a backwards compatible manner for more than a decade.
> First bullet point is relevant for internals mostly, little bearing on actual API.
The concepts of Components, State, Context, Thunks, Fibers, Plugins, etc. are very important differentiators between various virtual DOM APIs. Either the presence or absence, let alone the specific design of those concepts strongly affects the API surface and what users can do with it and how. Don't mistake React's API for some kind of standard.
Once the hype inevitably moves on from virtual DOM to whatever the next declarative UI paradigm will be (e.g. FRP with precision DOM updates) this whole standardization and reimplementation exercise will be rendered a giant waste of time.
There is enough differentiation in virtual DOM designs[1] that I don't think implementing a lowest common denominator that is flexible enough to support competing strategies would be useful. Being a browser API it would need to be a rather timeless, low level design. Essentially, we already have that – the imperative DOM API.
With WASM the performance gap between libraries and native browser code will be reduced even further. Focusing on that has the benefit of lifting all boats, not just a particular DOM building paradigm that has been popular recently.
[1] Just some examples that come to mind:
- logic that decides when to update an element vs when to create a new one (including but not limited to having the concepts of components, thunks, deciding to look at class names, ability to move nodes, etc.)
- design of lifecycle methods and hooks, as well as any performance-oriented optimizations such as asynchronous / delayed rendering, short circuiting logic, etc.
- handling of props vs attributes vs reflected attributes
Because virtual DOM is not the only way to achieve efficient DOM updates, and even within the concept of virtual DOM there could be many different ways to achieve efficient diffing (e.g. React vs Snabbdom). There is nothing special about a particular virtual DOM spec to deserve a place in web standards.
ScalaTags is indeed not relevant here, but Scala.js has its fair share of reactive UI libraries such as my own Laminar https://github.com/raquo/Laminar
Directly. One of my friends is holed up in Yukon working via a website similar to upwork. Seems to work for him although these kind of sites generally get bad rep on HN.
Yes, I worked remotely for both US and Canadian clients. Dealing with Quebec clients is a pain (need to file their sales tax, _in french_), otherwise it's been a smooth sailing. Just remember that you're a contractor, not an employee.
You don't have to change from the qwerty layout for general typing.
For example, you can program the keyboard in such a way that pressing X+A sends Ctrl+C keys to the OS, where X is a custom modifier button (Not Ctrl but a separate button that you assign for this use case) and A is, well, whatever other button on the keyboard you want to use for this, not necessarily "C".
Or you can have a single button programmed to send Alt+Tab, or... whatever, really, the firmware is very flexible.
Keyboards like Diverge and Ergodox are fully programmable so nothing's stopping you from doing that today!
Also, I found that putting a small touchpad^ in a thumb-accessible area (near where a laptop touchpad would be) is a good enough replacement for a mouse.
I tried Dvorak for a month a few years ago. For me it was just useless agony, not only with key positions but also with app/OS shortcuts that are very much designed for qwerty layout.
I have since switched to a split ergonomic keyboard (Diverge 3) and adjusted the layout somewhat (kept qwerty, but put all the modifier keys in custom locations). That took me about a month to exceed my previous speed. Typing on standard keyboards when needed is not a problem either.
It would be great if you had a public preview of the content there. I've seen it done before, so there must be some kind of a slack app that lets you do that.
As a remote contractor I sometimes feel that it would be nice to have a chat like that, but a few startup-themed slack channels that I tried out turned out to be no good for me.
I was told they would send me a replacement if they determine it to be a hardware problem. Return wouldn't be an option (I'm past the first 30 days). I'll try to negotiate with them anyway.
Don't take this too literally as I'm just a developer, not a licensed insurance agent. But this kind of thing is harder in a heavily regulated business such as ours.