Not trying to pick a fight, but again your team comes off as naive and essentially gives the middle-finger to probably the majority of the software developer community with comments like these. It seems like you guys simply have not worked on an actual complex system of any significant size or over-value the complexity of front-ends. I personally respect all facets that go into making software.

Anyway, I would argue there's no easy part and dividing things into monoliths at a conceptual-level is a mistake. Putting that aside, whatever part is comparatively (key-word) easier is highly dependent on the implementer. For instance if I build a system that just needs 1 input field, but then performs some sort of machine-learning or triggers some complex background dispatching, then that system is arguably much more complex on the "back-end." I think making big distinctions is a source of trouble to begin with and regardless I do about equal amounts of front and back-end work on my current start-up.

As for the special sauce, in many apps the special sauce is actually the back-end. I would agree everyone hates with dealing with 3rd party libs and so on, but the ways you deal with that information is important. I think the way Treeline is described in your website, this article, and video makes weird distinctions and conflations between what is front and back-end work and what are actual problems programmers actually have. I totally get the parts about plugging into another API and not having to write the fetch code, but honestly with a library or two or even implementing integrations with many libraries, the work is minimal. Adding the correct libraries is often an important choice.

To give you a concrete example, I do most of my current work in Clojure followed by Haskell, Java, and C. The choice of library authors doing things like using non-standard data structures that I then have to transform or directly consume, using/not using things like async channels, and so on from the ends of their APIs is a huge deal. It's not normally a problem to find a library that works with how you want to do things, but rather important that you pick the right one from the list of choices. If a Clojure library forces me to consume a core.async channel, I might not do it because I want to use something more general like a transducer to abstract that away.

Sometimes also the ways that I consume someone else's library are very unique to my app and provide a crucial difference aka special sauce. Consider for example that for years I had a client that had a huge advantage due to code my team created against some public APIs because we were able to stream, batch, and thread our interactions with this particular API in ways most people had not thought of or implemented. The fact that our integrations were based on self-calculated heuristics provided dramatic speed-ups over everyone else meant it looked like we could do things that would cause the client's competitors to think we had some special deal or wonder how it all worked. This is not unique to us, rather it is simply illustrative of the importance of optimizing your business activities in the back-end. Consider that most of wall-street high frequency trading as another example is based on this notion. While I am not claiming that everyone needs to do this, your generalization is the issue here.

It is funny because maybe our definitions of "back-end" are the issue. I tend to notice that the wheels on the front-end are invented time and again. How many different UI frameworks, patterns, controls, etc are there that get implemented from scratch? How many people end up composing their apps out of little more than paging, showing pictures, textboxes/checkboxes/pickers, form validation, css positioning, animation, and so on. I'd argue these are the actual repetitive bits that are tedious to write.

I am reminded of criticisms of forum software by the authors of discourse. They pointed out a lot of the special sauce things that were wrong with forums, but ended up pissing off a lot of potential users who thought at least the versions in the past few years were essentially a lower functionality version of the same things with fancier loading and scrolling using JavaScript and JS templating. And the critics were at least in part right because not much new was brought to the table beyond looking and feeling slightly better on some basic elements, but the nature of forums software as we know it was hardly shattered so far.

It seems to me what you've noticed is that a very particular segment of node.js users who used sails or were involved in the node.js ecosystem were reinventing the wheel or didn't understand the wheel. This is fine as you clearly are trying to address this problem, but you are also making blanket statements about software development. Everyone I have worked with who I consider to be far smarter than me would agree that a common mistake a lot of people make is they think any part of software development can just be replaced by a magic wand wave and that xyz part of the system is just stupid, tedious, and simple. It's like that time before you reach the point in programming where you realize it is not that your code is awesome, it is merely that it sucks slightly less than the next guy's code due to your experience.

You guys really need to focus on the concrete things the product does not on philosophical nonsense of magic software development. Presently it just seems like you've made it easier to wrap some node.js APIs, call them in an opinionated way quickly, and slap a visual front-end that includes some canned forms and an impractical editor on top.