3,161 karma · joined April 15, 2008
Email: meredydd@anvil.works
Based in Cambridge (UK).
Drag'n'drop UI, Python in the browser and the server, one-click deployment - we're aiming for exactly that niche!
2. Python is the most popular language that isn't JS. It's used for teaching almost everywhere, it's used for data science, it's used on the back-end, even embedded code...
3. We wanted to start with an "island of sanity". If you google "how to do X in JS", you'll find StackOverflow and end up tweaking a DOM node, or making an HTTP request, or grabbing something else that breaks the abstraction and brings back the traditional Web hairball.
We want to make it easy to escape, of course (I wrote an whole essay about that[0]), but not so easy that you wander out of it without realising, and then find that the autocompleter no longer understands all of your project.
[0] https://anvil.works/blog/escape-hatches-and-ejector-seats
4. People who speak JS have already invested in the web - they've paid the price, got the scars, and probably have more than a little of their professional capital invested in "being a web developer". We want to win them over in the end, of course, but they would have been a very hard target market for an MVP!
It's the worst of both words: Even if you're using vim, you spend an awful lot of your time using (or debugging) tools like webpack, minifiers, live-reloaders, and of course the in-browser dev tools.
BUT, you still don't get the benefits of an old-school IDE, because no IDE can reason about a modern web stack reliably! Take something basic like click-to-code: "where is this attribute defined?" The web is such a Turing Tarpit[0] that, if that data comes from the backend, that question is literally undecidable. Between the database and that JS object are ORMs, backend frameworks, REST requests, microservices, JS frameworks, templating engines, and possibly CSS frameworks as well. At best, you can build good IDEs within one layer of the stack (I love WebStorm, and the VSCode+code-server stuff is cool - but they break down completely at stack boundaries).
[0] https://en.wikipedia.org/wiki/Turing_tarpit
And it's been like this for so long that new web developers don't even remember what it was like to have full autocomplete, everywhere in your project!
I have a dog in this fight - I founded a startup (https://anvil.works) to make web-dev tools, and we realised that to reason automatically about a web app you basically have to replace the whole stack. We went with Python - by doing Python front-end and back-end, replacing REST calls with function calls, and building a UI toolkit rather than generating HTML, it turns out you can have actual, real click-to-code, across your whole program. And full-stack autocomplete (I gave a talk about that one[1]).
If the Web is going to turn us all into tool mavens, at least we should do it right!
This survey is from FairShake, whose whole schtick is that they can represent you in an arbitration proceeding so efficiently that you can actually afford to participate. They got written up in the NYT the other month: https://www.nytimes.com/2020/04/06/business/arbitration-over...
The only reason I found out about this at all is that FairShake are a customer of ours (their whole dispute-resolution process runs on https://anvil.works), so I talked to them for our podcast (https://anvil.works/blog/podcast-fairshake). Even with the profanities edited out, I'm pretty sure you can hear the incredulity in my voice.
If they could, something would be terribly wrong: Something that could be done by two cofounders in the proverbial garage, and paid for by commercial industry, was instead consuming valuable research funding. A PhD, like any form of research, prioritises in discovering the unknown and expanding what we know, rather than seeking a commercial goal. (The exception is projects that "win the lottery": they went digging somewhere that's useful research but commercially unpromising, and stumbled on something directly monetisable. This is the case for most biotech, but it is - by definition - rare.)
But the people who do PhDs...that's a different matter. By the time you're eligible to do research, you've hauled yourself to the frontier of your chosen field, and fully grokked everything humanity knows so far about your topic. This kind of deep expertise can often pay off in solving an adjacent commercial goal.
Take my history: I did my PhD in usable programming systems. The actual day-to-day work (controlled experiments, inventing and analysing imaginary hardware extension, writing papers) wasn't even a little bit commercially relevant. But the experience, the surrounding reading, the techniques, and the knowledge I picked up from colleagues really set me up for when I started my startup.
These days, I head up https://anvil.works, making a programming environment for the web that doesn't suck (along with a cofounder who did his PhD a few offices down, in human-computer interaction). Would Anvil make a good research topic? Hell, no - it's recycling good ideas from the last 20+ years. Do our research experiences make us really well positioned to solve this problem? Absolutely.
Having read to the bottom, the quality of text generation there absolutely blew me away. GPT-2 texts have a somewhat disconnected quality - "it only makes sense if you're not really paying attention" - that this article lacks entirely. Adjacent sentences and even paragraphs are plausible neighbours. Even on re-reading more closely, it doesn't feel like the world's best writing, but I don't notice major loss of coherence until the last couple of paragraphs. I am now really curious about the other 9 attempts that were thrown away. Are they always this good?!
[0] https://en.wikipedia.org/wiki/Canary_trap#Barium_meal_test
Now, perhaps this doesn't matter to Gravitational. Perhaps any potential Teleport customer instantly understands what it is, and the confused onlookers are collateral damage.
But to me, it looks like the non-employee commenters are doing a better job summarising your product than you are. I strongly suspect this means you're leaving something on the table.
That said, in order to support `eval` and friends, you still need a full-fat compiler in the browser. So the best route is probably to use a full-service Python->JS compiler, but compile most of the code ahead of time. That's where we're heading with Anvil (we use https://skulpt.org for the client side, but it's the same principle).
My colleague wrote up a pretty wide-ranging comparison of browser-based Python interpreters. It describes how (and why) Brython, Batavia, Skulpt, Transcrypt, and Pyodide differ, and the tradeoffs they're chasing:
1> For the employees, [post-acquisition] is business as usual for the most part. The goal is for the employees to not even notice.
2> You can buy companies and replace expensive people with a global remote workforce that is just as good (or better) and cheaper.
Can someone with more knowledge or experience of Tiny acquisitions explain which of these is true? Are they a holding company for SaaS companies with extra best practices, or a cuddly face on traditional PE cost-cutting tactics? The article itself doesn't seem sure. (And, oddly, appears not to notice the contradiction.)
https://anvil.works/open-source
(And yes, it even works with the Free plan)
A colleague of mine collected and compared a few Python-in-the-browser implementations - including Skulpt and Pyodide - with code samples and a description of the trade-offs.
You might find the write-up interesting: https://anvil.works/blog/python-in-the-browser-talk
At PyBay last year, I ended up with a knot of Python core devs talking about this problem, and talking about building a better, more portable API for native modules. The transition would be nasty (the 2->3 transition was..scarring), but it would solve this problem at a stroke.
> I very much prefer Python over JavaScript for example, but even then it wouldn't cross my mind
I would encourage you to at least check out Anvil (https://anvil.works). It's more than a Python->JS compiler; it's a reimagining of what the web as a platform could look like.
FWIW, I agree with you that it's a bad idea to swap out JS for Python at one layer, while keeping the rest of the stack intact. It's extra complexity, and it doesn't solve the actual problem with the Web, which is the sprawling complexity of the stack and all the weird frameworks that work around it (while themselves making the problem worse).
The Big Idea of Anvil is to replace all those different layers of abstraction with one big, coherent abstraction. That's one reason why we deliberately chose Python rather than JS, so that users wouldn't reflexively reach out and break that abstraction every time they Googled how to do something.
Skulpt compiles Python to JS in one shot, so it's not a million miles away from the architecture Brett envisages. (I gave a lightning talk about it here: https://anvil.works/blog/pycon-talk).
Things I've observed:
- "Ordinary code" requires remarkably little fidelity. Python has a very strong "simplicity culture", so most code avoids being clever. If you're creating an environment for users to program against (as we do in Anvil), it's astonishing how little of Python you need to support.
- "Be able to use popular Python libraries" is really, really hard. The ordinary user doesn't use all the esoteric stuff Brett mentions, but libraries do, left and right. Even porting PyPy's `datetime` implementation to Skulpt required filling out a lot of odd little corners of the object implementation.
We still have a pretty crummy subset of `unittest` because it's eye-achingly dynamic - for example, it really puts metaclasses through their paces. (Metaclasses are a perfect example of a powerful feature that really depends on details that descend directly from CPython: The API exposes the fact that variable scopes are literally `dict` objects, that classes are created dynamically at runtime, etc.)
- Finally (and most unfortunately): A lot of the strength of Python is in its ecosystem, and a lot of that ecosystem relies on native code. (Again, much more than you'd think. When porting stdlib modules from PyPy to Skulpt, we have often been disappointed by how many of them use native code - even in PyPy!)
The Python-to-C interface is really, really CPython-shaped. Anyone who wants to be compatible with numpy, scipy, etc, needs to literally emulate CPython's data structures, and then translate them to whatever faster/simpler thing they use internally. This emulation overhead is the main reason PyPy is slower than CPython on some workloads. (In Skulpt, we haven't even attempted this. It doesn't bother us much in Anvil, of course, as the server-side CPython is just a function call away, but for Brett's use case I'm guessing it would really hurt. One day we might try, with a JS-to-wasm bridge and doing the emulation in wasm, but it would be a hell of ajob.)
Help us fix web development at Anvil (https://anvil.works)!
Anvil is a platform for building full-stack web apps with nothing but Python. That's Python in the browser, Python on the server - even a Python UI toolkit with a drag-and-drop designer! It's faster and easier than traditional web tools, but it's got all the power of an industrial-strength language, ecosystem and tooling. We open-sourced our runtime a few weeks back: https://anvil.works/blog/why-open-source
We’re looking for developers with great communication skills, to show people how to build awesome things with Anvil. You’ll be writing how-to guides, blog posts and tutorials, building example apps, presenting Anvil at conferences (when those resume), and helping our users – from individual developers to huge tech companies – build their applications. And then you’ll help us work out how to improve Anvil for them.
It's rewarding work – developers love being introduced to Anvil (our stand is always crowded[0] at conferences!). Plus, there are all the advantages of an early-stage startup: lots of autonomy, and huge impact.
We're bootstrapped and profitable, with customers ranging from tiny to enormous. Find out more: https://anvil.works/jobs
-
Help us fix web development at Anvil (https://anvil.works)!
Anvil is a platform for building full-stack web apps with nothing but Python. That's Python in the browser, Python on the server - even a Python UI toolkit with a drag-and-drop designer! It's faster and easier than traditional web tools, but it's got all the power of an industrial-strength language, ecosystem and tooling. We open-sourced our runtime last month: https://anvil.works/blog/why-open-source
We’re looking for developers with great communication skills, to show people how to build awesome things with Anvil. You’ll be writing how-to guides, blog posts and tutorials, building example apps, presenting Anvil at conferences (when those resume), and helping our users – from individual developers to huge tech companies – build their applications. And then you’ll help us work out how to improve Anvil for them.
It's rewarding work – developers love being introduced to Anvil (our stand is always crowded[1] at conferences!). Plus, there are all the advantages of an early-stage startup: lots of autonomy, and huge impact.
We're bootstrapped and profitable, with customers ranging from tiny to enormous. Find out more: https://anvil.works/jobs
-
He cites some obviously real examples of institutional dysfunction (hi, San Francisco zoning!). But these examples are all (or are all portrayed as) institutions "hindering", "stifling" or "limiting" otherwise beneficial processes. This implies a worldview in which the only thing institutions do is get in the way of "the freedom to build", and the only implied remedy is to get them out of the way.
This is counterproductive, because it takes us straight back to the "government is [bad/good]" argument. These arguments haven't got us anywhere so far, even - indeed, especially - in Silicon Valley, which features one of the world's highest concentrations of libertarians.
(My amateur hypothesis: If you approach institutional reform with an agenda of dismantling those institutions, that's a recipe for scorched-earth resistance from anyone who believes in that institution's goals - however well or poorly that institution is currently functioning. This leads to the worst of both worlds: dysfunctional institutions, held in stasis by the tug-of-war going on around them.)
If you really believe in institution-building, you should be able to cite some examples of what they should be able to do more or better. Otherwise, you're just advocating old-school deregulation and calling it "building".
Tyler Cowen's summary of "state capacity libertarianism", which this article cites, is much preferable on this score: It is explicit about what Cowen believes institutions should do (and do well), as well as what they should not: https://marginalrevolution.com/marginalrevolution/2020/01/wh...
In this case, there is a broad ongoing argument about Google and its products [jumping the shark/being evil]. That argument is so much fun that, as I write this, almost every single top-level comment in this thread is a salvo in that argument, only tenuously connected to the OP. This article is just a convenient place to have the argument.
(I have a personal learning experience here: The first article of mine that hit the HN front page was a writeup of a PyCon talk entitled "To Make the World Better, Remove Some Javascript from it"[0]. It also shot to the top within minutes, and was [defensibly] flagged off the front page very quickly, because the title alone immediately turned it into a place to argue about JS [not] being evil, rather than discuss the Python-to-Javascript compiler I was talking about. Suffice it to say that subsequent articles have been more modestly titled!)
Help us fix web development[0] at Anvil (https://anvil.works)!
Anvil is a platform for building full-stack web apps with nothing but Python. It's faster and easier than traditional web tools, but it's got all the power of an industrial-strength language, ecosystem and tooling.
We’re looking for a developer with great communication skills, to show people how to build awesome things with Anvil. You’ll be writing how-to guides, blog posts and tutorials, building example apps, presenting Anvil at conferences, and helping our users – from individual developers to huge tech companies – build their applications. And then you’ll help us work out how to improve Anvil for them.
It's rewarding work -- developers love being introduced to Anvil (our stand is always crowded[1] at conferences!). Plus, there are all the advantages of an early-stage startup: lots of autonomy, and huge impact.
We're bootstrapped and profitable, with customers ranging from tiny to enormous. Find out more: https://anvil.works/jobs
-
[0] Yes, web dev is broken. Here's the conference-talk-length rant, and the case for Anvil: https://youtu.be/6hHQKUeTL1U
[1] https://anvil.works/blog/img/how-many-t-shirts/crowd.jpg
- Drag'n'drop UI design (https://anvil.works/docs/client/quickstart)
- Python code (browser-side and server-side)
- A built-in database (https://anvil.works/docs/data-tables/quickstart)
- Multi-user support out-of-the-box (https://anvil.works/docs/users)
- Built in email/cron/secrets/etc
- Plug-in integration with Python code running anywhere else on the internet. You import a library, it connects via websocket to your hosted app, you get two-way RPC between your code any your app (https://anvil.works/learn/tutorials/jupyter-notebook-to-web-...)
As other replies have pointed out, the really successful tools are like Excel: They have a real programming language at the heart of them, and they don't try to hide it away.
Disclaimer: I founded and run something you could call a "Low-Code web environment" (https://anvil.works) - but I prefer "Visual Basic for the Web" (or "Web Apps With Nothing but Python"). We built it around the idea that writing code is inevitable - indeed, it's the best way to tell a computer what to do. So don't try to hide it - make it a first-class experience!
It is tempting (albeit a bit snobbish) to think that "CRUD apps", as a category, have so little logic that you can describe a useful working version without code. I just don't think it's true - they are always shot through with squirrelly business logic.
You can carve off products like form builders (eg Google forms/Airtable/etc), but anything you'd describe as a "CRUD app" contains an amount of logic that's just painful to describe without code. (And the form builders know it, which is why they don't support those use cases!)
We have been programming computers for most of a century: 71 years this year. And in all that time, nobody has come up with a better way of telling a computer what to do than writing text in a programming language. People keep trying, of course, with endless permutations of flow-charts and rules. But sooner or later, you'll find yourself either:
(a) unable to express what you need to express, or
(b) tangled up in Cthulu's own flow-chart, barely accomplishing something that you know is a three-line `for` loop in Python.
And the thing is, anyone calling their system "low code" (rather than "no code") knows this. They know that the shiny demo can't actually do all you need. The moment you want to build something they haven't already imagined, you fall off the edge of the world. That's why they hedge, and say "sure, you might write a little code". Then the trap-door opens underneath you, and you go straight from a click'n'drag flowchart to writing a React component (or worse). Not fun.
I cofounded Anvil (https://anvil.works), and if you squint hard you could call it a low-code platform for web apps. But many valuable apps are a fifteen-line Python script surrounded by fifteen tons of JS framework. The problem here isn't the application logic - it's everything else! So build a drag'n'drop designer, and a VB/Delphi-like component UI, then get out of the way and let the author write their app logic in peace. When your users try to do something you haven't thought of (and they will!), they'll have an industrial-strength toolbox to deal with it.
But to tell someone that they can build substantial apps without writing code is to invite them to drive at speed up a blind alley.
And then I googled up some of the articles[0] that were written in the aftermath, and whaddaya know, they credit ex-Twitter people. I guess the skill generalises :)
[0] http://newrelic-wpengine.netdna-ssl.com/wp-content/uploads/8...
It was inspired by the 'xkcd' matplotlib theme, which itself is delightful: https://matplotlib.org/xkcd/examples/showcase/xkcd.html
https://anvil.works is the tool. It is quite explicitly based on VB and other systems like it: it's got a drag-and-drop UI designer, backed by Python. Double-click a button, and edit the Python code that runs when it's clicked. You write Python on the front end (we transpile to JS), Python on the back end, and we host it for you with a click. Check it out!
Search boxes? Sure! App titles? Yeah, one week a bunch of our users' apps got renamed to the author's email address.
Being an IDE, of course, there are lots of places where inserting random text will break things. When I open up the console and see it filled with "'meredydd@anvil.works' is not a valid Python identifier"? That's the signal to go hunting for which dynamically-generated off-screen text box Chrome is stuffing credentials into this week.
TL;DR Chrome's autofill is out there. It can't be bargained with. It can't be reasoned with. It does not feel pity or remorse. And it will not stop.
I have ranted at length before on the reason that the Web is not amenable to RAD tooling. The short answer is that you have five different programming languages (HTML+JS+CSS+Python+SQL), with each component generating source code in another language, and that's impossible for a single development tool to manage sensibly.
To take one example: One of the best things about VB6 was autocomplete. But there's no sensible way to autocomplete what keys are in a JSON value that's been generated by a REST endpoint written in Python serving data from generated SQL, all with about 4-5 different frameworks in the way.
So for Anvil, we dispensed with that and did everything in one language (Python). Python on the front end, Python on the back-end, a Python-native database, a drag-and-drop designer producing UI components that are Python objects...and all of a sudden, it's all one representation and you can autocomplete it!
(I gave a talk about how the autocompleter works at PyCon UK a couple of years back: https://anvil.works/blog/python-autocompleter-pycon17)
I'll start with the one I founded: Anvil, which is an end-to-end Web dev system with Python (plus a drag-and-drop UI builder, and lots more good stuff): https://anvil.works
Here's our version of how to turn a Jupyter notebook into a web app: https://anvil.works/blog/jupyter-notebook-to-web-app
(tl;dr there's a library you can `pip install`. It makes a websocket connection to Anvil, and then your code - wherever it's running, including a Jupyter notebook - can do everything you can do in our serverless environment, such as handling requests from browser code.)
But of course, we are neither the first nor the last to think Python in the browser is a good idea. A colleague of mine did a survey and comparison of the major open source implementations (including PyIodide, which you mention, and Skulpt, which is what Anvil uses):
https://pythontips.com/2019/05/22/running-python-in-the-brow...