I was only commenting, not necessarily criticising. However, if you want an easier entry-point, then focusing on capability and not function is a much better UX. This is one of Node-RED's strengths in my view. It has a very low starting friction. Better than any of the other flow and visual tools that I've looked at (and I've looked at a LOT over the years both professionally and at a hobby level).
Having a long list of individual functions and no obvious entry and display points is not conducive to people getting started.
This is, of course, always true.
No, I couldn't really care much about that, anything even remotely complex would need a proper IDE anyway. My comment was more that I was impressed by the fact that a lot of the node code complexity was nicely hidden by using a parent class that you extend. This is, in my view, an area of some weakness for Node-RED. Code complexity for writing nodes is relatively high. Not impossibly so but there are a lot of complex parts that you have to provide boilerplate for.
It has actually started me thinking about whether there would be a way to do something similar in Node-RED. At least for the runtime component. I'll be giving it some more thought. I already use a number of singleton classes in UIBUILDER (which, I freely admit, is at the upper end of complexity for a node). I also use an refactored approach to the main runtime for all my nodes which I personally find a lot easier to follow and extend. But if I could embody the runtime boilerplate in a class and then extend that for each node, I think that might be very powerful.
Time to dust off my test nodes again. 
Indeed, personally, I always appreciate being able to look at potential alternatives.
