Hacker News Reader

Hell yeah. I build internal web apps with Django. I'll definitely try this out in my upcoming project. Some major pain points are going past tables of data to (1) graphs (2) create/update modals (3) cron jobs. I've used and contributed to some plotting library I don't remember. For modals I usually use Vue+Primevue and for cron jobs I use celery+redis. Login is a pain, but it's mostly a solved problem on my end.

thanks for the feedback! i'm curious, how critical are graphs for your internal tools and what are some examples of their use?

Pretty darn critical! I built a service a few years ago to scrape natural gas volumes from different refineries and my client wanted that data plotted over time. Another project collected and displayed wellhead pressure data.

Oh yeah, maps are also super important, and being able to overlay different statistics and or graphics over them.

thank you for sharing! i think we'll get there eventually and add components beyond tables, such as charts and maps. current focus is to get the table+sidebar experience right first. the thing that differentiates us from dashboarding tools is that with us an end user can trigger a task that gets or acts on data (as opposed to rearrangement of existing data on ui).

could you elaborate on cron jobs being a pain point? would you use it as a scheduled task to fetch/prepare data before user logs in or let users schedule jobs on their own to run async? any use cases you could share?

> could you elaborate on cron jobs being a pain point? would you use it as a scheduled task to fetch/prepare data before user logs in or let users schedule jobs on their own to run async? any use cases you could share?

Sure, I've used cron jobs to collect data, send reports, and check if any users should receive push notifications or alert emails.

The pain point is that celery can be a little tricky to configure when you're working with docker-compose. It works, but if I had to re-figure everything out again, it would take me a while.

I've had the need for things like this very often. But we had multiple metrics to store and visualize, we went with InfluxDB and Grafana for that purpose. Maybe one could create an integration with at least InfluxDB, because it is great for time series.

Hi - sorry for the random note - but would you mind chatting about this?

Sure, what do you want to know? We can also take this discussion to email or mastodon or whatever.

Great, much appreciated - i'm trying to understand the screen scraping of gas volumes, to trade nat gas. My email is my username at the very popular google email service.

10-4

Looks cool! I think there is a huge need for tools like this, especially as AI turns more subject matter experts into programmers who can code a bit of python.

At my company we have recently started using NiceGUI which is a python wrapper for quasars+tailwind and seems like a very similar product. I’ve found it has a great level of abstraction that enables you to do Python only web App development without too much magic, but also lets you sprinkle in some CSS and javascript if needed.

> as AI turns more subject matter experts into programmers who can code a bit of python

I also think there's a good number of people who have basic Python skills coming from data analytics and data science backgrounds, who might not be doing hardcore ML research but who nonetheless want to build simple web apps. One of our hypotheses is that our product would be a good fit for them.

NiceGUI looks interesting, reminds me of reflex.dev a little bit.

what kind of apps are you building with it?

I work on a Bioinformatics team, so we are a bunch of programmers, but not fully-fledged software engineers. We know Python well but have no front-end experience.

Some examples:

- Another non-technical team needs to know if our test covers specific genetic variants. The code to answer this is 10 lines of Python + a 100 line CSV. We can solve this with a CLI on our local computers but to serve it to the other team was a huge blocker until we started using NiceGUI. Now its 10 lines of Python + 10 more lines of NiceGUI Python and they have a website to go to so they can self-serve the answer to that question. All done in a 2-4 hours.

- More complicated, we have a workflow where we want to select data from a database via a series of filters, run some automated algorithms on it to generate new data, denormalize and view the data, manipulate it using an Excel-like interface, and then update the database with the edits that were made. NiceGUI + their AG Grid integration let me build an application that has all the great GUI features of Excel when it comes to grid-based data manipulation but is fully programmable with 99% Python (and like 1% JavaScript).

- I also built a data hub that integrates and displays data from a bunch of our different data sources and displays it based on some queries. If I can write a tool in Python to do something, I can now easily deploy an internal app that does that too, without knowing any front-end code. It even has the flexibility that when needed I could dive into a bit of HTML with the help of ChatGPT to embed iframes of PDF files getting served directly from S3 links.

The great thing is that this is all done in Python, all version controlled in the same repo as the rest of our codebase, uses open source software, and can be deployed easily within our VPC using terraform+docker. So it's a very maintainable dev ops experience compared to most other no-code/low-code tools, while at the same time enabling people who have programming (but not really engineering) experience and are subject matter experts in other areas to build fairly complex and customized GUIs.

