Comment by jmtulloss

Comment by jmtulloss 6 days ago

3 replies

Hey. I wrote some of that trash.

I think this is a bad take because I don’t think the core issue of the platform was that it was based on web tech. The web tech basically worked fine. However the bugginess and challenging user interface (which is actually standard today) was a huge issue. The leadership decision that was needed wasn’t to kill the touchpad 49 days after launch, it was to kill it before launch.

Palm was a raccoon backed into a corner and it was using all its cleverness to get out. But it was willing to ship stuff that wasn’t ready and couldn’t be ready with the resources we had. HP had the resources. They could have taken a good start and given it the space to become great. Maybe.

hajile 6 days ago

webOS really needed low-level help. It took over forever to boot because (seemingly) nobody ever bothered to optimize even the low-hanging fruit. The webkit version used was slow and way behind standards and (as was the JS JIT). This was crippling for a web-first system.

That aside, the actual UX of webOS itself is still better than anything we have today and I liked my Touchpad despite the flaws.

  • jmtulloss 6 days ago

    Yeah, there's a lot of context there that isn't obvious from the outside and is behind my feelings that Palm just had too little too late. They shouldn't have been blindsided by the iPhone, but with that happening they really did the best they could. I'll make some brief points, but maybe I should write a blog post at some point.

    - Kernel talent was never a problem at Palm. The ex-Palm folks lead or are technical leaders at many mainstream unix-ish OSes today, plus Fuschia (Android, Apple, Chrome, Fuschia)

    - Boot times weren't the highest priority (though we did spend time on it since they were _so bad_). Battery life was. We didn't even do that well by launch date, but if Android hadn't mainlined their power-management framework before the Pre launched it would have been a joke. It was all hands on deck to get that stuff integrated in time for launch.

    - The webOS platform was actually a thin UI layer on top of an Android-like Java-based platform that never launched. The Java-based OS wasn't derivative of Android (it predated Android), but it had no differentiating features with Android already live. Booting the Java runtime _and_ the JS engine and webkit was a lot.

    - We knew we couldn't have Java running on this phone long-term, so tons of effort was going into nascent node services instead of Java ones. So all those were launching too.

    - Your memory is incorrect on the JS jit, or mine is. My memory is that we were adopting the latest v8 engines as fast as they would come out (although not as fast as chrome) because they were the only ones that could keep the thing performant.

    - Webkit was a mess, I'll give you that, but I'm surprised you noticed. Were you at palm too? Did you build apps? We generally provided UI components that were the way to build apps that, hopefully, allowed you to ignore the intricacies of exactly which webkit version you were on (at least to build an app).

    • hajile 6 days ago

      Boot times for alternative kernels were a lot faster. I can't recall exactly (it's been years), but I seem to remember that there were some simple config settings in the bootloader that could cut boot times by a lot.

      Was battery life the reason stock clocks were 1.2GHz instead of Qualcomm's recommended 1.5GHz? I used to run mine at 1.7-2GHz without any trouble (aside from battery life).

      Maybe I'm wrong about the JIT, but as I recall, the JS benchmarks under webOS were significantly worse than Android (preware ultimately wasn't enough to keep up with things and LuneOS wasn't really viable without a lot of effort, so dual-booting to Android extended the life of the tablet for quite a while).

      I wasn't at Palm, but it was noticeable during browsing (especially vs Android) and was extremely noticeable when it came to missing features. I did some EnyoJS work, but that was actually targeted at web apps rather than a webOS-specific app.