I love it. But seeing this now, in 2017, is a bit depressing to me.
For the last 15 years Microsoft has been putting out the same RAD tools, but based on ASP.NET/C#/Visual Studio. Things like drop-in provider-based OAuth, editing versioned database projects, WYSIWYG UI, etc. Publishing to the web, even the flow of clicking on a button to edit its handler looks like it was based directly on Winforms which is a 12 year old technology.
Why aren't there more of these things out there?
How much time now is spent learning the latest and greatest framework/toolkit/etc. only to spend more time configuring individual components and cobbling them together vs. just getting the product finished and published to users? I don't mean to be cynical but I wish there was some way all these different tools somehow built on each other instead of constantly resetting the dev stacks.
For example, Create React App - I'm constantly impressed by how it has eschewed configuration in favor of getting things done while still having a lot of flexibility. It draws on a lot of great, previous past projects and seems to define the train of thought for other react projects. It seems to me that people like Dan Abramov, Brent Jackson, and others are on the same wavelength which is incredibly powerful for the react community.
There should be a way for that sentiment to extend beyond React, into the database world, the IDE world so that we can collaborate and create more nice things like this.
> Why aren't there more of these things out there?
There are a few - I did like the MS PowerApps recently. But these things work well in an enterprise environment where "works" is important, but "users don't want to kill themselves during interaction" is not. These tools are usually great at putting together a quick CRUD app that fits requirements. But they're typically not flexible enough to give you that finished and polished for users product. If you want to do that rather than a flow of basic forms and tables, you'll start fighting the framework at some point and then think "maybe I should've just used X from the start".
Maybe it doesn't have to be that way, but I did see this a lot.
"users don't want to kill themselves during interaction" - touché :)
I agree with you, but taking the create-react-app example again - I can very quickly scaffold a react app with necessary toolsets, built on top of webpack. This gets me up and running without having to mess with webpack config.
At some point, I need to break out of these opinionated guardrails and do my own thing. At that point create react app has an 'Eject' feature which opens up the black box and dumps all webpack configuration and scripts for me to hack away on. The Anvil tool seems to have something similar where you can grab all the sources, download, run, and publish it yourself.
As a rule, I'm not a fan of the "Eject button" pattern. It's an admission of defeat. It says, "because you needed one advanced feature, I am now dumping you into the Wild West I was previously protecting you from. Good luck!"
A much more interesting approach is to acknowledge that your system will always be incomplete, and provide ways of using more complex external features without abandoning simplicity for the other 90% of your project. We call this pattern an "escape hatch", rather than an "ejector seat", because you don't need to jump all the way out at once.
Anvil has escape hatches all over the place:
* If you need to use code (or hardware) outside our server environment, you can use our Uplink library to connect arbitrary code anywhere in the world to your app - but you still get our drag'n'drop front end and seamless RPC. (You can even use our built-in database from uplink code.)
* If you need a browser feature we don't support yet, you can call to/from Javascript with our FFI - but you can still wrap it up in a Python form and use that from our visual designer.
* If you need to use a front end that isn't built with the Anvil UI toolkit, you can expose Anvil server functions as REST endpoints and use them from your {iOS|Android|vue.js} app. But you can still use those same server functions from Anvil client code, with full autocomplete.
* If you need direct textual access to your source code, or to do advanced version control operations, or to do CI/CD, you can clone your app as a Git repository. But the moment you push those branches back up into Anvil, you can edit your app with all our tools. (The editor will happily represent Git histories that it cannot [yet] create itself.)
Give me an escape hatch over an ejector seat any day.
Very cool. I had no idea about some of these features. 'Escape hatch' is a much better way to think about this instead of 'eject'. Re. create-react-app: I definitely prefer it when other libraries (like cosmos or storybook) integrate directly with CRA without forcing me to eject.
It sounds like these features go a long way toward addressing the concerns people had re. my parent comment. You can provide custom frontend or backend code with sacrificing too much of the power of Anvil.
Hi, cool project, really. As a backend developer I often feel stranded when going about web app frontends. And it's so hard to find WYSIWYG editors that don't suck. What about supporting Java for the coding, though? Is this going to happen at some point?
I am the developer of Solvent IDE, which attempts to tackle this problem in a comprehensive way, ie from the ground up as a platform: http://codesolvent.com/web-dev/
It is not as easy a problem as it seems...beyond the technical hurdle, a major obstacle is developers :)
While you like this paradigm, I am afraid a lot of developers generally scuff at these types of products.
... making it onto the front page of HN isn't some mysterious process, it's as a result of people who are viewing https://news.ycombinator.com/newest when you posted an article voting it up. Due to the fast churn rate on the 'New' page (and to the lower traffic on the New page) it often a matter of luck if a post reaches the front page, but what it isn't is some kind of conspiracy to exclude new entrants.
That aside, your tech looks interesting. What licence(s) is it released under?
I agree it's a tough problem - especially because you want a combination of 'get up and running quickly' with flexibility. At some point you might want to eject out of the entire system and start coding on your own without wysiwyg, etc. That's why I used the Microsoft and CRA examples because I think they (eventually) got it right... CRA especially shows how one single company doesn't have to create the whole ecosystem. There are so many OSS tools that support CRA and build on it.
First, we do really. But also, can you look at the website... You should spend some time explaining better why would I bother learning your product. It is a shame if has nice features, not to put them out, as I couldn't figure out at quick glance.
Can I ask, if I understand correctly, your reason for saying this dev stack is depressing is that it is yet another all-new stack. The problem here is the cost-benefit test of re-learning frameworks would fail in comparison to building on additional frameworks?
But I guess my question is, is it really depressing, because how would the indutry otherwise motivate giants like MS to innovate without such competition?
So I've been working on a python flask web app in part time/spare time for my business for almost two years (in addition to running a company doing several million USD in sales over that time without the app.) In that two years, I've tracked my programming time with wakatime and I'm at >1000hrs now, more than 25 full-time 40hr work weeks of actual coding time. I'm running the app on a dedicated GPU server, as part of the apps function is to evaluate 3D CAD files. Time spent managing and running a dedicated server is not even counted in the 1000hrs. Of course, I've also had to learn to be a Postgres database admin and dozens of support libraries. And, certainly must have at least some javascript/jquery. Libraries like flask-admin and flask-security are great. But, when you need them customized for production, it takes weeks of time to dig in and actually learn how they are built from the inside out. Need to subclass and override much of it to finally have something usable. I literally just spent about a month hacking on flask-security to get the login/email-confirmations/email templates/argon2-hashing/2-factor-auth the way I need it. Then, I watch this video the guy replicates most of the functionality in six minutes. Nice work, definitely looks like heading in right direction.
I would bet that you would need about the same amount of time nomatter what technology you used. The catch is this sentence:
> I literally just spent about a month hacking on flask-security to get the login/email-confirmations/email templates/argon2-hashing/2-factor-auth the way I need it.
I don't know Anvil but I am sure it has a specific way of dealing with login/signup/... - just like every other framework. And if you want to modify it, well, that takes time. And I am guessing it was the same with other tasks.
There is nothing wrong with that, of course. Just saying. :)
Anvil's built in "Users" service is incredibly simple and un-magical (user records are just database rows, and you can reimplement vanilla password login in four lines). This makes hacking on it an awful lot easier than some magically injected extension that needs to be configured just so.
My personal experience with Flask has led me to believe it's many times easier to expand on vanilla Flask then it is to try and incorporate any of the flask-* libraries.
Flask never really seemed like a very mature framework to me, it got so many strange inconsistencies and very dubious design choices I much prefer newer, significantly simpler frameworks.
One example is the way the request context works in flask, I venture to say thats just terrible software design in my book (from flask import request, g). And seriously to have your framework give you a "global" variable to put random stuff in, wth?
Also I rather not use Flask-SQLAlchemy since why should my database models be tied so incredibly closely to some library of my web MICRO framework, it doesn't make sense, I mean its not django why introduce this coupling?
It seems if you need all the dependent libraries (like webassets and wtforms) just use django from the get go instead of going through the pain of trying to cleanly integrate dozens of flask libraries.
To see how a proper simple middleware-based framework should look like consider express, koa (nodejs), or bottle, falcon. Aiohttp and tornado also have their place of course.
Having just built a boilerplate that integrates a bunch of the flask-* libraries, I think the key really is that you need to be careful about how you organize your code: it's important to be able to control the order of registering the various extensions you're using relative to when you're registering your app code. Otherwise you're going to end up in circular-dependency import hell. Buried in the documentation is a hint on how to do this correctly with application factories[0], but if you don't know that's there, it's very hard to just stumble upon how to correctly organize everything.
My personal experience with http is that you parse url and cookies by hand and never bother to use any crap “framework”. Of course, it has to be reverse-proxied with all irrelevant headers cleared, e.g. via nginx, which can also serve /static efficiently and provide https-http conversion. If you’re familiar with Lua, then writing http to json-only or binary-only unix socket is a no brainer in OpenResty, so you can skip backend-side parsing at all.
Flask/etc was useful magic only until I figured out what it really does between me and underlying socket.
I ended up with writing my own flask extension that integrates some useful flask-* libraries and client-side JS libraries in very opinionated way. Somewhat ironically I'm currently in process of spliting that into separate flask extensions...
I went from learning Python with Bottle, moved to Flask, found I was reinventing the wheel with just about everything, wasted vast amounts of time trying to integrate basic functionality from third party Flask libraries for things like auth and cookies, moved on to Falcon for building APIs, and finally arrived at AWS Lambda with Python and Cognito. Its now six years into the journey of turning myself into a complete full stack developer with database, back end and front end skills.
With AWS Lambda, Python, AWS Cognito, Postgres and ReactJS I can build large scale complete applications.
I think I'm vastly more productive today than I was then. That's partly a function of being a much better programmer in general, partly about now having developed expertise with my chosen technology set.
There's no way I'd go back to something as bare bones as Bottle or Flask any more. If I had to use a Python framework I'd look at a batteries included system like Django. As I say however, I've settled on Lambda, Cognito, Python, Postgres and ReactJS. I've done the hard yards... years of learning and many thousands of lines of code written.
>> Need to subclass and override much of it to finally have something usable.
This is really not something you should be spending your minimal available programming time doing.
After having done it a few times I personally don't find Flask auth very time consuming to implement.
But I'll admit I really like Flask. I find it just the right approach between something simple and something that can be much more complex with extensions. I don't like all of the extension (WTF Forms for instance can do without and SQL Alchemy usually is better independent of Flask IMOP) but these don't need to be used. I've stuck with Flask as much as possible over the years and that alone has led to a huge productivity increase for me because of familiarity.
awesome stuff, I never tracked my time but would have done similar hours over 2 years on iOS/Android/Python-Flask & Flask-Security.
Doing a rebuild now I have scaled and have a team and am using Auth0, and thankfully I am grateful for the abstraction!
In the 90s we had RAD tools like Delphi or Visual Basic which allow you to create simple apps very quickly. I feel that we are missing RAD on the web these days. There are so many different moving pieces. To do a full modern web app you need to learn different languages and frameworks plus other technologies for hosting such as containers or AWS, etc. That might work for complex apps, but sometimes you just want to do something simple that you can easily design visually, use one language and hit one button to publish. I have the feeling that Anvil is moving in this direction.
Were you at PyCon UK this weekend? Cause you just repeated our pitch, just about word for word :)
I started out on QBASIC and Visual Basic, back in the day, and as far as I'm concerned it's practically dereliction of duty that there wasn't something similar available for the web. Eventually, we got fed up enough to go and build it ourselves.
I learned to program with Turbo Pascal and then moved to Delphi. While watching your introduction demo my thoughts were "this is like Delphi for the web". I've also missed something like this for a long time.
It is really cool to see someone reviving the RAD concept, especially within the Python ecosystem. I was pretty big into Delphi back in the day--even worked for Borland testing it for a bit. I'm looking forward to trying this out.
Visual Basic where you replace basic with Python is compelling enough. On the web with a visual design editor ? That’s worth more than 50 bucks enough so that you can crank out a prototype.
No one is forcing you to cargo-cult the backend architectures of huge companies. There is no shame in using mod_passenger, mod_wsgi, Elastic Beanstalk, Heroku, etc.
Containers and container schedulers should be employed when it’s harder to not use them, at which point you can afford full-time SREs.
Went nostalgic. I remember SilverStream. I had made a proposal for a movie theatre booking project around 2000 and had proposed using this. Though the client didn't care, I was very much in to the java hype raging then. (this is India)
Ah the CMS wars of the 2000s. In a David/Goliath kind of thing, we managed to beat them many times when they were one of the offerings. I don't remember why we won usually but probably because we were local and price.
I'm really not a fan of Python client side. Or RAD. Or closed source services.
And I'm hugely impressed by the potential of your product.
Good luck.
I never though I would say that one day. But don't listen to people asking you to open sourcing it now. You can always do it once you are profitable. But right now, you need money to get this going. And if your product does what you say it does, people will be happy to pay.
Although not to be locked up on the long run. You will need to address that one day. One day.
I just had a video demo tutorial with your colleague @daviesian. He is such an intelligent and effective communicator. I learned a lot about your platform in a short 30-minute screen sharing.
In the crowded world of PaaS, human factors might have equal (if not more) importance than the technology magic. From my experience with Ian, I do see the bright future of your platform. You have a great team that people will trust.
Wow this is pretty impressive! Python everywhere is a big advantage and the way the frontend, backend and database are integrated appears quite seamless.
My question is about scaling - what are some large apps on this platform and how big do you think these apps can get in terms of db size and qps?
Our infrastructure is all on AWS and designed to scale horizontally, so we're pretty confident we can handle whatever traffic you throw at your app. (Ask about our dedicated-resource hosting plans!)
As for examples, it's a bit Catch-22. Our smaller customers, you haven't heard of; and our largest ones, we can't talk about in public. And a lot of it is internal/intranet stuff anyway.
We use the Skulpt Python-to-Javascript compiler (I'm a maintainer): http://skulpt.org
You might be interested in my talk from PyCon US this summer, where I talked about the compiler, and how we turn blocking Python code into non-blocking Javascript code:
Awesome stuff. Are there any debugging capabilities? Being able to inspect variables and step through code is massively valuable, particularly for education, but also for devs.
Honestly, we would absolutely love to open-source it! The issue is that we're a bootstrapped start-up, and it's rather difficult to make open source pay the bills, even if it becomes huge (see, eg, Docker's troubles). By charging for the product, we can claim some of the value we create, and be sustainable so the platform stays around.
For a counter-example, see RedHat :) I can certainly understand your position, but it isn't impossible to make money from Open Source. One approach to get some funding might be a KickStarter or Patreon type offering. (Or a combination of both). You also have your hosting service. Just some ideas, there are lots of open source business models- good luck whatever you decide.
RedHat was bought and incorporated by a pre-existing business. It wasn't bootstrapped.
I'd also discourage a patreon- or kickstarter-style offering for a B2B product, because it signals very clearly that you're not playing with the big fish.
Not a bootstrapped business, you mean, like Docker (Explicitly used as an example, to which I was providing a counter-example)?
As for signaling, one would not have to use those providers if they felt it did not fit their brand, and could roll their own platform. But if signaling that you want to "play with the big fish" is what one wants, most companies hire sales team who go out and play golf with prospects. Having an open source product and using other forms of funding certainly does not preclude doing that. (Though being a small bootstrapped business might make it more difficult).
I can't see my company (a small business with a number of small apps, with engineering and marketing people who it'd be great if they could just use something like this to build some things themselves) ever using something like this that is both closed source and somewhat prone to lock in by the nature of how it works.
While charging for use might seem like a good business model, I think an awful lot of potential customers will just never use it because of it. You may be able to find a model where you charge for the front-end page designer or something, but open source everything needed to run the site so that being locked in to a product you have to pay for and can't modify is less of a concern.
Perhaps a clear migration path from Anvil-infused Python to vanilla Python / JavaScript would be a reasonable approach. If for one reason or another I have to move my apps elsewhere I'd would like an easy way to do so rather than being permanently locked into a specific vendor.
At my entreprise, they are paying per seat to use gnat compiler. Even if it is open source and free to use for non commercial use, you can sell it and expect that your potential clients will generally not cheat.
Are you worried about would-be customers self hosting? Because I doubt there’s that much overlap between would-be monthly customers and those who are eager to self host.
This is a really hard question to answer. We've got everyone from scrappy one-person startups building products on Anvil, to larger startups pumping terrifying quantities of money through Anvil apps, to Seriously Large Companies We Can't Name building internal tools with our on-premises version.
Right now we're taking it all as it comes, but we never want to lose our focus on accessibility: It's way too hard to build web apps with today's traditional tools, and we want to make it easier for everyone.
I will only leave it and never pay if something terrible happens: the price is jacked up, service suffers or I create such a great thing that I need commodity pricing.
But its worse than that: if I don't have the security that I can leave, I won't dedicate time to use this.
I am happy to pay for the convenience and to try to create MVPs or proofs of service etc.
Anyway, it hardly matters what I think. Imagine what all the students and start ups think when they see it.
Customers aren't that black and white. I used to work for a SaaS company, and having the option of requesting the source and copy of the database was crucial to land quite a few of our contracts.
That said, I agree with you that it's probably not their best approach right now. Even if it pains me to say so :)
I don't think being locked down to a service is that important in this case. I see Anvil as a potentially valuable tool to create prototypes, to quickly iterate on an idea... then when it is validated, you can build it with more conventional (and safer in terms of future) tools.
Yes, its funny but I think of python itself as an exceptional good "prototyping" language. Thats not to say it can't be used in production, but I think the real power of python comes from its ability to go from 0-100 in a very short amount of time (powered by all the great python libs).
So in a sense, Anvil is valuable at its price point for just as a web prototyping service. Most new developers obsess on things like "scalability" and "MVC separation", etc and in 95% of cases their creations never ever generate enough traffic to warrant any of that. I see Anvil as a tool that would allow developers to sketch out an idea, quickly iterate features based on feedback, and when warranted, move to a full production stack.
Yes, that's true. But that does describe Rails. A pure Python web framework, integrated, with a python to javascript transpiler is very likely to emerge, but I can say with almost total certainty that it will have to be open source.
I don't know any actual numbers, but I think DHH and basecamp almost certainly profited from the popularity of Rails. That's probably up for grabs, since integrated web environments in non-js languages may become a big deal over the next decade.
DHH and basecamp made money because they are explicitly not open source and you have to pay for it.
The fact they are built with RoR is an implementation details. 37signals was very good at communication, Ror or not. Their blog and books were fantastic.
ROR as a FOSS may have helped, but I doubt it was instrumental.
yes, exactly, they found a way to monetize a product other than their framework, and they used the OSS framework to draw attention to the non os project. Whether that was deliberate or unintentional, I don't know, but it certainly worked out.
EDIT: I agree with you that the product is good, and that the communication was excellent, but I disagree that the success of ROR was minor to the success of that company. It brought a tremendous amount of attention.
This is not an unreasonable ask though. You should certainly think twice to pigeon holing yourself with any technology that you do not have full rights to and will be lost without a specific provider.
It does make figuring out your business model more complicated, but having SOME story for what will happen if you go out of business or start being a bad actor is something you need to figure out.
It isn't impossible though, our SAAS is Open Source and we survive, though yes, some customers do choose to self host. You just end up with fewer enterprise customers and more smaller clients.
I understand the request, because I would not use the service myself for the same reasons.
But let's be real, if it became open source, I would just host it and never pay for it. They would have to do more work for less money. Hardly fair.
They can always start with a strong commercial offer, then later address the user locking issue. For them, I think it's a way better strategy. FOSS first is very hard to monetize. The Libre community is a terrible customer.
If I make software that enables you to create things, then the software is mine and I can charge you for using it, but what you make using my software is yours and you can do whatever you want with it.
I played with Anvil for the first time at PyConUK last weekend, and I was really impressed.
Specifically on the point of accessing your code:
- if you Architect your code well enough you can keep reasonable separation between generic Python code and code that is tightly-coupled to Anvil (I.e. keep it modular)
- and Anvil does actually provide a means for you to directly clone your Anvil app code locally from their servers using Git. This would give you a copy of all your code including front end templates etc.
I think tie-in is always a consideration but we are increasingly getting into that situation with things like AWS, and so we really must balance the pros and cons. I’d rather by tied in and profitable if I’m trying to get something off the ground...
From the website, it looks like you can clone the git repo locally, so you would have the code. Now what I want to know through is if that repo contains all the "magic" code that anvil does. You have to upgrade to PRO in order to clone a git repo unfortunately.
I stopped at the pricing model. The jump from $0 to $49 per developer precludes my typical "dip my toe in the water" approach with new platforms.
I'd ideally want to try it out in production with a real, small commercial job. But if I do and decide not to expand my use of the platform, then I'm committed to a $600/year hosting deal for a small client...
And I won't use it on a bigger client at first due to the risk of lock-in.
In fact - lock-in is the biggest problem with using this. It's a paradox. I'll only willingly get locked in to platforms that I'm 100% happy with and I am only 100% happy when I've been using a platform for a reasonable length of time.
Otherwise I risk having to rewrite a 5 year old website for a client out of my own pocket when you decide to pivot or you run out of cash/luck.
Looks very impressive. Any plans of offering this a-la-gitlab: paid hosting + support OR free downloadble source but then you're on your own? Main concern is that for something to really become ubiquitous the community should be able to contribute and not just be in the hands of two developers (no offense, I think you did a fantastic job!)
I share this concern. I made a resolution not to tie myself to proprietary services for anything that I couldn't replace/move within a few days. I can move containers, databases and even serverless functions.
Starting from scratch seems to be the only option here, so I would hesitate to even start a small prototype. Which is a shame because I really like your model.
Also, and exactly because I find it very interesting and well done, I'm curious about what happens if the company goes down, or pivots, or gets acquired.
Whenever i see these cloud apps that seem like a good idea, I just think of spiralling costs similar to the likes of firebase written about on HN before.
Their pricing page doesn't show anything about usage limits and if it is "per site" or "per domain" or "per project".
Pricing is per-developer-seat; we don't limit the number of apps you can build or publish.
Usage limits are pretty soft right now (depends heavily on what you do in your code and how hard you're hammering our servers), but the general intention is to charge you more as you scale up your team, rather than because you got a few thousand users.
It is this lack of clarity (published limits) that scares many of us. It basically says that we won't know when we'll be cut off or shut down, but we'll find out when it happens!
So if we build something that becomes wildly successful, we could suddenly be in a world of hurt if our site is deemed too heavy and we're throttled or worse. It would be like Pokemon Go - big explosion, lots of tiny pieces, customers gone.
I urge you to have some kind of professional plan with guaranteed tiers. Otherwise, only naive people or people who really don't care about the future will use it (outside of the prototyping case everyone else is mentioning).
On the other hand, it would be the perfect tool for someone on upwork or the like to do a gig ultra fast, leaving the client to deal with all the future pains. But since most projects end up not huge and successful, that might be just fine!
So as long as I build the next Twitch on my own you guys will just charge me $50 per month? That’s freaking awesome! It’ll save me $5300 per month in hosting already!
Does Anvil render server-side or is it client-side only?
My issue is if being used for websites, on average our sites get ~50k visitors a month or even spikes with that amount.
The same goes for complexity of the system, for simple html sites it will not matter much but for very dynamic apps this will require a lot of CPU time.
Reading the docs, it says the Forms run on the client, so most rendering should run too. Client-side rendering - while it has its disadvantages - shouldn't be worse for the CPU time than server-side, though. What's your concern?
I can see this as an amazing teaching aid too. You can take away all the learning about tech stacks and platforms and various languages and server config etc. for a while and concentrate on developing the idea and developing a process.
Edit: My son is going to love this when he gets home!
It seems good enough that you could push the prototype live as an MVP.
I am interested if you grow to something to the stage where you want to move off this and onto something more customised, do you have access to be able to properly migrate the DB somewhere else?
As to your second point - yes, that's a common pattern. We see people going "oh, let me just sketch out the UI...well, I'll add a bit of code...oh, look, it's in production and scaling!"
We do have a lot of support for integrating with external systems, so it's easy to gradually move off from (or on to) Anvil. External access to the database is just the start of it :)
Using this as a teaching platform was my first reaction too.
I don't think I would use it for anything production though without an option to export the app (database & source for my app). I would pay the listed monthly subscription fees in a heartbeat. That is a no brainer for the time this appears to save but I have learned the hard way too many times in the past on being locked into a platform for business crucial stuff.
I would be fine even paying a one-time fee of few hundred dollars to be able to export my app if I need to. Simply for the peace of mind of not being locked in if something happens.
Like many I'd be afraid for to much tie-in with this system. If I could export my code is a way that it's usable and based on open source libs, I have the liberty to extend it beyond what Anvil's limitations.
But now I'd probably still take the upfront cost to get a bigger app started without tie-ing in with a service. For rapid prototyping it seems awesome!
This looks really nice, reminds me of what you could do with Visual Basic for creating GUIs, and I really liked that experience (though I did very little of it).
One thing I really don't like about it is how the free pricing level doesn't have authentication. Seems like I can't really build a toy project that I then "graduate" to a real app. Or maybe the plan is that you build it as a private app as a toy and then start paying $45/mo when you want to make it public and have auth?
I feel like if the free level was limited by something else, like database size or something?
I can understand why they want to drive people to revenue-generation. Just seems like a feature that hurts more than it helps, by keeping people from even trying it?
I love this idea. It reminds me a lot of old school .NET worked within Visual Studio, or the Delphi editor for Windows application forms.
.NET has evolved into a totally different beast so I don't use it any more. This framework brings back the simplicity that I feel has been lost from drag and drop tools.
Drag and drop tools exist for the web, but there's nothing that introduces and organises the use of simple programming languages within the mix - at least that I know of - so this is definitely going into my list of cool tools.
Awesome! I work at Mendix where we've been building something similar for just over 11 years now. Companies in this space (rapid app development for the web) typically target the Enterprise market and are typically not open source, I think that's why they don't get much interest on HN.
The market is heating up though, we are growing fast and our competitors do as well. Moreover, Google (AppMaker) and Microsoft (PowerApps) have entered the race in the last two years.
I remember someone saying on HN that what the world needed was a way to make web apps that was as easy as making a Windows form in Visual Studio. Could this be that app?
This looks amazing (speaking as an old Delphi programmer).
My three questions:
- I have a client whose app sits idle but then gets hit by maybe 300 concurrent users, all reading and writing within a few seconds of each other - do you have anything in place to deal with that kind of spike in usage?
- It looks like it's designed to be always online - any plans to make it offline-and-sync capable?
- Any documentation or hints on automated testing?
I'm actually hoping that this will allow me to avoid a very grave situation, which is that we have some workflows which we were going to be pushed into handling with Sharepoint! I'll take Python any day!
I only watched the video, so it is a bit early to judge, but I wonder:
1. Why put that much effort in explaining it takes only 6 minutes in setting up a web app? Anyone who has done any serious web app knows how quickly you can set up a simple app really does not matter much for an app even of moderate size, let alone big ones?
2. Why yet another attempt to abstract away everything and using one language (python) only? What happens when you need to debug nitti-gritty js/css/html/sql?
These tools are for simple CRUD apps for people who aren't necessarily strong developers to begin with but need to put together something anyway. That's why the demos focus on speed and only ever show the tiniest of applications.
I'd dispute that! There are much larger applications built on Anvil; it's just hard to build a two-week project for a demo video, and harder still to build a two-month one ;)
We're starting to post some larger examples (check out our "download portal" example at https://anvil.works/learn#examples - I'm also working on a video series building a SaaS app over the course of a few hours). But the biggest apps are, of course, our customers', and we can't really publish them as examples.
Fair enough. I may have been a bit harsh (though not really on purpose). I'll look through some of the larger examples. I just tend to think that if one's team has the chops to write something large and more complicated than a CRUD app, they aren't going to want to start here. That's not to say there's not a role for these types of tools...
Their control panel drives companies' entire online marketing operation - creative, targeting, performance, and more - across multiple advertising services. That's a whole lotta UI. Their back end drives the advertising platforms' APIs (eg Google and Facebook), and it all hooks into great big machine learning operations that run on big beefy servers out in EC2. Not just a pretty CRUD app, that's for sure.
(Unfortunately, they know what their services are worth, so I can't just point you at a live demo ;) )
So, the UI/front0end of their app was created with and runs on Anvil, but the backend is entirely under their control? That's interesting. Very interesting.
Their backend is partially inside, partially outside Anvil (eg I believe the campaign management backend runs in our hosted server modules, but the compute-intensive machine learning is offloaded). And it's all under their control - it's their code!
The wonderful thing about the Uplink is that the boundary between "inside Anvil" and "outside Anvil" can be very fuzzy, because you use the same APIs. (See my "escape hatch" post above)
Absolutely - please ask about our Enterprise plans ;)
That said, even with the standard plans you can plug into your own Postgres database from server code (just `import psycopg` - it's only Python, after all). And using the Uplink, you can access Anvil's database from your code anywhere on the internet, with the same API as Anvil server code.
What you should really do is also sell anvil in a form that makes it possible to host on premise or in AWS or somewhere else. Even if you charge a 1000$for that people would pay up. You don’t need to open source everything but you can sell the compiled c files instead with installations and support guidelines. I would love to use it but if I cannot control the infrastructure I feel my hands are tied.
Installing and running it is typically a single 'docker-compose' command. If you're interested in this option, please do drop us an email at sales@anvil.works.
Also things like bulk uploads to a table for migration, would I have to write a service for this? I have an app I would like to migrate that has a sqlite table with static data in it, that I could see using this. I suppose I could use the server connector, but what other tools does this have?
It's a library you `pip install`, which lets you connect Python code running anywhere in the world to your Anvil app. Everything you can do from Anvil server code, you can do from your Python code, wherever it's running. You can define server functions, HTTP endpoints, access data tables, etc.
We have customers controlling IoT devices with it (like that Raspberry Pi video). We also have companies driving big machine learning jobs on EC2 servers with tons of GPUs - but with all the UI and housekeeping in Anvil.
I fail to see the equivalence. I'm not contracting with Anvil for development or support. I'm basically buying a tool, in this case a tool that is more expensive than my hosting costs.
One, if you're using it commercially, it's going to pay for itself pretty quickly. I rarely do client projects for less than several thousand pounds; I reckon I could probably churn a lot of them out using this in half the time.
Two if you're not using it commercially, it's still a very low cost; maybe more than pure hosting but it does a lot more than just hosting.
Honest question, this looks awesome but how would a contractor justify using it? Would you somehow swallow the risk of them going out of business for whatever reason and promise a rewrite for clients (is that something you can get insured for?) or would clients just be okay with the risk? It seems like you'd have to have already bought enterprise to be able to run this without them from what I can tell?
Looks promising but my biggest gripe is the visuals. Maybe in the future, you could support different themes or skins? It's great to be able to bootstrap a website quickly, but if this is going to be customer facing the design needs some love :)
+1. I know that enterprise might be your main focus and internal web apps don't need a lot of styling love, but just the ability to add Bootstrap or Semantic UI components would make this beautiful. Of course, hiring a designer to work on the Anvil website itself as well as the default styling couldn't hurt.
We already do! Paid users can choose "Assets" in the app browser and edit the HTML/CSS/etc. (You can also check the app out with Git and edit them there.)
We'll also be adding more built-in themes before long :)
Oh yes. I know some people who work with them, and they charge quite a bit of money. They're exactly like Oracle, they'll charge you for every single feature and these are not small amounts. Not to mention the pain you have to deal with once you want to do anything more complicated than their platform provides. I am not aware of anything stories in particular but I can imagine that migrating away from them is not an easy task.
On the other hand, I gotta give it to them that it does some things well. I definitely see it solving problems in industries that need custom software but simply don't have the resources or capital to get a completely custom, from-scratch system.
For when you need to keep sensitive data or apps inside your firewall. Anvil on-site installations allow you to develop and deploy your apps entirely in-house.
I was thinking more in terms of ameliorating the risk of building a successful small business on this and them going out of business after gorging themselves on VC money and having a heart attack.
You could probably rewrite your thing in Django or similar in the event of that. Given that the majority of web apps don't turn into successful small business it might be a good way to try stuff.
My use case is closer to being a small dev shop doing webapps for other people. If they go out of business, I would have tons of Django/whatever work all of a sudden, but lots of pissed off customers when I don't have time to rewrite them all. Plus I (morally) would need to warn them about this risk when pitching/selling them, which would probably put a sizeable dent in sales: "Also, there's a chance that this completely separate company stops supporting their product and we have to charge you for a complete rewrite of your app".
Also, a great job with the demo video explaining what it is.
The only feedback I could give for now is that the "Free" plan should include some extra feature from the paid plans (e.g. User Authentication, Custom Domains, etc.) as it seems way to basic and the first paid plan is quite expensive.
I may sound like a cheapskate but you'll pull in the right crowd if you tax other metrics like traffic/bandwidth/cpu/ram/etc.
Hey, so there is another solution that is pretty popular out there that I'm sure you already know of: https://bubble.is/, and it doesn't seem to require any coding.
Can you explain what are the differences between Anvil and Bubble? I am currently using Bubble right now to make web apps. What makes Anvil better?
Glad to hear it! Some details about the tech stack:
* Front-end code is compiled from Python to JS with Skulpt (http://skulpt.org)
* The back-end code runs in a custom Python sandbox. Calls to server functions go over a secure web socket (this lets us do fun things like returning database rows directly from server functions, rather than faffing with REST APIs all day)
* The built-in database (Data Tables) is based on Postgres, using its JSONB and GIN indexing to create a table you can search efficiently on any column. This also means that things like transactions are properly robust.
Interesting. I've been looking for alternatives to React or Angular for some time. I've enjoyed playing with Elm recently. My preferred back end is Python Tornado RethinkDB, so browser GUIs in Python is appealing. I looked at https://github.com/skulpt and it looks like the compile to JS step happens on the client side, unlike Elm. What's performance like?
As far as I can tell, the footprint is around 1MB for the combined skulpt-min.js and sculpt-stdlib.js (not sure why the latter apparently isn't minified). That's pretty huge and makes for a large barrier against using Anvil for a public-facing app. Moving the compilation to the back-end would eliminate the footprint problem -- or would you still have the stdlib running in the client? Any further comments on footprint issues? As it is, we're talking about about two orders of magnitude bigger footprint than some javascript options.
From the Skulpt website: "Skulpt is an entirely in-browser implementation of Python."
It sounds like you implemented python in JS, so there is no compilation to JS. The application code is always python and is evaluated on the client, no?
If you move it to the back end, would that not be something like Trascrypt?
Skulpt has a separate compiler stage that compiles Python to JS, and a runtime library. There's no need to eval() that code in the same JS VM that compiled it, so it's totally feasible to ship the JS to the client and run it there.
the editor is really nice, it's ability to sense what I am about to type is borderline magic. It'd be cool if that were open sourced, but I understand if few to none of this is going to be since they're trying to bootstrap a business.
Thank you! When the PyCon UK lightning talks go up on YouTube, you'll be able to see my talk from last night about how we built that autocompleter.
Bottom line: Traditional web dev has starved us of decent tool support. Give us even a really basic autocompleter (especially one that knows about what's happening in the server and database) and it feels like borderline magic :)
I searched the documentation URL with Google for the word "tenant" and it returned no results. Does this mean that Anvil does not support multitenancy, for SaaS sites?
Multi-tenant/single-DB is a pretty common and straightforward pattern with a lot of support in Anvil (eg restricted views, as described in the video).
I'm also currently working on a multi-part video series, showing the creation of a SaaS product, from scratch to monetisation. Sign up for our mailing list, and watch this space :D
That's exactly what you can do! If you open up a Server Module, you'll see a drop-down in the top-right. That will allow you to select a Python 3.6 runtime.
The client-side code is Python 2 only for now, but we're already upgrading our Python-to-Javascript compiler to include Python 3 syntax.
Are you looking at Transcrypt https://www.transcrypt.org/ as a replacement for Skulpt at all? Because its here and it already works great for Python 3.6, it just needs more usage to develop workflows and examples around it and tools like Anvil are a great way to get started with any technology.
He just copied and pasted his code from the notebook into an Anvil server function, and it ran first time! It's all just Python, at the end of the day.
Am I the only one who things this is a really really bad idea?
The world does not need more interpreted languages on the backend.
Visual UI layout is cool for beginners but almost useless for serious projects. Plus if you're a beginner (or a non-programmer) maybe an existing CMS is better? e.g. WordPress.
If a project started with this tool was to ever evolve and get big, I can't imagine that maintaining it will be anything but a nightmare.
I am sure you are not the only one who thinks it is a bad idea. But I disagree with you. I think the future of programming (or I should say, one branch of it) is making programming easier, and letting the computer do more work. I definitely think working in this direction is a good idea.
Regarding CMS, I view those as high level languages. And in that regard I think we can improve on them a lot.
> I think the future of programming (or I should say, one branch of it) is making programming easier, and letting the computer do more work.
I think this is already what is happening. Computers now are orders of magnitude faster than they were 15 years ago, and yet fundamentally nothing really got better. We just have more people producing lesser quality programs. While producing something is easier than before, the new things are not necessarily of good value, because a lot of the tools that enable this are layers upon layers of abstractions and virtualization (e.g. Electron).
I'm not sure that this is any good.
And fundamentally this is not that different from VB6, for example.
There was a time when typing a document in your computer meant you have to know an macro language (remember wordstar?) ... the current state of programming is such and a big barrier for non programmers. We need to make it easy just like MS word made it easy to type complex documents in the computer.
Writing documents is a use case for the general public.
Writing code is not the same. In general, programming tools _are_ getting better (text editors, debuggers, IDEs, etc).
The only barrier to non-programmers is learning how to program.
It's the same with writing. The tools _are_ available. But you still need to know how to write. I mean how to put words together in a way that people would want to read.
personally, I'm going to stick to flask and django.
this is nice and all... but you still have to learn python to get it going. My preference is to learn Python/Flask via books, tutorials, and as part of a big community (websites/forums, IRC, etc).
But... I really don't see the benefit of this, even after watching some videos.
the drag and drop stuff? that's just html and css (child's play)
python? that's still python.
I'd much rather just open a blank Ubuntu 16.04 server on DigitalOcean and pull my repository from github. I.e. work like a real developer :)
I wouldn't mess with Anvil, personally. I'd prefer to do code by hand, with a framework that has been around for a while.
I love Django and flask. I'm an expert at both. I train people at both.
But come on. 6 minutes with DB, responsive design, registration (including social auth or AD) and online deployment ? I can't top that. No even close. Even with boostrap and pythonanywhere. And I know the freaking API by heart while most people are just trying to figure out what's going on.
This stuff is amazing for somebody who just want to fiddle with a CRUD app. The ratio investment / return is crazy.
And the thing that a lot here are missing is the integration aspect. If you have team members who aren't coders, they can still participate with the drag-and-drop UI builder. Anvil is definitely on the right track here, I'm not a fan of drag-and-drop UI builders, but can definitely see how useful it would be for a product person on my team being able to jump in and make changes to the UI without needing to tap me on the shoulder. That being said, I'd prefer a code-based representation of the UI and didn't see anything like that -- would be interested in knowing if I can build UIs via code alone.
Wish Django had a mature integrated client-side UI toolkit like this, I'm amazed given how advanced django.contrib.admin is that the Django team hasn't already generalized much of the admin components. If anyone is aware of something like this already let me know, with React eating the world it looks like DRF + React is the only way to go these days..
For the last 15 years Microsoft has been putting out the same RAD tools, but based on ASP.NET/C#/Visual Studio. Things like drop-in provider-based OAuth, editing versioned database projects, WYSIWYG UI, etc. Publishing to the web, even the flow of clicking on a button to edit its handler looks like it was based directly on Winforms which is a 12 year old technology.
Why aren't there more of these things out there?
How much time now is spent learning the latest and greatest framework/toolkit/etc. only to spend more time configuring individual components and cobbling them together vs. just getting the product finished and published to users? I don't mean to be cynical but I wish there was some way all these different tools somehow built on each other instead of constantly resetting the dev stacks.
For example, Create React App - I'm constantly impressed by how it has eschewed configuration in favor of getting things done while still having a lot of flexibility. It draws on a lot of great, previous past projects and seems to define the train of thought for other react projects. It seems to me that people like Dan Abramov, Brent Jackson, and others are on the same wavelength which is incredibly powerful for the react community.
There should be a way for that sentiment to extend beyond React, into the database world, the IDE world so that we can collaborate and create more nice things like this.