It's also using FastAPI under the hood so you can implement some things at that layer as well. I know that's how they suggest implementing Auth, but I haven't dabbled with that as well.

these are great examples, thanks for sharing! the second one is particularly interesting. python seems like a perfect fit for that use case.

are there any limitations you encounter with NiceGUI? do you need a user permission feature or does each user get admin access? can you see it scaling up easily?

Auth is a big limitation. It's not a built-in component, they have an example [1] using the FastAPI layer for auth, but I haven't had the time to try implementing it. It's definitely not something you get out of the box with NiceGUI.

For scaling, I am viewing it mostly as an internal tool builder. I wouldn't recommend it for external applications. So as far as scaling an internal app I think it works fine. Their website [2] is built with NiceGUI, and it works fine, but you can feel the lag occasionally on some of their larger demo pages.

1. https://github.com/zauberzeug/nicegui/blob/main/examples/aut...

2. https://nicegui.io

got it. thank you for your feedback, i really appreciate it!

FastUI (https://github.com/samuelcolvin/FastUI), a fully OSS Python-to-React library was just launched recently too

this looks great, thanks for sharing! i’ll check it out. we are also big fans of Pydantic and FastAPI

Have you taken a look at django-ninja? It's like a modern take on Django Rest Framework (async + OpenAPI + Pydantic support are built-in)

Not yet, but will check it out! Thanks for sharing it

You've chosen a really bizarre way to package your software. I'm looking through your repo and can't see any code for your libraries. It seems like its somehow part of the docker image? So then this is just a shim for a docker environment that contains the code? Normally people would use Github for a hosted repo and make their software available on Pypi. But deploying with a docker file is kind of opaque and sketchy.

I would give better feedback but still no easy way to see the code? Unless you're trying to do it like this to have something like a closed-source version of your libraries... which would again be kind of a bizarre model to use with Python.

Yeah, the code is in a docker image, published on docker hub. It's prepackaged so it's easy to set up with docker-compose. The repo mostly has the docker files needed to self-host the dropbase worker and client. As you said, it's a bizarre, but not uncommon way to distribute. We're not technically open source at the moment, but considering evolving into source-available, and maybe eventually move up to an open source model. But we still have plenty to figure out. It's a bummer we can't get your feedback though, that's definitely a nice thing about open.

So does the docker file have something like python bytecode files in it or actual source? If it has source aren't you worried about people leaking it?

It has actual source for the worker. We aren't worried about it being leaked because we are not particularly trying to hide it in the first place. We will probably make source available to paying customers on request if they want to verify that their sensitive data only moves between self-hosted worker and self-hosted client.

The other reason is that internally we've always thought that we'd eventually gravitate to an open model when the time is right i.e. at least until after we've figured out the product.

I am confused on why I need to sign up for an account to try it on my machine?

yes, it's a bit inconvenient, but user management and ui component definitions are managed by the dropbase server. because of this, we need an account, with a token to identify and authenticate a workspace

Very cool, thank you for sharing!

Do you consider your customer path someone coming from e.g. Airtable and converting? Or are you looking to find someone who would be choosing Django for their next project?

(This looks like something I would use Django for, although the additional building blocks are nice sugar on top too)

I'd say it's closer to the latter, unless you are already quite familiar with Django. Dropbase is a lighter framework with a more narrow use case, whereas Django is a much more powerful, complete, and you could practically build anything with it. For internal web apps/tools specifically though, it'd be much faster and with a smaller learning curve to build with Dropbase.

Congrats on launching!

> a backend API for app/component definitions hosted by us to simplify pushing feature updates

Any plans to open-source that part as well?

frankly we're new to open source. and technically we're not really open source. we wanted to take advantage of the self hosted nature of data processing worker, which are safety, extensibility, and developer trust. that's why the worker is under the source-available model.

as we grow and learn, if we get interest from the community to contribute, we'll definitely consider opening more of the codebase.

Also fun fact: originally we only intended to enable self-hosting for the Worker, but we ended up enabling self-hosting for the Client too. If we also end up enabling self-hosting for our backend API then we'd probably rethink our distribution approach

That looks fantastic! I own a startup where we used to relay he-vea-ly on retool (until we could automate most of the Retool work with ChatGpt haha).

I would have tried out your approach if it was out back then, I am much more well-versed in Python than JS. Having some way to write code in files, and then link it to the table structure makes a lot of sense (having lots of spaghetti code all over the place was one of the core issues of Retool, also it became slooooow at some point). Simplifying to a table + sidebar view is a very good idea (that's all we ever did).

Thanks! You’re spot on about our approach! Python, binding code files to UI, table+sidebar.

Chainlit is my new favorite Python webapp framework, it’s especially geared toward UI for LLM chat apps. (It has nothing to do with LangChain fortunately, though it does support it and the name probably is inspired by it).

There are unique challenges in making a decent looking chat app. State management is one such. Streamlit’s approach is to rerun the script on every action, which means your code needs to be aware of this, and this usually results in headaches and spaghetti code. Chainlit has a clean approach — I don’t know what they do under the hood but at least from a dev POV it’s far simpler.

I’d be interested to see how a basic chat app is built with Dropbase so I can compare.

Looks interesting! I'll check it out. We don't currently focus on chat apps and don't have a chat component yet so it'd be significantly harder to do this.

why the internal moniker ...what stops this from being "external" facing?

I think it requires a lot more UI components, more flexible layouts, and customization options to be able to build something externally facing. Building for end-users, especially on the consumer side, tends to require a lot of flexibility on all 3 aspects. Our product could handle it, but the resulting apps will feel quite limited.

For example, one of the limitations is that we have a highly opinionated app layout, with a data (table view) on the left, and a sidebar on the right to perform actions. Only a small fraction of all external apps have this layout (e.g. database lookup tools, CRMs, data editing tools) but on the other hand, almost all internal apps look this way.

I am so confused about this too. retool, tooljet, budibase - why is everyone doing this? Best I can figure out is that no one has found a pricing structure that works otherwise, which would be rather sad if true.

I assumed this was because it’s internal devs that are actively looking for platforms to build on, while external devs might already have stacks they prefer to work on due to how it interacts with their security postures. Pure speculation, but it’s been my anecdotal experience.

i second that. for external-facing tools, you probably want something custom, branded, and more flexible. when it comes to internal tools, you typically want something quick to get the job done.

at dropbase, our focus was on enabling developers to get stuff done efficiently. we noticed that for 90% of internal tool use cases, you only need a table and modal to get user input. so we focused on developing those. while it may not be sufficient for external apps, for internal tools, it should cover most of that you need

Are you aware how most companies external apps look like? Here's how: They don't.

What you compete with, what you have to beat, is not "something custom branded and more flexible". It's nothing at all. Cutting yourself out of that market with a tool that would easily be powerful and user friendly enough to fill this gap does not make any sense to me, if that is in fact your true reason. (And also I don't understand how that could make any sense intuitively if you just look at how often you see google forms being used by a big company as an external data collection tool).

It could be such an obvious differentiator for any of the competitors – but, like I said, I suspect the actual reason to why people are so ready to give up on this is rooted somewhere else.

This is actually quite encouraging for us as product developers (although maybe it's not a good thing if end users don't get good tools). It just means there's a lot more room to grow. I wouldn't say we've given up on external, but there's definitely a part of us that's hesitant to communicate the product as a "build anything" app so early. The fact that you think that could actually be an obvious differentiator is quite intriguing and thought provoking. I should do more research and understand the extent to which customers of big companies are exposed to google forms (and similar tools). Maybe we'll discover something interesting in the process. Thanks!

I understand. Maybe a niche for you, that might be interesting to explore,from my latest personal experience: Managing a medical business, including a combined portal for patients and providers.

For the patients, you might need submission process, you might need a place for people to see or cancel their next appointments, fill out a form or upload some pictures from other, while also making this information available internally, with doctors being able to document therapies and such.

Nothing fancy; I would hardly call it "build anything", it's all fairly CRUDy and on the face could be very effectively handled by all retool-alikes. (In fact budibase for example could have easily filled the need from a technical standpoint – but having to pay xx$ indefinitely per "customer" just does not work out, when you see most of them only once a year and maybe only once total, while having to keep records for many years.)

That's an interesting use case. Thanks for sharing. I think I understand your point better after reading this. I agree that having to pay xx$ indefinitely for presumably many end users who will only fill up the form once (or very rarely) doesn't make sense. We don't have a solution to this just yet, but I have a couple of ideas on how to tackle this.

PS. CRUDy sounds like a fun and quite literal name for an app builder!

It's because every small business has this problem and need, and there are a lot of small businesses. But selling technology to small businesses is extremely hard.

Because it lets them establish a beach-head in a less-demanding market, but one with deep pockets. It also lets them create corporate relationships. With all this revenue they keep adding features until the product is more general purpose and can be used to build anything. If they try to boil the ocean to begin with, they'll fail. This is a more pragmatic, staged approach.

It's just how we try to narrow down the uses cases that the product would be better suited for. I'd love to come up with a better name for it. At the end of the day, I think we're all just different approaches to a similar problem/use case

This is interesting, congrats! I'd really like to try it on my own, without booking a demo. Is it possible somehow ?

Thank you!

Thanks! Yes, absolutely! All HN readers can try without booking a demo. Get an account here: https://docs.dropbase.io/setup/ and then follow instructions for local development setup here: https://docs.dropbase.io/setup/developer

Thank you so much, I'll try it !

https://anvil.works is excellent

I'll check it out

Looks nice, but I'll pass and stick to streamlit.io as they don't require an account and a connection between MY app and YOUR server for some misterious reason which is not clear anywhere.

Streamlit is a great. Despite the fact that we are both Python-focused, the use cases for the two products are mostly different at the moment. When it comes to triggering tasks/actions, updating databases, processing data, and talking to APIs, you’ll find Dropbase the more convenient of the two.

What makes a web app "internal"? Does it mean it's just made to be run on localhost? Does it mean it would not run on a server? How so?

Also, why using this vs creating a desktop app? (There are ways to create GUI desktop apps in Python)

I normally understand internal to mean an internal corporate application used by the employees.

correct. internal apps are usually built by developers for internal users. examples include processing refunds, updating customer information, managing user permissions, triggering batch jobs, and etc.

the goal of internal apps is to optimize tasks that are tedious and time consuming, but not too common for an off-the-shelf product to be available.

since the internal apps aren't the main product developers work on in a company, they prefer to build them quickly with minimal resources.

internal tools usually run on a server, as does Dropbase

Interesting. How does this compare to https://flask-appbuilder.readthedocs.io/en/latest/?

I hadn't heard of it, but I'm excited to check it out!

Looks cool. I have so many internal scripts that need a face/UI.

Give it a try! You can copy those scripts as-is into the workspace directory and with a few lines of code turn them into web apps.

Did you guys pivoted Dropbase from CSV analytics to internal app builder? Interesting move. Internal.io just sunsetted. Maybe Dropbase has what it takes and finding its P/M fit.

yes, that’s us. glad to see you remember our previous iteration :)

