I think it's a more natural approach to you (and many others, including me a couple of years ago) because that's the way we used to do things, both on web (Java

I think it's a more natural approach to you (and many others, including me a couple of years ago) because that's the way we used to do things, both on web (JavaScript, CSS, HTML) and Android (Java, XML), and who knows where else. If you stop for a second and think about whether or not it's actually natural, you'll quickly realize that it's not, it's just something you are used to. I cannot give you anything Python specific, but I can share my experience with Flutter and Dart. In Flutter, you build your UI using regular Dart code and it feels great. This approach, btw, is also similar to Compose and SwiftUI (and to a lesser degree, JSX). Here are the pros: You don't need to switch from Java to XML, or from JavaScript to CSS/HTML, you can do everything using the same language. Instead of learning 2 or 3 languages (and their respective tools for testing, analyzing, linting, coding conventions), you can learn one well. You need to do some semi-advanced logic on the button label or classes? No problem, just write the language you write everywhere. An IIFE solves your problem nicely? It's okay, you can just use it. If you like working with Rx streams, or any other library, you can keep using them in your UI, no glue-libraries are needed. Need to debug or add logging, printing, error reporting? Your toolchain already supports that. Your IDE has terrible support for "insert templating language"? Not gonna happen here, if your IDE supports Dart (or in Pynecone's case, Python), you are good to go: you can jump to definitions, you can refactor argument names, and you can lookup usages exactly the way you are used to. You don't need to learn special syntax for conditionals, for loops, and whatnot, you just use your primary language. In Dart's case, you also win with the typing: if a widget expect a callback that receives a User instance and returns an integer, you can define that and making sure that instead of runtime errors, you will see the errors in your IDE as you type. You also don't need to worry about different naming conventions. If you app calls it userIds, your UI will also call it userIds, instead of "user-ids", or "user_ids".