I can see how people can get worked up over this. Here's what I replied over there:
Thanks for pointing that out. I agree that from a technical standpoint this is not the same as a Philips Hue bulb or light strip. If you look at it from a users point of view, all Philips Hue is a lamp that you control the Brightness and Hue of. This gives you that functionality. No Zigbee protocol. True, but in the context of HomeKit/HAP-NodeJS, does it matter how the bridge talks to the light? I might as well be using 433MHz transceivers, nRFs, or directly controlling the Raspberry Pi's GPIOs. For that matter, ZigBee would be doable too, but I don't know enough about the protocol to see it's benefits. No smart mesh network where each device extends your coverage. True, but a mesh network can be implemented with ESP8266. But if my whole house has WiFi, I don't see the point. No possible compatibility with either Phillips' Hue bridge, Hue remotes, or any other kind of Hue hardware (like Phillips' Hue+Ambilight TV's). Actually, using the Philips Hue shim in Homebridge, I believe it should be possible to make it compatible to Hue bridge. My motivation behind making this was to prove that with ESP8266 based projects, you don't need to have a clunky web UI or a custom app. This lamp can be controlled with any app that support HomeKit. Philips Hue was just the most similar commercial product I could think of. Btw, HAP-nodeJS can be completely eliminated here by using nRF51/52 BTLE chips. They can emulate the HomeKit API and control the NeoPixels both in one chip, so no bridge necessary!
Current IoT implementations all rely on a corporate link to their servers, which I heartily disagree with. You can see a lot more of my acerbic complaints on my blog crankylinuxuser.net as well as reddit /u/crankylinuxuser :)
People like us add to a growing force that says "We will not accept non-standards." I don't care of BigCo makes IoT gear: Just use MQTT/CoAP/AMQP or make doing so trivial. Don't make me use your garbage API on your servers.