internal app builder is certainly a challenging market to break into, but we believe we have something interesting to offer and are quite optimistic about our approach.

were you a customer of the previous dropbase version (csv to database)?

thanks again for your interest, it is always appreciated!

Oh man, I would love to compare notes.

I pivoted in the reverse direction from:

https://github.com/pycob/pyvibe

To

https://github.com/vanna-ai/vanna

Totally, i'll reach out!

I was hoping you were the hardcore techno label. What a pivot!

Ha! What a pivot that would have been! And the story behind it!

Thanks HN! Really appreciate your input! Gotta sign off now though, it's getting late for me. I might answer some more questions in the morning if this is still on!

It would be great if this could generate a desktop app rather than another webapp that I need to host somewhere. We need to focus on desktop apps again.

If you’re interested in Python desktop apps, check out TKinter. I have a piece of boilerplate code I typically start with, and within an hour I can have a finished piece of software that runs in the native windows manager on any OS with no libraries or frameworks to manage. It’s not the prettiest code but it’s very easy to write and I love how native it is.

We've heard of Tkinter before, but haven't really looked into it. We don't have a lot of experience with desktop apps and we're mostly unfamiliar with this space. But a few people have asked us about desktop, so we do a bit of research here.

Felt.dev is any easy way to write flutter desktop apps with Python

