101–110 of 230 posts
> In the abstract, FastUI is like the opposite of GraphQL but with the same goal — GraphQL lets frontend developers extend an application without any new backend development; FastUI lets backend developers extend an application without any new frontend development. I know a lot of backend developers who are backend developers specifically because they don't enjoy frontend work and prefer to leave that work to people…
> In the abstract, FastUI is like the opposite of GraphQL but with the same goal — GraphQL lets frontend developers extend an application without any new backend development; FastUI lets backend developers extend an application without any new frontend development. I know a lot of backend developers who are backend developers specifically because they don't enjoy frontend work and prefer to leave that work to people…
> to build something complex on the frontend But, unlike frontend devs, designers and product managers believe these complex things are needed, they almost never are and actually bring a lot of issues with them instead. I rarely see a complex component/combination (in a SaaS, let alone on some landing/public page) and think, "well, that adds real value over just a standard component". If you can point some out, pleas…
One common front end component that you can’t build with vanilla HTML is an autocomplete/typeahead input. I’ve had to build a few of these in JavaScript and I do think they’re genuinely helpful. It’s helpful to get suggested options as you’re typing. I also think search results that get filtered in real time as you type are helpful and can’t be accomplished with pure HTML.
> In the abstract, FastUI is like the opposite of GraphQL but with the same goal — GraphQL lets frontend developers extend an application without any new backend development; FastUI lets backend developers extend an application without any new frontend development. I know a lot of backend developers who are backend developers specifically because they don't enjoy frontend work and prefer to leave that work to people…
A template language (that isn't Python) is sufficient. Even better if you can render the templates from different languages.
I'll never be defining web app presentation in Python.
Earlier quoted context omitted.
The first point you made is what myself and my team have struggled with. We have built simple apps for customers to upload a document to interact with and having the state be accurate to the document that the user uploaded was a major pain. Felt easier at that point to build something from scratch than to keep messing around with streamlit's session states
Would you consider giving Shiny (for Python) a try? https://shiny.posit.co/py/ It's (I hope) pretty close to Streamlit in ease of use for getting started, but reactive programming runs all the way through it. The kind of app you're talking about are extremely natural to write in Shiny, you don't have to keep track of state yourself at all. If you decide to give it a try and have trouble, please email me (email in pro…
What's the use case for this? Is doing a roundtrip to the server on every client interaction ever a good idea for building user facing UI?
Hold on I thought HN is all hyped about HTMX now? Isn't that what that does too?
What's the use case for this? Is doing a roundtrip to the server on every client interaction ever a good idea for building user facing UI?
1. It can save a lot of repetitive boilerplate code
2. You can keep validation rules in one spot.
I've been working with some toolkits like these after years of 'backend api, frontend vue/react/angular' and it definitely can save a lot of time. It's not always the best fit, but there isn't one approach to all applications that is the best fit. Everything has tradeoffs.
Works beautifully and fast, send only rendered code to the front. Have db admin for when you scale