We make an open-source web framework, an online code editor, a GUI builder, and a PaaS hosting platform. Together, it's a platform for building and hosting full-stack web applications, entirely in Python.
Web development is way too complicated, especially if you're not a professional full-stack dev. So we're fixing it: Instead of writing JS/HTML/CSS/Python/SQL and all the associated frameworks, Anvil enables developers to design pages with drag-and-drop, write Python that runs in the browser and on the server, set up a database, and deploy their code instantly as a hosted service.
---
1. Senior Developer
We’re looking for an experienced all-rounder who's comfortable with a variety of technologies to work on the core Anvil platform, with a focus on back-end and systems engineering. Our stack is mostly Clojure, Javascript, Python, Postgres, and container tools – but we're looking for someone who isn't afraid to jump into something you haven't used before.
You’ll be working with seriously good all-rounders, including the founders (PhDs in programming usability, kernel contributors, builders of backyard dancing fountains) and senior colleagues (a former maths teacher who went from “teaching Python to students” to “reverse-engineering Anvil’s designer to build better UI components” in months), as well as our other developers and developer advocates. It’s a small, smart, friendly and diverse team, and all of us care deeply about building interesting technology that makes life easier for other developers.
Building dev tools is great! We're solving problems we have ourselves, our customers are developers just like us, and platforms get the best engineering problems.
---
2. Developer Advocate
We’re looking for a developer with great communication skills to show people how to build awesome things with Anvil, and to make Anvil better to use.
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 companies – build their web applications. You’ll then use what you’ve learned to help us make Anvil better to use. That might mean deciding what examples to build, or it might mean deciding that we need to redesign the first-run experience for the Anvil Editor – and then doing it.
It's rewarding work – developers love being introduced to Anvil (we get mobbed at conferences!). Plus, there are all the advantages of an early-stage startup: seriously smart colleagues, small team, lots of autonomy, and huge impact. (Did I mention we're diverse, friendly and supportive?)
---
For full job descriptions, and to hear what it's like working here, go to https://anvil.works/jobs.
We work hybrid (in the office in Cambridge Tue-Thu, wherever you like Mon/Fri).
If you have questions, reach out to me - I'm a founder, and my email's in my profile.
It's quite explicitly VB-esque (only using Python), and having a single paradigm rather than stitching together several different programs speeds things up even for those who can write HTML/JS/CSS in their sleep. (And of course, you can drop out to JS/CSS/HTML if you want.) Overall I think the development speed is comparable to VB6.
I started with Delphi 5 and completely share the sentiment of OP, development experience (mainly when building GUIs) was way better back then. For anyone who feels similarly I can only recommend you to look into Anvil. It is a fantastic tool, under active development and with a helpful and supporting community. It allowed me to build web apps by myself that I previously thought about hiring someone for. Very enjoyable experience and of course the fact that I am building web apps instead of desktop apps is a big plus in many scenarios today.
Great to see you here, Merdedydd! I was thinking about sending this thread to you. I discovered Anvil in a similar thread years ago and am very happy I did.
But VB also didn't host web apps for you including databases, user accounts, email etc. I think self hosting is an option with Anvil by now, in which case you may be able to remove the branding.
> something like Pynecone that targeted html/dom/js directly instead of wrapping node/react/next
This might not be what you were imagining, but I think this js more or less what we built at https://anvil.works (I'm a founder).
Anvil's UI toolkit is built "straight on the DOM", and it's shaped like Python objects rather than going via some other React-y abstraction. This is possible because we expose the difference between client and server code - even though they're both in Python (transpiled as necessary), and you can make mostly-transparent function calls from one to the other. Contrast Pynecone, where the UI is "puppeteered" from the back end over a websocket, so every update is a round-trip. And of course, because you're writing in-browser code, the HTML/JS interop is pretty straightforward (in fact, you can import JS objects right into Python code).
There are downsides to our approach, of course - the developer needs to understand the difference between code in the browser and on the server, which can be a hurdle, and it's really neat that Pynecone apps can be a single Python file - but you don't have to round-trip every UI update to the server, and we've seen people have scaled up to some pretty big apps with Anvil!
Anvil has been great. I'm a happy subscriber. As someone requested above for Pynecone, could Anvil also make a tutorial for creating ChatGPT clone (UI wrapper for ChatGPT/gpt-4) using Anvil?
Agree a little different approaches, we found many developers wanted to stick with a 100% code approach and avoid the constraints of using an online drag and drop builder like retool/anvil etc. Instead opting to stick a traditional code tech stack that provides benefits like easier version control with ui and reviews with larger teams. Where as with a low code tool you are now forced to develop on the ui platform and locked in by the vendor.
We have also had some users build some fairly large Pynecone apps including our whole website built in our own framework.
Oh, yeah - "text in a Git repository" is table stakes for developers. Ditto being open source to avoid lock-in. (Which is why Anvil has both! You can check your code out, edit in VS code, and host locally.) But if you want a visual UI editor, you gotta have the tooling somewhere...
Aside: I get grouchy about the term "low-code", mostly because it's almost always a lie (you're going to need the code, and most "low-code" systems just hide how much that's going to hurt - which is why we put the code front and centre), and it causes people to lump Anvil in with, eg, Retool rather than, eg, Pynecone/Viola/Beeware...but this is definitely getting off topic ;)
Interested to hear how your scale-up/B2C users deal with the round-trip delays - I guess that's less of a deal with websites than interactive apps? (Should probably have grabbed you at PyCon to ask, but we were both pinned down pretty hard! I did manage to wave at you though, I think...)
Will be improved in the future as we start to offload client side actions with wasm, starting to do this but the python wasm ecosystem is still maturing
slight aside, but it's refreshingly pleasant to see a cordial discussion between representatives of two competing aproaches. HN is better than some other sites, but there's still a fair bit of polarised "my choice is right and so yours is wrong".
I didn't know about either Pynecone or Anvil, and have a side project for a friend that might be well suited to one/both. So I'm both more enlightened on options, and more predisposed to both given the positive dialogue here. Thanks for both.
> Find a UK-domiciled USD account to pay out to. Might be possible - no idea really. Need to look into it.
FWIW one of these was readily available from my existing bank (Barclays) last time I needed one (~10yrs ago). Bit of hoop-jumping to go through, but definitely worth it for $30k/year.
There are actually quite a few Python-in-the-browser implementations, not just those two! A couple of years ago a colleague of mine wrote up a comparison, including Brython and Pyodide:
(We chose one of the Python-to-JS compilers, https://skulpt.org, for the Anvil web-app platform, because it's much lighter weight than this. It's a couple of hundred kb on the wire, and you can call to the server for any heavy lifting.)
This article accurately describes a problem, but while it claims to talk about digital media in general, it is really just talking about Twitter.
Here's the giveaway:
> A huge part of the problem is that digital spaces generally have no equivalent of a disapproving glare.
Every. Single. Platform. has an equivalent to this - except Twitter. Reddit (and HN) have visible downvotes. YouTube's downvotes, invisible though they now are, can at least influence the recommender algorithm. Even Facebook has "frowny emoji" reactions. But on Twitter, the only way to express disapproval is to "join the conversation" - thereby amplifying it, and incurring all the negative consequences Devon explores.
It's engagement genius. (Accidental genius, naturally - like most of Twitter's "core game loop", it's an unforseen, emergent phenomenon about which its inventors seem faintly embarrassed). The "grifter" problem Devon mentions exists almost exclusively on Twitter, because it's incentivised by the platform!
Normally I wouldn't get so heated about this stuff, but Twitter has attracted a critical mass of the world's journalists, so its incentives flow directly into The National Conversation(TM). This has visibly malign results, prompting many people to look for ways to fix it. This is a noble aim, but won't get anywhere if we regard Twitter's design decisions as immutable and inevitable, rather than a deliberate choice.
I don't think downvotes/emojis work the same way as real life human feedback, at all. On places like reddit, downvotes more often than not incite anger or resentment in the recipient, whereas strong negative feedback in real life is a much more powerful form of feedback that can trigger embarrassment and shame, which at least can lead to self reflection. I's much easier to make a fool of yourself on reddit then in from of living, breathing people.
Being anonymous is a big part of this. There is very little consequence of being controversial online if you're just another person posting (and not, say, a celebrity where your presence means something offline too). The most might be people noticing that one particular person is stirring up trouble (and block them). Offline conversation has the benefit of being in real time. The other person almost has a social obligation to listen and respond. In addition, you know it's a real person that you're talking to (although, with people spending more time online, their real-life etiquette has changed for the worse; people shout, berate and threaten others like there is no consequence). Online conversation is static; you can ignore it, and nobody will know. Anybody can read it at any time as if you were continously shouting it. Nobody is obligated to respond or pay attention. You have no idea if the person responding or commenting is real, or is just a bot, or is a troll trying to make you irrational and angry. It's terribly confusing.
It's extremely annoying to spend time thinking about and carefully writing something only to have it downvoted by unknown people for unknown reasons.
And anything vaguely political or controversial is the kiss of death for downvote systems because it triggers upvote/downvote wars where downvote becomes "I disagree with this viewpoint (so it must be downvoted to oblivion.)"
> YouTube's downvotes, invisible though they now are, can at least influence the recommender algorithm.
YouTube's algorithm is opaque, so obviously folks could be wrong about this -- but there's a pretty common belief that dislikes actually cause a video to be recommended more often, making it not really that much of a disapproving glare. Same with the Facebook frown, except that FB is pretty open about it.
People think a lot of obviously wrong things about various social media algorithms, and this might be one of them, but in a way that's beside the point. The belief is sufficient to negate the social pressure effect, regardless of how well founded that belief is.
Well they also aren't bad things: they count for two likes and are used to indicate sadness, not disapproval. According to articles on the ranking decisions, Facebook internally calls them "Sorry". You don't want to take a post where someone says something sad and people react with sadness and say "this is bad content".
I think you're confused. Facebook has both a "Sad" reaction and an "Angry" reaction. They can both be used to agree with and disagree with the recipient, depending on context.
Ah, and you believe the original post here was talking about Angry, not Sad? (I have a hard time reading "frowny" in general non-Facebook contexts as "angry" instead of "sad", but I also have a lot of weight using the term over the years as part of "frowny pants" and so might be biased.) FWIW, all "reactions"--including Angry--were worth two Likes when they were first introduced (maybe maybe there was one that was worth 1.5? though I think it was all 2.0), but Facebook recently downmodded Angry (only) to be worth zero (but not act as a counter-signal). And, as you seem to understand--though I feel like you fail to appreciate the gravity--neither are inherently negative reactions: if you post something about vaccines (say, to choose something that people get super upset about) and you get a thousand Angry reacts, there is literally no way to know if those people are angry at YOU for posting the article or angry at the CONTENT you posted (commiserating with you), and so this mechanism simply doesn't serve as a "disapproving glare" as it isn't merely context-dependent but subjective in meaning.
The reactions I see are a sad crying sad face with a single tear and an angry red frown. Neither of those would be described as a frown. You are right that neither is something that could be used to tell someone they are being inappropriate.
> YouTube's downvotes, invisible though they now are, can at least influence the recommender algorithm.
YouTube has this feature, but the information it signals is now hidden from the public. The hiding of dislikes have essentially nullified the disapproving glares of the surrounding audience. I'm wondering what the ultimate effects on viewership will be, and the effects on the algorithm might not be in the favor of viewers.
A theory I have is that the lack of dislikes could make potential viewers more anxious that they could be stepping into misinformation at any time and have no easy (even if unreliable) way of checking veracity, so they choose to engage with less content overall.
I have also heard that if someone dislikes a video after watching it all the way through, it still counts them as "engaged" and doesn't negatively impact the channel's exposure. That would mean that a viewer could be mislead into thinking that a dislike means "nobody should watch this", whereas the effect is actually the opposite for the platform's algorithm.
I would really like to see hard data on this from a YouTube channel with significant viewership, detailing how the view count and engagement have changed since dislikes were hidden. If YouTube claims that dislikes don't influence viewership, there should at least be evidence that it is so.
I have not been able to figure out if the YouTube downvote means "this video is bad and should not exist" or "it's a good video but I'm not interested".
Nor has anyone else, which makes attempting to use these mechanisms as "signal" somewhat circumspect, and only gets worse once you take into consideration the mathematical issues with trying to then "average" a bunch of unrelated metrics (something people love to try to do with five star ratings even though it is well-documented as returning garbage; the only reason it is sometimes better than nothing is because nothing is a pretty low bar for a competitor to defeat ;P), but I'd say one of the key issues is actually the sampling bias of "who bothers to vote": different topic posts attract different kinds of people (or are barraged by niche audiences) who are quite likely to react to really awkward things that are ancillary to the correctness or quality.
This problem even happens in places you might fail to notice if you aren't paying attention: as an example, with ratings for hotels, depending on the location--even for what is essentially a cookie-cutter franchise--hotels attract different audiences, and so the ratings people leave mean something different! I noticed this often as a I (used to... damn pandemic ;P) travel a lot, and in some cities (like San Jose) all the reviews of a Marriott would be talking about how useful the rooms are for parties, as a lot of the people booking hotels are doing so for tech companies, whereas in another city (I can't think of an example but imagine some place you would usually go on for a vacation instead of a conference) all the reviews would be focused on whether or not the pool was a fun and safe place for their children. I frankly care about neither of these qualities of a hotel :/.
What you probably want to do is enough "collaborative filtering" to only care about voters who are similar to you. This is the kind of thing people were talking about a lot back in the days of the Netflix prize competition (which had an amazing forum they deleted :/), with k-means clustering of users trying to figure out which subset of votes "matters" to you, and people thought this would be the future and how every site worked... but then Netflix seems to have just gone in a direction of extremely simplistic category affinity (and even removed five star ratings recently). In my case, this would eventually (hopefully) case me to ben heavily weighting people who tend to rate a hotel based on the quality of its bed and the smell of its air, to the exclusion of almost every other rating axis.
The reality is that--for better or for worse--platforms refuse to actually provide rich signaling for these mechanisms (and what they do do is sometimes misunderstood: like, it actually irks me that this grandparent post thinks a Facebook sad react is supposed to be bad somehow: if you say something and I react "Sad" I might very well be commiserating with you... and Facebook knows this so Sad is worth two Likes! fwiw, they did finally decide to make Angry worth 0 ;P) and even--such as the case of Netflix--tend to remove and "simplify" signaling mechanisms over time, and so none of these mechanisms they have "matter" really as they are so low signal and are used so naively.
The only content platform I can think of that "got big" (but isn't anymore) which really tried hard to work on this problem is Slashdot, which asked you why you were downvoting something, and then 1) required you to choose whether you got to comment anywhere at all on the post's thread OR vote on any of the comments and 2) would show your voting decisions to other people who would "meta-moderate" your decisions to decide how good you were at it and then change how often you were given the option of voting. This way you could actually separate out "tyranny of a majority that I think is dumb" from "this comment is actually off-topic or an attempt to incite chaos".
As someone who rarely uses Twitter but scrolls through Facebook every now and then, I strongly disagree.
I read a joke once that went something like "On Facebook, I spend half my time deciding if I want to debunk pseudoscientific bullshit, or if I want to have friends." Point being lots of times I'll have friends or acquaintances post shit where I think "Did this person just suffer a head wound?", but if it's someone I want to remain friends with, I just scroll by it. I often wonder if that person noticed they usually get tons of positive emojis with other posts but it tends to be crickets when they post their "I'm just doing my vaccine research" posts or whatever other bullshit.
Down votes don't mean your comment was made in bad faith or unhelpful. It means somebody who has amassed more than 500 karma disagrees with you. Let's not kid ourselves about what karma, Reddit gold, or any such approach actually is used for.
Unfollowing someone is the best way to get their tweets in your timeline with the current state of Twitters algorithm. You were interested enough to follow and mad enough to unfollow == engagement.
For anyone else who couldn't make head or tail of the linked page, there's more context at https://pipewire.org/ :
PipeWire is a project that aims to greatly improve handling of audio and video under Linux. It provides a low-latency, graph based processing engine on top of audio and video devices that can be used to support the use cases currently handled by both pulseaudio and JACK.
Never did any audio programming, I still can't make heads or tails out of it. Is it expected that an application sets up some processing graph for an engine to play a sound? [1] Instead of writing samples to a buffer in a loop? Who wants that?
Also, while I don’t know the project yet I can see the benefit in building something from the ground-up in a way that embraces multi-process “in/out” pipes. Someone could have dozens of effects all connected to the audio signal, then run that to dozens or hundreds of outputs (streams online, multiple speakers, recording applications, analog mixer inputs...). Traditionally that kind of usage is fragile as memory corruption can happen at any stage since everything is writing/reading the same buffer. If they have a true graph implementation then applications could interact with the graph edges and the overall system would be much more robust.
And doesn't processing necessitate buffers? How does this approach reduce the number of buffers involved? If anything, it sounds like less sharing would mean more buffers.
I don't know of very many applications that use PipeWire directly (at least for audio); usually a program would target some other Linux audio API (ALSA, PulseAudio, JACK), for which PipeWire would provide the necessary plumbing and libraries to be a drop-in replacement for those older APIs.
Side note, why is posting a link to a changelog a common and accepted way to share links on HN? You are correct, reading the linked page is pointless until we understand what PipeWire is.
We make an open-source web framework, an online code editor, a GUI builder, and a PaaS hosting platform.
Anvil is a platform for building and hosting full-stack web applications, entirely in Python. We're looking for developers to help us build our hosting platform-as-a-service, online code editor, and drag-and-drop GUI designer, as part of a small, friendly and diverse team.
Web development is way too complicated, so we're fixing it: Instead of writing JS/HTML/CSS/Python/SQL and all the associated frameworks, Anvil enables developers to design pages with drag-and-drop, write Python that runs in the browser and on the server, set up a database, and deploy their code instantly as a hosted service.
Behind that magic is a lot of work - and that's where you come in. You'll be working on the Anvil editor (that's the dev environment, code editor, drag'n'drop designer, version control, and so on) and the Anvil runtime (that's the Python-to-JS compiler, UI toolkit, database back-end, API router, integrations and infrastructure that make it all go). A lot of your work will be open source.
Building dev tools is great! We're solving problems we have ourselves, our customers are developers just like us, and platforms have the best engineering problems.
We're hiring both senior and junior developers, front-end and back-end. Our stack includes:
Not pretending to be in the same league as The Daily, but we have a more tech-focused interview with Teel Lidow (the guy I think you're talking about - he's the lawyer who founded FairShake, the company in that NYT article) for the Anvil podcast, along with their tech lead.
Fun fact - the entire thing was prototyped by the lawyers using no-code systems, then only rewritten with an actual Web framework when they had proven out the idea:
We make an open-source web framework, an online code editor, a GUI builder, and a PaaS hosting platform. Together, it's a platform for building and hosting full-stack web applications, entirely in Python.
Web development is way too complicated, especially if you're not a professional full-stack dev. So we're fixing it: Instead of writing JS/HTML/CSS/Python/SQL and all the associated frameworks, Anvil enables developers to design pages with drag-and-drop, write Python that runs in the browser and on the server, set up a database, and deploy their code instantly as a hosted service.
---
1. Senior Developer
We’re looking for an experienced all-rounder who's comfortable with a variety of technologies to work on the core Anvil platform, with a focus on back-end and systems engineering. Our stack is mostly Clojure, Javascript, Python, Postgres, and container tools – but we're looking for someone who isn't afraid to jump into something you haven't used before.
You’ll be working with seriously good all-rounders, including the founders (PhDs in programming usability, kernel contributors, builders of backyard dancing fountains) and senior colleagues (a former maths teacher who went from “teaching Python to students” to “reverse-engineering Anvil’s designer to build better UI components” in months), as well as our other developers and developer advocates. It’s a small, smart, friendly and diverse team, and all of us care deeply about building interesting technology that makes life easier for other developers.
Building dev tools is great! We're solving problems we have ourselves, our customers are developers just like us, and platforms get the best engineering problems.
---
2. Developer Advocate
We’re looking for a developer with great communication skills to show people how to build awesome things with Anvil, and to make Anvil better to use.
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 companies – build their web applications. You’ll then use what you’ve learned to help us make Anvil better to use. That might mean deciding what examples to build, or it might mean deciding that we need to redesign the first-run experience for the Anvil Editor – and then doing it.
It's rewarding work – developers love being introduced to Anvil (we get mobbed at conferences!). Plus, there are all the advantages of an early-stage startup: seriously smart colleagues, small team, lots of autonomy, and huge impact. (Did I mention we're diverse, friendly and supportive?)
---
For full job descriptions, and to hear what it's like working here, go to https://anvil.works/jobs.
We work hybrid (in the office in Cambridge Tue-Thu, wherever you like Mon/Fri).
If you have questions, reach out to me - I'm a founder, and my email's in my profile.