meredydd

This probably makes it less accessible for non-programmers than Bubble, but it does make it more powerful in the hands of someone who can code, and makes it useful for bigger/more complex projects.

(The same is true for you, Eilene - your email address is hidden. If you want people to be able to email you, click your username in the top right of the page, and add it to your "about" section.)

It's amazing, in retrospect, how important it felt to create a "real EXE". Nowadays, we write huge professional systems in scripting languages that need explicitly invoking with an interpreter - but back then, "grown up" programs were the ones that didn't need that.

(While I'm making a new comment, and since the last one is out of its edit window, I should acknowledge I mangled my attempt to summarise the place-of-supply rules. Sorry. Don't get your tax advice from HN comments, kids.)

(Example from a few years ago: http://gawker.com/5164035/tesla-ceo-in-digital-witch-hunt)

In short: If you're supplying digital services to consumers, you need to charge them Value-Added Tax (VAT) in the country they're in, not the country you're in. If you're supplying to businesses, you charge them VAT where you are. You need to collect certain evidence with each transaction, to prove which category/country your customer is in.

The search term you probably want is "VAT MOSS". This officially refers to the "Mini One-Stop Shop" provided by HMRC (the British tax authorities), which tries to ameliorate the situation. You still need to charge people the right amount of tax, but then you can just upload a quarterly spreadsheet saying how much revenue you got from each EU country. But "VAT MOSS" is also used as a catch-all term for the whole cross-border digital VAT kerfuffle.

It started out as a well-intentioned attempt to close a tax loophole, but it was clearly drafted by people with no understanding of how computers work. (There are actually "FAQs" about how, precisely, to handle a German citizen with a British SIM card making a mobile transaction from a train journey crossing the Italian-Swiss border...as if this were something a website could reasonably detect.) But, as I say, there are decent solutions you can use, and you just spend a couple of days implementing one of them.

Anvil isn't for distributable desktop apps (that's not where most of the action is these days, for better or worse). But we use it for one-offs (driving local code via the Uplink) all the time.

One similar project is https://anvil.works. It's got a pure Python front end rather than HTML/CSS/JS, with a drag-and-drop designer - kinda like a modern Delphi or VB. But the client-to-server function call interface is very similar (are you using websockets too? [edit: Yes you are!]).

It's targeted at traditional web apps, rather than desktop apps, but it has an "uplink" that lets you connect local code (eg here's me building a GUI that shows text on a Raspberry Pi: https://anvil.works/blog/uplink).

I originally wrote execveat() because I was experimenting with implementing FreeBSD's Capsicum[1] API on Linux, and I needed a "true" fexec(). (Previously, glibc fexecve(fd,...) was implemented as execve("/proc/self/fd/N",...), which isn't so helpful in a sandbox where you aren't allowed to navigate the full filesystem.) Turns out, the Chrome team really wanted this too, and David Drysdale took on the work of polishing it up and getting it into the tree, so big props to him.

[1] Capsicum is a sandbox based on per-file-descriptor permissions. Eg you could have a web server that can only append to files in its log directory, or read files from its Web root, but nothing else. Man pages: https://www.freebsd.org/cgi/man.cgi?capsicum(4)

It's mentioned in the article, but I personally think Capsicum's syscall interface should have made this list too. File descriptors as capabilities is just so elegant!

This is the direct equivalent of demanding the right to dump whatever I like into the river, because some other company in another country can.

More generally, this is an example of "all regulation bad" thinking. If it is inherently evil to impose any rules on companies operating under your jurisdiction (and that's what you're implying with phrases like "obey us or we crush you")... Well, now you're arguing that no government should try to solve any coordination problem. No auto efficiency standards, no pollution regulations, no product safety standards...not a world I want to live in.

(I'm going to ignore the Brexit stuff, as that's a long-standing flamewar that's already producing more heat than light in this thread.)

There are companies that will go out of business, or have to pivot heavily, as a result of GDPR. If this doesn't happen, it's is not doing its job.

More mainstream companies will grumble about this, just like they do about environmental regulations now. But, then as now, we've done the experiment. As an industry, we were left to self-regulate for 2.5 decades, and look what we did.

I am not looking forward to finishing our GDPR compliance. Anvil doesn't rely on personal data for its business model, so it's not a big deal, just a bit tedious - it's a textbook frictional loss from regulation. But I am looking forward to living in a world where everyone has to comply.

(Which reminds me, cycling down the runway at Tempelhof is still on my bucket list. I should go to Berlin this summer...)

1. Modern .NET for desktop apps, whose many semi-obsolete UI frameworks make Java's UI tools look simple

2. Learning HTML/JS/React/Redux/CSS/Bootstrap/Python/Django/SQL/SQLAlchemy/Webpack...

Neither is likely to appeal to someone used to how easily applications could be created in VB6 or Delphi.

(I believe this so strongly I cofounded https://anvil.works, which is basically VB6/Delphi for the web. That's not so much a disclaimer, I guess, as putting my money where my mouth is :-P)

Nowhere is "worse is better" more true than line-of-business software.

This emotional response probably transfers onto the languages themselves, which means any language in decline will naturally attract resentment.

The general principle of a programmable RAD with a nice IDE and a visual designer is still very popular. I'd wager Delphi would also appear on a list of "most-missed" languages, because using Delphi back then meant a pretty nice developer experience.

The runtime can be remarkably small (Skulpt is 228kb minified and gzipped, including the standard library), so I think it's a feasible target. (Pypy.js is, of course, enormous!)

Archive link: http://archive.is/leOnD

GitHub: https://github.com/skulpt/skulpt

Skulpt is "a Python implementation in JS". It doesn't have built-in DOM bindings - it's typically used within a project like Anvil or Trinket which provides higher-level (and therefore more Pythonic) modules for display/input/IO. Skulpt code can block, which also helps keep those APIs simple.

I guess my summary would be that Brython is great for scripting your HTML in Python rather than Javascript, but Skulpt is best for providing a Python runtime in your app. Does that make sense? (Of course, you'd have to ask a Brython developer for their take on it ;) )

Feel free to ask any questions about the gory internals and how it works. You might also enjoy my talk from PyCon US this summer, about how Skulpt compiles blocking Python code into non-blocking Javascript: https://anvil.works/blog/pycon-talk

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.

One customer has kindly allowed us to talk a bit about their app - see https://news.ycombinator.com/item?id=15589020

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)

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.

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 :)