For a few years now I have been using PHP as a thin-client UI layer on top of C# Web API (dotnet core) projects running on Ubuntu/Docker. In my experience this has worked out very well, and has been easy to separate the areas of responsibility between Software Engineers and Designers.
All of our sophistication and unit tests live inside the C# back-end projects. While the PHP in the UI layer is limited to very simple code like for loops and templating; otherwise they're mostly design projects centered around HTML/CSS/UI/UX. Keeping it so simple makes it rather easy for designers to pick up on and work with.
I started a small website to document this pattern:
Good point. I've never actually worked with gtk+, but I have worked with windows forms development for desktop apps. I thought it was a really good approach for building a windows desktop applications, but I create all web-based UIs in a code editor.
I suppose if there was only one browser to target, then we might actually see more use of a GUI editor. Kind of how FrontPage was for IE a long time ago.
I completely agree with the learning curve. I often think it's just as hard, if not harder, to learn a new tool than it is to learn a new programming concept. You have to re-train your brain to think the way the creators of the tool approach problem solving (assuming their approach is actually good). If you're not already like-minded, then this is incredibly counterproductive.
There's so much flexibility that allows for creativity when you just understand the code. In fact, I've been doing what I consider to be "designing in the browser" for years. Which is using Photoshop to get started, pick colors, etc, then utilizing developer tools for much of the refinement during the implementation phase. This is the closest thing I've ever found to a good "GUI editor".
I get what you're saying; that these characteristics are not mutually necessary. And I agree with you.
As for the other question, I suppose you could separate those characteristics as well. For a moment, let's ignore the Bible and focus on an abstract concept of "God". It is possible to be good, and not be God. It is also possible to be God, and not be good. And in that case, we don't have to redefine the word "good" to mean (a bad) God, just because he is "God". So yes, ultimately these are independent concepts that are not mutually necessary.
> "Are people saying he's a great person because he's god"?
Jesus is described in the Bible as being a man that lived a sinless life. That's where the "good person" description comes from. He was tempted just the same as any of us are, and he could have given into any of those temptations. According to the Bible that didn't happen, but if it did, it leads right back to your original point: he could have theoretically been God and simultaneously not have been good. The problem with that (not the problem with your logic, but the problem with him being an impure God) is he would no longer be an innocent sacrifice and his whole mission falls apart.
You're logic is correct, but it's not the great teacher part that is in question. The part that is always in question is about whether or not he is really God.
Take that same analogy and replace "great teacher" with "great person". If Jesus told people that he is God, and convinced them to put their trust in him, but he happens to be wrong about being God (regardless of whether that's an intentional lie or an honest delusion), then it really isn't fair to say that he's a "great person". It would be more accurate to characterize his morality in leading people astray similar to the likes of Hitler and L. Ron Hubbard.
You're right, the logos really aren't good. But to give him credit he did say "I have a bit of a designer inside me. Not a lot. Just a bit."
I appreciate a developer who knows enough about design, even if their own design talent isn't very strong, to recognize quality and the efforts put in by other designers.
All of our sophistication and unit tests live inside the C# back-end projects. While the PHP in the UI layer is limited to very simple code like for loops and templating; otherwise they're mostly design projects centered around HTML/CSS/UI/UX. Keeping it so simple makes it rather easy for designers to pick up on and work with.
I started a small website to document this pattern:
http://rapstack.io
I have advocated for its use on most of my projects, but obviously the mere mention of PHP stirs up a lot of knee-jerk reactions.