Nah. There are billions of people on the internet, and it varies from a dusty library to Atlantic City (though for some reason we let kids into the casino?). It is not one thing any more, but there are plenty of fun corners.
I could type ~four lines and an alert box response from a visual form.
For years I have lamented the amount of paperwork necessary in most of modern programming to get things done. I don't know how important that is now that I have a machine fill out the paperwork. It would still be better if there was less fuss.
The amount of paperwork is controllable. It’s just that most programmers have a tendency to prefer more paperwork because they believe it is a better software architecture.
That said I also lament the death of WYSIWYG-style HTML authoring tools. This is I think the same affliction that caused programmers to prefer writing code to build UIs rather than drawing it interactively.
Interactive UI design tools are cool when you're not a programmer, an inexperienced programmer, or lack the imagination necessary to create new abstractions.
UI preview tools are incredibly useful, hot reloading when doing UI work is, again, incredibly useful.
What nobody needs in their life is to meticulously hand place elements and align them only for the auto-resizing logic to fuck things up.
You want good abstractions which let you easily and quickly define UI elements and to define new composable widgets. So that you can declare in your code details of how things should be aligned with respect to each other, and leave final layout to more code which, if you are lucky, you might not even need to write.
For an example, check out jetpack compose. It's not completely flawless, but it truly isn't bad.
Yeah this is the kind of programmer’s thinking that led to complexity that is present by default and sometimes not warranted.
> meticulously hand place elements and align them
You don’t need as much meticulousness as you imagine. Have you tried placing some text boxes in Keynote or PowerPoint and hand aligning them?
> for the auto-resizing logic to fuck things up.
Auto-resizing is often unnecessary during rapid prototyping. Even in prod, even if you are developing internal apps in an enterprise environment, it’s still not necessary. Make your window non-resizable if you are targeting native, and set a fixed viewport <meta> for web apps.
> define new composable widgets
The kind of people who are enjoying VB6 don’t need new widgets let alone composable widgets. Just use whatever widgets that are builtin.
Basically your entire comment is describing the kind of complexity that I said was not always necessary.
You don't need to be meticulous if you want your software to look like a 5 year old drew it, which maybe you don't care about.
But even so, hand placing 20 labels, editing them to say the right thing, then hand placing the entries, making sure the tab order is correct, you don't want to be doing that by hand. And it gets worse if you need to edit this in the future.
I am not saying this because I think it sounds stupid, I am saying this because I spent 4 years at an organization where this was the only method to do things and I _know_ for a fact that it is stupid and tedious. Given that we had the list of fields, if the language wasn't hot garbage, and the organization wasn't stuck in the past, we could have made it so 99% of fields on 99% of forms could have been placed automatically and cleanly saving literally months of development time in total.
We needed a complex UI for something which could not be done natively using this technology and I proved this to be true when I made a data driven UI in a fraction of the time it was taking to iterate on the legacy version which had 1/10 of the features.
exe.dev | full time member of technical staff | sf bay area only
competitive salary, meaningful early equity, 2 days a week in the downtown sf office
come build a cloud. we are doing everything from custom hardware to custom ssh servers to our own global load balancer. very senior small high-trust team looking for someone we can rely on to get done whatever is most important in the stack for the business. some days that means patch the vmm. other days it means figure out passkey quirks.
Our exe.dev web UI still runs on AWS. We also have a few users left on our VM hosts there, as when we launched in December we were considering building on AWS. Now almost all customer VMs are on other bare metal providers or machines we are racking ourselves. We built our own GLB with the help of another vendor's anycast network. You can see that if you try any of the exe.xyz names generated for user VMs.
We would move exe.dev too, but we have a few customers who are compliance sensitive going through it, so we need to get the compliance story right with our own hardware before we can. It is a little annoying being tied to AWS just for that, but very little of our traffic goes through them, so in practice it works.
I need to fix our transfer pricing. (In fact I'm going to go look at it now.) I set that number when we launched in December, and we were still considering building on top of AWS, so we put a conservative limit based on what wouldn't break the bank on AWS. Now that we are doing our own thing, we can be far more reasonable.
Almost every VC rejected us when we went to get seed funding for Tailscale, we knew none of them. Friends of friends of acquaintances got us meetings. Fundraising is very possible for you if you are committed to building a business. Most important thing is don't think of fundraising as the goal, it is just a tool for building a business. (And some businesses don't need VC funding to work. Some do.)
The biggest challenge is personal: do you want to build a business or do you want to work with cool tech? Sometimes those goals are aligned, but usually they are not. Threading the needle and doing both is difficult, and you always have to prioritize the business because you have to make payroll.
Surprising that a founding team as strong as Tailscale's had to go door-to-door to get seed funding in. Glad that Tailscale did & changed the industry like it ought to, though I'm sure, y'all would have managed to self-fund it either way.
Author here. Most of our infra is custom, the VMM is based on cloud-hypervisor (a project spiritually similar to Firecracker). We have a lot of work to do, including on the VMM, but right now there is more value for users if we spend our time on the VM management layer and GLB.
I really resonated with your piece. I really have found once the friction to writing code went down, the time was immediately replaced with “setting up cloud abstractions”.
I’ve been using things like onrender.com for hosting projects, and once the initial pain of setting up was complete, I found shared infra like logs/metrics somewhat useful. Do you imagine building these in exe.dev? Or does doing so move into “more confusing abstractions” territory?
very nice service, i'm using it to build out an agent orchestration system and so far it's quite good. anything to share in terms of future plans/improvements to the platform?
Based on this and recent product releases, Anthropic seems keen on building a closed ecosystem around their excellent model. That is their business choice, I suspect it will work well. But I cannot say I am particularly excited to have my entire development stack owned by one company.
As a non-American, I love what Chinese companies are doing. The progress they are showing and the fact they are sharing the weights of the models is great. I can't wait for the day when companies that "have no moat" like A. , Cursor or even OpenAI are left with a bunch of float matrices and hardware.
I understand people from the US will have an anti-Chinese reaction, but for us in the "third world" that can use both techs, the openess is always good.
reply