I looked at alternatives like tkinter and it was the most compelling

This is really cool. I know lots of banks and trading firms have built home grown tools that do something similar to this.

Thanks! We've heard something similar - many Python tools in financial services. I think they build tools on R too. We should probably try to reach out to people in this industry to learn about the kinds of apps they build and whether their home grown tools are missing something we can ship

How does it compare with other tools like flask and django?

Flask and Django are web frameworks that are more geared towards general app development - you could build anything with them. Dropbase is an app builder that makes it easy to build certain kinds of app: internal apps used to support customers, business operations, build admin panels, or trigger tasks or processing jobs. You can’t build absolutely anything you’d want with us, but for a narrow set of uses cases, you can build it very quickly.

There are plenty tools like this, plolty dash, justpy, nicegui, lona, reflex, streamlit, just to name a few. If your app does not involve complicated interactions, streamlit is really easy to pick up. We also had a great experience with plotly dash for a more complicated application. nicegui also seems very promising.

Also, a lot of the ones you mentioned are actually open source, no strings attached, self-hostable. I have personally used plotly dash and streamlit, still have a couple running for years. This one appears to be a closed source (?) commercial offering where you have to have an account to do anything with it.

Nothing wrong with commercial offerings, but the trend of posting a GitHub URL to fool people into an open source first impression when there’s nothing in the “repo” really irks me.

