4 ms·

We're trying! (https://anvil.works https://anvil.works) The problem with making a WYSIWYG designer for the web is that it's a Turing tarpit. There are three wh

We're trying! (https://anvil.works https://anvil.works) The problem with making a WYSIWYG designer for the web is that it's a Turing tarpit. There are three whole programming languages in there, interacting in weird ways, and programmers use all of them. So your UI designer has to either create something horrible that no human is expected to edit, which doesn't work for dynamic apps (see: Dreamweaver), or you have to constrain what the programmer can do. This means inventing a sensible API that's amenable to WYSIWYG. We took the latter approach with Anvil - we've cut the Gordian knot of HTML/JS/CSS by implementing a (VB6-like) component model, with a pure Python API. While I am, of course, biased, I think that's probably the closest we can get to what you're wishing for.

desireco42 9y ago
Hey, awesome work with Anvil. How difficult it would be, once app is created, to move it to standalone server? Just python and pg.
- meredydd 9y ago
  Thank-you! You'd need a standalone Anvil runtime for that, but it is something we offer. (It's one `docker-compose` command.) (The reason for this is that our client and server are deeply integrated. This is what lets us, eg, return a live database view from server code into client code with a simple function call, with full autocomplete. But it does mean we can't do a one-click "export as a Flask app".)
  - desireco42 9y ago
    I understand. Thank you for explaining.
heartbreak 9y ago
Is there a blog post out there on the reasoning behind choosing Python instead of JavaScript for that component model + API? Just seems odd to add a 4th language to the mix.
- true_religion 9y ago
  I'm just guessing but by using Python, they can go with a more robust module system, and there's a semantic break between Anvil's Language and its output. If they used Javascript, you might be confused because they'd process your Javascript into other Javascript before it's used on the site, and you can edit it. That's a bit confusing isn't it? Knowing to begin with that the input language is a whole separate thing, is less confusing.
  - meredydd 9y ago
    Spot on! If we used JS, it would be very difficult to maintain the firm layer of abstraction that gets us out of the Turing Tarpit. Also, to a first approximation, people don't learn JS on its own. You only learn it if you're already learning traditional front-end development. That's a journey we explicitly want to save people from - so we didn't want to use a language that only web devs know. Python is a lot easier to pick up for non-Pythonistas than JS is for non-web developers. Perhaps we should write that blog post...

desireco42 9y ago

Hey, awesome work with Anvil. How difficult it would be, once app is created, to move it to standalone server? Just python and pg.

meredydd 9y ago
Thank-you! You'd need a standalone Anvil runtime for that, but it is something we offer. (It's one `docker-compose` command.) (The reason for this is that our client and server are deeply integrated. This is what lets us, eg, return a live database view from server code into client code with a simple function call, with full autocomplete. But it does mean we can't do a one-click "export as a Flask app".)
- desireco42 9y ago
  I understand. Thank you for explaining.

heartbreak 9y ago

Is there a blog post out there on the reasoning behind choosing Python instead of JavaScript for that component model + API? Just seems odd to add a 4th language to the mix.

true_religion 9y ago
I'm just guessing but by using Python, they can go with a more robust module system, and there's a semantic break between Anvil's Language and its output. If they used Javascript, you might be confused because they'd process your Javascript into other Javascript before it's used on the site, and you can edit it. That's a bit confusing isn't it? Knowing to begin with that the input language is a whole separate thing, is less confusing.
- meredydd 9y ago
  Spot on! If we used JS, it would be very difficult to maintain the firm layer of abstraction that gets us out of the Turing Tarpit. Also, to a first approximation, people don't learn JS on its own. You only learn it if you're already learning traditional front-end development. That's a journey we explicitly want to save people from - so we didn't want to use a language that only web devs know. Python is a lot easier to pick up for non-Pythonistas than JS is for non-web developers. Perhaps we should write that blog post...