Reasoning and technical reference on FitBit JS / SVG / CSS, and how they diverge from the standard?

[mhelvens]

I'm a web-developer, and it's taking me quite long to get used to the idiosyncrasies of the FitBit versions of JavaScript, SVG and CSS.

I take it that you developed the engine in-house, presumably for performance reasons. That's perfectly understandable, but some decisions are still puzzling, and I wish I could know the underlying limitations of the system, so I might better understand those decisions and better predict what can or cannot be expected to work (now or in the near future).

For example, here are some differences I ran into just today:

• FitBit JS: The online editor seems to accept `async` / `await`, but using them crashes my Versa. Does the JS language follow an EcmaScript standard? If so, which version, or which features?
• FitBit SVG: I can use a `<circle>` element, but I cannot use `stroke` or `style` attributes. I can give it a `class` attribute, but even that way I'm not able to give it a border. You introduce an element called `<section>`, but it doesn't support a `class` attribute.
• FitBit CSS: I'm not able to use units like `px` (even though not using units is normally discouraged). I can't seem to use any kind of composite selector. It does not even seem to be a subset of standard CSS, since it introduces its own `50%+5` notation. Why not adopt `calc()`? (Even if it would be a limited form, it would at least be standards-compliant, affording you backwards compatibility should you want to support the full standard someday.) Also, it took me 10 minutes to debug `50% + 5`. It turns out those expressions do not allow spaces.

I guess I'm asking:

1. Could we get more comprehensive documentation aimed at experienced web developers?
2. Are there plans to become standards-compliant on the roadmap?

PS: One way to go would be to make the rendering engine open source. The open source community is a powerful force, and this strategy has propelled some platforms into worldwide popularity. 🙂

[JonFitbit]

Thanks for the feedback. This is the first version of the SDK and we're steadily improving and adding functionality.

FitBit JS: The online editor seems to accept `async` / `await`, but using them crashes my Versa. Does the JS language follow an EcmaScript standard? If so, which version, or which features?

The device itself supports ES5.1, but the companion isn't as restricted. We are transpiling during the build process, but some things might be beyond the capabilities of the device right now.

FitBit SVG: I can use a `<circle>` element, but I cannot use `stroke` or `style` attributes.

We currently only support the documented attributes on the SVG tags. https://dev.fitbit.com/build/guides/user-interface/svg/#circles

You introduce an element called `<section>`, but it doesn't support a `class` attribute.

It's intended to establish a new coordinate system for child elements. I'll pass on the feedback though.

FitBit CSS: I'm not able to use units like `px` 

I can't really comment on the design decision, but it is a very resource constrained platform.

Could we get more comprehensive documentation aimed at experienced web developers?

Do you have anything specific in mind, we're always looking for ways to improve the documentation.

Are there plans to become standards-compliant on the roadmap?

I can't comment on the future, but you can submit feature suggestions here: https://community.fitbit.com/t5/Feature-Suggestions/idb-p/features/label-name/sdk/tab/most-kudoed

[mhelvens]

---

@JonFitbit wrote:

Thanks for the feedback. This is the first version of the SDK and we're steadily improving and adding functionality.

Added functionality would be good, but even better would be clarity about the current functionality.

FitBit JS: The online editor seems to accept `async` / `await`, but using them crashes my Versa. Does the JS language follow an EcmaScript standard? If so, which version, or which features?

The device itself supports ES5.1, but the companion isn't as restricted. We are transpiling during the build process, but some things might be beyond the capabilities of the device right now.

My main point there was that there was no way for me to know that `async` / `await` wasn't available on the device until after half an hour of slow debugging. The documentation doesn't tell me, nor does the editor, nor do the build logs.

(In retrospect I can guess what's going on here. You're uniformly transpiling (parts of) ES2017, but you're not providing the necessary runtime to the device. On this specific issue: It would be best to have a separate babel configuration for device files, so we can get early error messages for unsupported features from the editor.)

You introduce an element called `<section>`, but it doesn't support a `class` attribute.

It's intended to establish a new coordinate system for child elements. I'll pass on the feedback though.

This is where standards come in. Why invent this new element if nested `<svg>` already exists? There may be good reasons, but I wish they were more clearly explained.

FitBit CSS: I'm not able to use units like `px` 

I can't really comment on the design decision, but it is a very resource constrained platform.

This is one issue that has nothing whatever to do with resource constraints. Using `width: 20px;` is the same as using `width: 20;`, except that the second form is generally discouraged in normal CSS, and the only form supported by FitBit CSS. So web developers trying to develop for FitBit are guaranteed to get this wrong at least once.

Could we get more comprehensive documentation aimed at experienced web developers?

Do you have anything specific in mind, we're always looking for ways to improve the documentation.

Web developers have been able (in more recent years, anyway) to count on all modern javascript engines and APIs to follow a set of web standards, meticulously designed by committees and based on feedback from developers around the world. Using web languages for FitBit development was a stroke of genius, because it leverages the largest group of software developers in the world.

But so far, FitBit does not seem to be taking advantage of this. The documentation and entire ecosystem is clearly targeted only at newcomers. Experienced developers get a rather frustrating experience, locked into your online editor, the SVG and CSS languages not even subsets of their standard counterparts (with non-standard notations that would break on the web). And the documentation is just very incomplete. Ideally it should lay out all differences from the standard in an easily discoverable way. And explain the reasoning behind those differences. 

I've already mentioned a number of inconsistencies and other issues, but if you want to know more, I suggest you ask your own developers.

All the best!