I think I understand the irk, but I feel that your presumption of our intention in posting a GitHub URL is unfair. In fact, I'm not sure how else we'd share the news that you can self-host this without posting a Github link. We've made it very clear throughout the comments that we are not an open source project and nowhere in our website or GitHub do we try to mislead people to think so.

I fail to see why the Show HN link shouldn’t be https://www.dropbase.io, which is in the very first sentence.

But maybe I’m the dinosaur. I still associate GitHub with open source, but closed source developer tool startups seem to increasingly use it as a ProductHunt.

Some context here is that our launch is mainly to developers. Other users can't even sign up from the website or use the product without self-hosting. In any case, we'd still need to post a link to Github, somewhere.

If you're saying it's ok to post a Github link to a non-open source project, but just not as the main URL, I'd understand, but I still feel that in our specific case, the Github link is the least friction path to set up for self-hosting. I think a developer who goes to a marketing site and doesn't easily find way to setup/self-host would be more frustrated.

> I think a developer who goes to a marketing site and doesn't easily find way to setup/self-host would be more frustrated.

In that case the marketing site should probably be fixed.

"If it can be self-hosted, it has to be on GitHub" is a really weird claim, considering that tons of "self-hosted" open source projects aren't on GitHub. debian.org, for instance.

Also, I personally wouldn't call something that requires an external backend API (if I'm understanding this correctly?) "self-hosted". Partially self-hosted? Not sure. It's not exactly on prem either.

These are all great tools! The use cases we are going after different than those these tools make easy. One way we think about the difference is analytics vs operations. Another way is dashboarding (streamlit) vs triggering actions (dropbase). By triggering actions we mean, triggering tasks that get/act on internal/external data, as opposed to a rearrangement/display of existing data.

There's also that library all the AI models started using that gives you a public URL to share. After researching it: https://www.gradio.app/ is the link.

It's used specifically for making simple UIs for machine learning apps. But I guess technically you could use it for anything.

Gradio is popular for machine learning but is versatile enough for interactive web apps, really easy to tinker with

I'll check this one out - it looks very interesting!

We definitely need more ways to build quick web UIs for Python code. Looks sick!

You have 6 comments from your account and one of them is this:

> I'm one of the engineers behind Dropbase.

So I hope this isn't the first time you've seen this.

I can confirm all our engineers have seen this product before launching it lol.

The comment you are referring to is most likely from a really old post. He was an intern at Dropbase a few years ago, back when we were working on a very different product!

Absolutely, thanks!

thanks Kelvin! :)

So it's an agent that phones home and exfiltrates all your sensitive corporate data to the public cloud?

Lol.

I understand that SaaS is the only way to monetize software projects in 2023, but this whole setup is not defensible.

Lol not sure if your comment was meant as a joke, but wanted to clarify in any case to clear up any misunderstanding: We don't exfiltrate your sensitive corporate data.

The self-hosted client talks to the self-hosted worker, the latter which is the server responsible for querying and processing your data, and storing your creds. So basically your sensitive corporate data flows from your self-hosted worker directly to your self-hosted client. There's no funny business in between. Only the worker can initiate calls to our backend API (not the other way around), and you can easily inspect our network requests and payloads. We do store app metadata, UI properties, and the names of the columns you configure in your tables. The worker sends periodic health checks to our backend. Hope that clears things up!

How would you compare this to tools like Budibase?

