Very interesting. Yes, at a glance, that's exactly what I had in mind.
>the web platform is so huge and sprawling, and constantly growing
>we've made the pragmatic choice to prioritise usability by non-web developers, and open an "escape hatch
Makes sense. And totally worth the tradeoff for the developer if it helps me flip the 80/20 rule around. And, if the component model is extensible such that, when I do have to open the escape hatch, I can plug a resulting component back into the framework (lay it out and set properties in the visual editor, etc.), that might be even more optimal. Either way, I'd rather a framework do the heavy lifting and let me deal with the edge cases than me do all of the heavy lifting and plumbing, so that's a win.
>and all of it's written in JS/HTML
And, this is the part where I do have to scratch my head a little. I'm going to guess you've heard this question 4,321,257 times, but why not support JS? It is the lingua franca of the Web (as your quote acknowledges) for better or worse, and virtually all devs already know it. There's also a rich JS library ecosystem.
The idea that I have to pick up Python just to try it out introduces more friction. I'm guessing that might slow adoption with a huge percentage of your potential audience who might otherwise have the knowledge they need to jump right in.
> Yes, at a glance, that's exactly what I had in mind.
Thrilled to hear it! If you do try it in more depth, please do drop me a line (email in my profile).
> why not support JS?
Two reasons:
1. Basically, the moment you use JS, any discipline or abstraction you were trying to introduce dissolves. People will reach in and use the DOM/combine it with other Web frameworks/what-have-you. And then you'll still need to know HTML and CSS and all these other pieces, as well as this new framework, and you've done the opposite of simplifying web development. This is the "Javascript Framework of the Week" failure mode.
2. Contrary to your assertion, "most devs" don't actually know JS. It's something people only learn because they're learning front-end web development, and it's difficult to learn it without the whole HTML/CSS/frameworks hairball. Python is much friendlier to, eg, data scientists or embedded programmers or back-end developers, who have every right to think they should be able to put together a web app without learning three new programming languages and two new frameworks.
(This is another way of putting what I said earlier about "prioritising usability for non-web devs".)
>Basically, the moment you use JS, any discipline or abstraction you were trying to introduce dissolves.
I see. Kind of a purist approach that eliminates all temptation by not offering the option to go there. Sound reasoning, as JS definitely has slippery-slope potential.
>People will reach in and use the DOM/combine it with other Web frameworks/what-have-you. And then you'll still need to know HTML and CSS
I'm probably too biased to make a call on this. I'm so wanting to be released from that madness that I'd fight tooth-and-nail not to descend back into it.
So, I look at it the other way around: My JS would be more disciplined (and there'd be les of it), as I'd be released from the need to use it so much for stuff like DOM handling. In my ideal world, I wouldn't even know there was a DOM or HTML or CSS. I'd just use JS in event handling and, perhaps, functionality that directly supports the same.
>"most devs" don't actually know JS...people only learn because they're learning front-end web development
That's what I intended--that most web devs know JS--as I was speaking in the context of web development.
But, I missed the emphasis on the "non-Web devs" portion of your statement. I do get that and applaud you for staying with your focus. The product has to have a market and an identity. OTOH, it feels so close for guys like me in the Web dev world who know there's a better way!
>please do drop me a line (email in my profile).
Will do. And will try to reserve any web-dev specific comments. :)
>the web platform is so huge and sprawling, and constantly growing
>we've made the pragmatic choice to prioritise usability by non-web developers, and open an "escape hatch
Makes sense. And totally worth the tradeoff for the developer if it helps me flip the 80/20 rule around. And, if the component model is extensible such that, when I do have to open the escape hatch, I can plug a resulting component back into the framework (lay it out and set properties in the visual editor, etc.), that might be even more optimal. Either way, I'd rather a framework do the heavy lifting and let me deal with the edge cases than me do all of the heavy lifting and plumbing, so that's a win.
>and all of it's written in JS/HTML
And, this is the part where I do have to scratch my head a little. I'm going to guess you've heard this question 4,321,257 times, but why not support JS? It is the lingua franca of the Web (as your quote acknowledges) for better or worse, and virtually all devs already know it. There's also a rich JS library ecosystem.
The idea that I have to pick up Python just to try it out introduces more friction. I'm guessing that might slow adoption with a huge percentage of your potential audience who might otherwise have the knowledge they need to jump right in.