I wouldn't. Budibase looks like a no-code tool and we are code-centric. I saw in your profile that you are the cofounder of Budibase - perhaps you can confirm my understanding.

Or NocoDB?

Looks like Airtable. Also no-code, like Budibase above.

I am surprised that lack of control and customizability over the frontend is being billed as a feature.

I've built multiple internal tools like those in the example section, and even with a solid framework like react-admin, one of the first requests you're going to get from internal stakeholders is tweaks to the UI.

It's a myth that internal users aren't as demanding as external stakeholders. If anything, they can be more pushy.

I would not want to launch an internal tool, except as an engineering-only POC, unless customizing the frontend were at least as easy as customizing the backend.

that’s a fair point.

what would be the minimum set of customization required to satisfy the majority of the tweaks requested by internal users?

would it be sufficient to offer themes (dark/light modes), a custom logo, and control over font sizes? or, is it more fundamental, like adding your own css and changing the size/positioning of components?

Even your "more fundamental" examples are just scratching the surface.

I know you're a Chief Technology Officer not a Chief Product Officer or Chief Sales Officer, but if you're not already getting an earful from prospects or clients about wishlist items on the frontend, gird your loins, because it's coming.

thanks for the heads up!

i feel like the challenge would be to find a subset of customizations that would work for most users.

I've done plenty of internal web apps with Python's old cgi module and it's really about the simplest approach. Too bad the cgi module has recently been removed from Python due to some weird neurosis about underused modules. It's still possible to side-load it from someplace though.

This is something that irritates me about some languages. I get the intention of keeping a clean language, but for something as foundational and basic as CGI... what's the real problem in keeping it there? It's not like CGI itself has changed much in the past 20 years...

I've written some stuff in Python but it seems like keeping up with Python and its near-infinite PEPs is half the job. They still can't get on the same page about how to package and share things on PyPI, or which tooling a developer should use to test integration or build packages, etc. I'm somewhat realizing what I enjoy about Python is more its dynamism and lack of verbose syntax. Or, cool stuff like list comprehensions and decorators.

The community is insufferable. I wish I could find a programming language that was high level, effective, but boring in the sense that it isn't being changed every other year. Something that I can build on for five years or more.

It's a strange thought but I've heard of people using PHP, of all things, to write general purpose CLI programs and whatnot. It had never occurred to me to try that even though I knew it was possible. It just felt... dirty.

Not strange at all! Leave those assumptions behind, take a look at symfony/console and minicli. PHP is not shiny or snarky as Python, but resilient and "boring". The "dirtness" that you are feeling is just a way to keep those insufferable people that you mentioned out.

I mean, to some degree I see where you're coming from. PHP extensions can be written in C, so you can drop down to lower level as needed. Hardly different than Python in that regard. PHP is just something I've always just used in a Web serving context, so pre-populated $_GET, $_POST, etc.

I would hope argv and argc at least are passed by default in PHP programs on the command line. New experiment unlocked I guess.

What kind of apps were you building and what did you like most about building with the cgi module?

The license kinda sucks though: ``` 3. USE RESTRICTIONS

Licensee is expressly forbidden from:

(a) Incorporating, modifying, or using the Software as part of any other product or service; ```

We should probably clarify that although we are pointing our post to our Github repo, it isn’t technically open source. It’s something we’d like to explore in the future with Dropbase though. At the moment, you can self-host our Client and Worker.

We actually started with just releasing the Worker for self-hosting. Then based on feedback from one of our friends and early users, we decided to also distribute the client for self-hosting due to security concerns. Maybe in the future if we also allow self-hosting our backend API it could make sense to distribute Dropbase differently!

Wait people read those?

We should have a Chrome extension that just summarizes the license for any Github repo you hang out at!

I'd love a TypeScript/NodeJS version of this, this looks really neat but I prefer TypeScript over Python.

I really like Typescript, but this is a really weird thing to say in relation to building web-apps in a single language considering that is one of the primary reasons to pick Typescript as a language. It’s not the only reason, but if Python, Go or whatever you love had the ability to do with the web what Typescript already does, then I’m pretty sure we wouldn’t be working with Typescript, and I actually consider Typescript to be one of the best modern languages. But really, Python or Go would probably take over the world if they had the same capabilities for dom manipulation.

You've got plenty of options for writing web frontends in TypeScript/NodeJS. Like, ALL OF THEM.

Show HN: Dropbase – Build internal web apps with just Python