Pick a "classless" CSS library from a site like CSSBed[1]. These are kind of like Bootstrap, except you don't need to write any CSS or apply any CSS classes in your HTML for them to work. No tooling necessary; just include a <link> tag in your HTML document. If you'd like to try something similar to this "Tailwind" hotness everyone keeps talking about, try Basscss[2]. Again, no tooling, just need a <link> tag.

Once you start needing to add interactivity to your site, htmx[3] is nice and decently simple. If you really want something React-like, Mithril.js[4] is very similar but much simpler.

[1] https://www.cssbed.com/

[2] https://basscss.com/

[3] https://htmx.org/

[4] https://mithril.js.org/

Or Alpine, but not htmx. Learning all those attributes (30, not counting the HTML headers and the JS API and the CSS classes, and events like htmx:historyCacheMissError) is not as simple as some in HN make it out to be. Just look at the most basic example in the top here: https://htmx.org/docs/. Meanwhile Alpine is read much easier, and has half the amount of attributes (15): https://alpinejs.dev/. Also look at the interactive component example from React: https://reactjs.org/tutorial/tutorial.html#making-an-interac.... It looks easier if you don't hate JS.

Of course, I respect that some avoid JS with passion, but I don't buy that it's simpler. It's juss less javascript-y.

Most of what OP needs can probably be achieved with a few HTML files and <script> tags. It will probably be a few more keystrokes than `npx create-next-app`, but the disconnect between the code he/she is writing and the final running application will be much smaller, and I think he/she will have a better understanding of what the heck is going on.

Fair point on htmx and Alpine; I have not given Alpine a shot yet, but it looks nice from the docs.

I believe you, and I've also met some like you described who came to our interviews indeed, but it's more like the failure of their mentors. I've also met back-end engineers, with a lot of experience, who couldn't write a simple HTTP service with C#, without using ASP.NET, nor open a simple DB connection without using EntityFramework APIs.

Understanding what's going on will be even harder if it's not your main field (back-end developer just trying to get front-end out of the way) and some magic there won't cause a lot of problems IMHO.

But for an experienced backend developer, the mental model of Next is no problem, and the flexibility of SSR will feel liberating. After a few weeks you might even put down the Flask!

If you want to use SSR on your pages, I'd recommend sampling some Next projects (just pick one of the examples and get it running locally). You might like what you find. And for closer integration with Python, I'm sure there are options for server-side rendering of JSX that you could use, although they'll all ultimately need to either wrap a JS runtime or emulate JSX compilation in Python. So you may as well just skip the middleman and go to straight to react, whether via a framework or otherwise.

If you don't want a heavy framework, or you just want basic CSR for some richer pages, you can accomplish a lot with just `react` and `esbuild`. Even SSR is just a matter of calling `ReactDOMServer.renderToPipeableStream()` and doesn't need a framework like Next. They're just nice because they take care of all the problems you'd end up solving in a robust deployment anyway.

HTMX makes this incredibly simple:

    <div hx-get="/example">Get Some HTML</div>

https://htmx.org/reference/

Oh, apparently I can put hx-trigger="mouseup mousemove delay:500ms" there to make it explicit. I mean this thing has its own DSL, and IMHO, you are escaping from JS and jumping to another language, which you still have to learn and less people know of.

In alpine, it's explicit. You can say fetch, then replace something in your data, and use that thing in your x-html. You still need to learn some, but in my experience, much less to keep in mind than htmx.

OTOH, Next.js is even easier than Alpine to learn. You just create pages as js files and run the server. Yes, you need to run a BFF (back-end for front-end) but it's just that. The thing even updates in real-time. Only thing that can match this is Phoenix LiveView but I can't speak for it as I've just played with it and nothing more.

It really looks like the x-html attribute you're complaining about is just using plain old javascript. It takes a statement that resolves to a string, and renders that.

The statement they provided happens to be pretty terrible for docs (I would have just used the built in fetch api, instead of the axios networking library - https://github.com/axios/axios), but it's plain old js regardless.

Your example is some custom fucking DSL that I have NO idea what it's doing. When does it run? how does it handle errors? What is the base url? What happens to the original text? How does it auth? What if I needed to post, or put, or delete? It's an entire fucking language I have to learn on top of the actual css/html/js knowledge required to understand this. In almost all cases, you're better off just learning "plain old javascript" since that skillset travels with you everywhere.

basically: DO NOT MAKE ME LEARN YOUR FUCKING DSL. It's wasted time and effort for me, and learning it provides absolutely zero benefits outside of your library. Further - it will fucking leak, and then you're right back at writing plain old js again, but now you have to understand the intimate details of the library implementing the dsl to tweak the right spots.

Even alpine turns me off a bit here (it's still a dsl, even if most of it reverts to plain old js) - but at least they're incredibly up front about the total time investment to learn the dsl (15 attrs, 6 props, 2 methods). HTMX is like 5 times the size (https://htmx.org/reference/), so I assume roughly 20 times the effort to learn the DSL.

> Why should only <a> and <form> be able to make HTTP requests?

And than you turn off your js in the browser and try to open a demo from the htmx. White screen of death. It doesnt even work without js. Why even bother to use it? HTML is not perfect, but it is well tested, can work without js, also works with screenreader and you can create accessible web apps. With htmx you can create something usable to some degree, but completely inaccessible, which may lead your company to be sued.

https://htmx.org/docs/#boosting

> Why even bother to use it? HTML is not perfect, but it is well tested, can work without js [...]

I agree completely. Still you can use HTMX for some cases where you would need client-side JS anyway, but without actually having to write .js code.

> which may lead your company to be sued

OP specifically said 'Given its home lab style stuff', I think HTMX would be a good fit for that.

Any sort of reaching out to the server from JS will be disabled.

However. For the OP's question, a toolset for quick and easy frontend development for a backend engineer who doesn't spend much time doing front end, avoiding npm is definitely the way forwards. It introduces a HUGE amount of complexity to a project who's aim was simply: produce some HTML and CSS with the necessary javascript to make the UI work. If your typescript compiler or Vue/React transpiler or bundler isn't working quite right, it is completely non-obvious to a backend engineer who isn't familiar with npm what to change in package.json to fix it, or even how to go about debugging it.

If you know you're going to end up at that point because your designs include a high level of interactivity, you might as well use tools that will support your needs from the beginning--either that or revise the designs to be less ambitious.

Often newbies have a vision of what they want to build that matches the complexity/polish of established products--they're building Uber for X or Instagram for Y and so they want that same silky smooth UX. To achieve that, they are going to need a lot of packages and tools. The solution in that case isn't necessarily to convince them to build the whole thing in vanilla html/css/js instead, but to level with them about their expectations being unrealistic for where they're at.

What's that certain level of complexity? I have some heuristics I might use, but what I've noticed is that even discussion about where these product behavior thresholds are seems to be rare.

And "polish" and "silky smooth" don't seem like features that come automatically with any of the top frameworks either, nor things that are inherently difficult without them.

In my mind, the best advice for beginners is to just follow the mainstream. You'll get the best tutorials, best community support, easiest tooling, and least fragmentation. First time using a computer? Mac or Windows. First time programming? Javascript. Just want to do simple web dev? NPM and React. After you've got the basics down you can start exploring the niche stuff like Linux or Rust or Htmx.

Just one thing: do a favor for your visitor's privacy and don't use a CDN, download the css/js packages and host them yourself.

> An easy way to try out Mithril.js is to include it from a CDN and follow this tutorial. [1]

[1] https://mithril.js.org/

This thread is about engineers looking for a simple way to just create a UI. Pandering to niche neuroses about privacy by avoiding entirely mainstream technologies such as CDNs is out of scope!

You can think of it being a neuroses for yourself, but you don't have to label it as such for others.

It can be a perfectly reasonable concern in the life of others, while not in yours.

> This thread is about engineers looking for a simple way to just create a UI

The recommendation doesn't go against this. To create a UI, you'll have to host at least one HTML file. Potentially several, also images, stylesheets, javascripts, etc. One more to ditch the CDN doesn't add work to the process. Deploying one or two files isn't much of a difference.

Often people will see this and say "that doesn't scale!" Well, yeah, unless you start writing optimizations, at which point, you maybe created your own framework or view library and maybe you should start looking at something like Preact or Mithril.

On the other hand, DOM APIs can get expensive quickly especially if you're calling `document.createElement` repeatedly to create maybe 1000s of table rows.

So then you have to find ways to minimize the amount of DOM operations that must happen. Or like the rest of us, just pick up a JS library that already solved this problem.

HTMX has been a joy to work with.

[1] https://tailwindcss.com/blog/standalone-cli

I mostly agree with the first three (with caveats about how interactive/app like you want to the result to be), but I totally disagree about Tailwind, the only exception being if all you want to do is throw up some <p>s and <hx> tags and have it look better than the default.

If you're going to do much layout at all, you're gonna need CSS. If you already need CSS, Tailwind isn't much more. It's basically just css properties expressed as classes in your html. If you know the CSS already, the Tailwind equivalent is in most cases guessable. If you don't know the CSS you need yet, you'll mostly have to learn it anyway unless you can copy/paste somebody's existing layout and have it be good enough for you. And again, once you know the CSS you need, the equivalent tailwind is easy. The benefit of Tailwind is that it puts markers/boundaries over the raw CSS that are easier to reason about, and having it right in the html (IMHO) makes it a lot simpler to work with.

You've mentioned in other comment:

> I wrote that in reaction to the comments telling a front-end newb to start installing a bunch of NPM packages and CLI tools. I don't think OP should be "afraid" of Tailwind, but for someone new to front-end development, I would not recommend you install a CLI tool or some funky CDN script just to style your HTML. Basscss is a good alternative since it's small and ships as a single plain CSS file.

I agree with what you've said, but again excepting Tailwind. A "compiled" version of TW can be used (very easily) from CDN[1] so there's no need to mess with npm or cli tools.

[1]: https://tailwindcss.com/docs/installation/play-cdn

I don't think OP should be "afraid" of Tailwind, but for someone new to front-end development, I would not recommend you install a CLI tool or some funky CDN script just to style your HTML. Basscss is a good alternative since it's small and ships as a single plain CSS file.

In short, these solutions take JavaScript out of the mix entirely and basically let you deal with a single logical "app", rather than a separate frontend & backend.

[0] https://github.com/phoenixframework/phoenix_live_view [1] https://github.com/dbohdan/liveviews

First, engineers build application using just LiveView and it works just fine. You click a link you have table with your data, you click button you have filtered table, click another link you see a chart.

But then UX concerns are raised from PO/PM/users. Users find it jarring that they need to wait a little to see a loading spinner on clicked button. And we litter our views with some alpine.js DSL in attributes or load stimulus controllers. Some stuff is moved to hooks and kept in ad-hoc global variables.

Finally, most of the live views evolve into single html node, with mini-SPA written in some lightweight javascript framework. And everything is wired with phoenix websocket.

LiveView is still a fantastic and very productive tool to quickly create applications but I'm not sure if it scales to users expectations.

If I _really_ need something to be driven by the frontend like a transition then I'll use Alpine.js.

For CSS I tend to use tailwindcss / tailwindui because I know it well and it doens't need npm. If I didn't know tailwind I'd probably look at something like bootstrap or something I can build on top of with vanilla css.

For example: 1) selecting a checkbox alters other fields in the form 2) validation that needs to hit the backend and then present warnings/errors to user 3) field arrays -> sending back a list of fields

So the flow is 1) click the checkbox 2) call sent across the open socket 3) backend does it's logic to figure out what it needs to do 4) backend returns the small diff of changes 5) frontend alters dom.

Just because it can be done 100% server side doesn't mean it should be, especially if its driven out of a "look, no JS!" type of approach.

Staying in one language for frontend and backend is just so appealing. To my knowledge, the other option to achieve that would be having something like Blazor WASM or Rust Yew that compiles to WebAssembly to have a client-side app a la React/Vue/Svelte.

I wonder which of these approaches will end up be more prevalent in the future. To me it seems like compiling something React-like to WASM might be more attractive, because you can stay in your backend language, but ditch the permanent websocket connection.

Admittedly it is still a bit raw. But seemed like a really interesting concept when I was looking for LV equivalents.

[0]: https://idom-docs.herokuapp.com/docs/index.html

Hugely simplifies the overall stack. Combine with TailwindCSS, TailwindUI.com, and you have some very powerful tooling at a low development cost.

I probably need to focus more on 'vanilla' back- and frontend stuff, but man has it been fun so far! Definitely made me enjoy my work more.

We run a half dozen elixir apps in the healthcare and research sectors.

people@polkadotskysoftware.com

I've been screwed over twice by Angular, RXJS, etc. Every month we had to redo most of our work as the community kept deciding on new directions of correctness.

At work, when I do internal tools, they are usually well received. They also pass just below the threshold of having their looks be judged. They're not ugly, because they're almost not there.

Very plain HTML: HEAD+TITLE, H1, H2, UL, OL, A, IMG, INPUT, BR, TABLE, P Javascript as needed, usually embedded in the HEAD There is no CSS.

There's simply no design to attack, no colors or alignments to disagree with. It exposes the interface to communicate with the backend, nothing more.

It's also the fastest and simplest way of getting stuff done, if you don't need to expose it to "end users".

This seems like a very good list with lots of handy easy to compare preview screenshots: https://github.com/dbohdan/classless-css

[0] From that idea that sometimes you just want to take a Markdown document's boring raw HTML output straight out of the processor without any other templating in between.

https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_Text/Wr...

The examples by vonadz are minimal to the point of being a chore to use.

Vs

http://bettermotherfuckingwebsite.com/

If black is too dark, I'll reduce the contrast of my monitor myself, so can y'all please stop trying to force me to squint to decipher your gray-on-gray oh-so-beautiful but unreadable text?

Or

https://thebestmotherfucking.website

?

We also have internal tools based on gigabytes of react across millions of files, we have data fields in there you can't actually highlight and copy the label from that require 3 days efforts to add a tiny feature. But it probably looks nice.

For your use case I would look at AppSmith (https://github.com/appsmithorg/appsmith) or ToolJet (https://github.com/ToolJet/ToolJet).

These are full-stack low-code frameworks, but it's easy to use them to do just the frontend and connect to a backend API you implement yourself separately.

Edit: forgot to mention that these support drag&drop for building user interfaces :)

Quick question because I have no idea what I'm doing: is there any integration in either of those that you know of for one or more 3rd party auth system(s)? I don't want to write my own auth!

It supports at least Firebase and Supabase. I think self-hosting Supabase + AppSmith could be a good combo for quickly hashing out prototypes or internal company apps.

Assembly language is simple.

For layout, don't use any CSS framework, but instead refer to https://css-tricks.com/snippets/css/a-guide-to-flexbox/ often - every time I use some big CSS framework I end up fighting it at some point.

https://vitejs.dev/ for packaging - I got really grumpy when frontend stuff started needing build and packaging tools, but it's the nature of things so you just have to deal with it, and vite is fast, not overly complicated, and supports fast hot reloading.

In fact, since when did ANY web development require those things?

The fact that builds dont need a second build is nice to know, even if useless.

Serving a static Svelte site is literally a one line change in a config file. I've got a good half dozen Svelte sites that live in s3.

Why? Preact is small, fast, and reasonably easy to use. But the main selling point for me was that, together with htm, I don't need any build system a la webpack. No node_modules folder. I just have to load one script (preact + htm bundled), define my components in plain javascript files and import them. Bliss for me.

[0] https://preactjs.com/

[1] https://github.com/developit/htm

Edit: Just read that you want drag & drop style UI building, so this might not be for you.

But for proper frontend projects, I would use typescript, and therefore a build pipeline.

https://www.unpkg.com/browse/lit@2.2.7/index.js

Highly recommend.

I needed to make a little thing "with a few screens" once, and using a react-like model of rendering specific components based on state just felt right. But I really didn't want to get all the CLI and front end packages involved because it was such a small thing -- and preact was exactly the ticket!

No build pipeline is very helpful, actually.

If you are comfortable with plain HTML + CSS + Javascript, adding KnockoutJS will give you a minimal app building capability that you will find useful for several usecases.

You get to manage your application's data model in javascript on the client side and the UI can be bound to your datamodel (bidirectionally) without having to manage it yourself. That is more than sufficient for many usecases.

If you don't want to be fiddling around with CSS too much, you can use something like Bootstrap or Material Design's CSS templates to get some decent looking UI (without getting lost in CSS minutiae).

For your development workflow, start without any bundler (like WebPack or Parcel) first. Once, you have your application working, you can then introduce it as a final step.

I find it a bit unfortunate that Knockout 3 seems to be showing its age at this point and is maybe not something I'd recommend in 2022. I think you can almost do more, easily and handier, with Vanilla ES2020+ than Knockout.

Though I certainly wouldn't recommend against Knockout either today. It's one of the few toolkits of that age that is still seeing somewhat active security maintenance, at least. There's also rumors that there may still be a production-ready "Knockout 4" in the pipeline one day. I'm still somewhat curious to see Knockout further modernized. (Search for "TKO.js" to see a preview. Allegedly, some groups are using TKO in Production already today, though it is under-documented and "unfinished".)

I'm not a dedicated front-end dev, although I did write plenty of KnockoutJS code (I was less involved with the VueJS rewrites; I mostly moved to work on backend code and other things), but overall I'd be a bit wary of KnockoutJS. I'm sure there is a way to avoid these issues, but I was never quite able to figure out how.

Bootstrap has a flex (https://getbootstrap.com/docs/5.0/utilities/flex/) for managing layout, alignment, grid sizing etc.,

Also, targeting multiple form-factors and building responsive UIs is easy once you start with the mobile-first styling classes and then start setting the various breakpoints for larger device form-factors.

If you already know HTML and some basic CSS, getting up to speed on Bootstrap or Material Design basics might be just a day or so. Their documentation is very good and you can go straight to the section you want (eg: tables) and try it out in your HTML.

Sveltekit scales down very well: if you need only CSS and HTML for some paths, that's all you write in your svelte files, and that's also all users download. At the same time if for some other paths you need more Javascript, you can just add it there, without bloating the JS bundle size. Svelte's built-in stores makes it also possible to also do very complex state management, if that's ever a need. With vite under the hood the dev experience is lightning fast.

For styling I pick up Bulma CSS if I need some more complex components (tabs, modals etc.) or TailWind if I just want to pepper a little styling here and there. All this loaded directly from CDN. No build step, no server etc required. You easily do debugging from browser console.

I have made a few internal tools like this which my co workers use everyday.

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

1. https://htmx.org

2. https://simplecss.org

[0] https://reactjs.org/

[1] https://tailwindcss.com/

[2] https://vitejs.dev/

Tailwind: CSS done right, in my opinion. If you haven’t tried it, it’s amazing. It’s a no brainer if you’re not great at CSS (which a self-proclaimed backend developer would not be).

React or Preact: it’s much better than cobbling together strings of HTML or using some proprietary template system. You build views with JavaScript and a teeny bit of syntactic sugar.

Vite: I haven’t used, but I do use esbuild which it abstracts. It’s fast, and gets out of your way so you can bundle everything up nicely.

If you add TypeScript to the mix, you now have one of the most advanced compilers in the world helping you catch your mistakes early.

I know it’s popular to bash on front end folks. I’ve been writing front ends, back ends, embedded systems, and more for over 20 years. These tools legitimately solve some gnarly problems and have turned an area I previously hated (web front ends) into one I kinda sorta like (or at least don’t hate).

In my eyes, it's important to find a technology stack that can scale both up and down in what it does - something that would be good enough for you to ship both production ready software with a bit more effort, as well as knock together a proof of concept in a weekend. Something that's good enough to be used in a team of people who have general experience in the industry (be it full-stack work or front-end in particular), as well as use on your own.

Why? Because the time I have for learning technologies and ironing out all the quirks in any particular setup is limited, it's far easier to make a few template repositories and a few customized component libraries of your own (which may just be renamed Bootstrap integration with a few additional personal touches and quality of life improvements) that you can throw in a new project and start working with it ASAP, not just work with 5 different stacks in 10 different projects, needing to constantly context switch.

Coincidentally, that's also one of the many reasons why most of my apps use containers as their runtimes (standardization regardless of orchestrator) and I don't scoff at boring languages like Java that let you use them as a hammer to beat in those pesky screws in their place.

They can write plain HTML and some barebone css, and thats ok. That'll be similar to asking a backend dev to ftp some php file to a shared host.

Reasons being:

1. React uses jsx,css-in-js and other non standard solutions. Adding additional learning effort

2. React hooks require manual dependency tracking which can lead to error. Literally every other js framework has dependency tracking built in. Vue had it since day 1

3. React has minimal api, and leaves a lot to third party ecosystem. So, not only you need to Google a lot more. But these best tools change frequently.

4. React be default recommends CRA which is slow. While vite (which is excellent) does support react, some of react libraries do not work properly due to ESM and JS issues which webpack ignores.

5. You are not trying to be FE expert, so react's major pro (good on resume) is not relevant

What languages / platforms are you familiar with?

For example, if you do a lot of C#, you could look at Blazor. Server-side Blazor isn't 100% simple; but if you're already doing C#, it's very easy to learn. (In-browser Blazor compilers C# to WASM, Server-side Blazor sends all mouse clicks over a websocket and gets back partial HTML updates. It (server-side) has a bit of latency, but because all state is in the server, you can keep your implementation simple.)

There's also a similar thing for Java, but I can't remember the name at the moment.

[1]https://vaadin.com/flow

* HTMX (formerly "Intercooler") for interactive (Ajax) functionality: https://htmx.org/

For simple personal projects I write all my own HTML and CSS from scratch. It's not particularly hard to write stuff with low to moderate interactivity from scratch and the infrequency that I do frontend dev means it's quicker to do that than learn whatever new framework has replaced the deprecated one I spent time learning a couple of years earlier (that's probably unfairly snarky but from an outsider looking in, it's hugely daunting and depressing when you see just how much churn there is).

The only problem with rolling your own is that you raise the difficulty for anyone new joining the project (if it's something you plan on opening up to other contributors) and CSS can be a bit a of trial and error to get right too.

However if you're just writing a few test UIs to interface with backend APIs you're POCing (which is what your question reads as) then it's probably easier to skip all the other frameworks out there and knock up something yourself.

https://docs.djangoproject.com/en/4.0/ref/contrib/admin/

A similar modular admin system that's more generic is https://www.forestadmin.com/, I think this one has a layout editor too. But that one requires a REST API and so it may require more plumbing, depending on what you've already built. Or it could fit nicely on top of what you already have, if you already have APIs for everything.

[0] https://reactjs.org/docs/create-a-new-react-app.html#create-...

https://reactstudio.com

It outputs create-react-app projects with no extra runtime components or other limitations. You can deploy on Netlify or do whatever you like with the code.

And with NextJS it makes react state management very scalable and rarely need redux at all IMO.

[0] https://pinegrow.com

To be clear, I... don't even know why I want that? Desktop software runs faster than webapps do. But for some reason I feel like people these days simply prefer to not download stuff. Weird.

We also have Pinegrow Online [0] that works 100% in the browser - without webassembly. The performance is quite good for such a complex UI.

[0] https://pinegrow.online/edit/

  body {font-family:sans-serif;}

And you don't need JavaScript to trigger back-end events, as a simple <A> link will work just as nicely.

An <A> link can't do POST requests, and GET requests should be idempotent, so you'll need to use either Javascript or a form with a button to trigger back-end events.

It achieves straightforward abstractions and great speed by not having a virtual DOM.

The syntax is also very pleasant.

This way it's easy to write and maintain. Looks okay. Fast feedback cycle during development. No need for build steps. Works in browsers without JavaScript. Works well on desktop and mobile devices.

Highly recommended if suits your needs.

[0]: https://watercss.kognise.dev/

Bootswatch is also great if you want a little more styling. (Free bootstrap themes)

Bootstrap is great because it is so ubiquitous. They have page templates you can copy to get the page layout you want and then there are tons of bootstrap examples you can just copy and paste.

Some team members have actually been suspicious that I was adding in React or something since if you use the right components it can look really interactive.

Especially on the corporate VPN with just Flask doing a little bit of templating the latency is very low. A button redirecting to a new page is almost as fast as something all in the client side.

For CSS I see a lot of recommendations for "classless" libraries, which I've never tried, but could be good if you don't need to do much tinkering. For just a little bit more time investment you can get a lot more options with something like Bootstrap. It's pretty easy to learn, has a lot of "drag and drop" style components, and there are tons of templates out there (free and premium). I learned it once many years ago and have been using it for projects ever since.

On the interactivity side it really depends on what your needs are, but if you don't need too many bells and whistles you could probably get by with vanilla Javascript. jQuery is also a good choice for simple applications, as it offers a slightly more intuitive interface to some of the basic JS actions.

All of this being said, if you think you will be spending a lot of time on the frontend, or have complex interactivity needs, it might be worth it to learn a framework. I can recommend Vue as one that is fairly easy to get started with and also scalable to larger applications.

Vue is easier to learn and uses html, css and js. So I feel right at home. Forms are particularly easier and vue dev tools help a lot in debugging.

Also, last year, I used it for an app after a break of 3+ years. I was still able to re-use a lot of prior knowledge (even if it was half forgotten). There was new syntax(comp api) and typescript introduced, but older syntax (options api) worked fine.

mod_perl / PostgreSQL on the back end. HTML::Mason for templates.

Better to pick one of the lightweight frameworks (like Vue, which is super simple to integrate into plain html/css), and save yourself some pain.

If there is a back-end API with a spec (GraphQL or OpenAPIv3) you can generate an Elm client for that which makes API calls type-safe and thus very robust.

How does it persist data? Does it use WebSockets (and thus push from server)?

I'm a bit scared for what that does to state that's shared (instead of that's specific to a user).

Very cool project non the less..

[0]: https://daisyui.com/

It's not drag and drop, but abstracts away all tooling and let's just get to just writing your code. Either in React or in Django templates.

Eventually, if you have any dynamic behavior, you're going to end up rebuilding a lot of what React does for you.

Full disclosure: I'm the creator.

It was a mind-numbing exercise I wouldn't recommend. There are a lot of strong tools out there, but they're often billed as 'general-purpose' when they're most certainly not.

For my project in question I ended up getting frustrated with either issues with SSR-rendered stylesheets or runtime access to browser API's and so on so I just wrote a simple server with Express that just renders static pages using EJS as a view engine.

I keep my client in the same source folder, with a different config for the build that drops the artifact in the public.

Since I personally like TypeScript over not using it, there was some build setup—but just `tsc` for the server code and `parcel` for the client code.

There's little configuration, and I had it up and running with hot reloading of both the server and client code in no time—made me regret my decision to audit so many other options.

TDLR:

The client code I decided to stick with "vanilla" JS via TypeScript using parcel to build and bundle deps.

The CSS is just css, but I might replace that with SASS because it can be a touch easier to organize and namespace things.

FWIW, if I didn't want the TypeScript or dependency bundling (via NPM for fetching the code to host locally), it would be just JS and CSS with server-rendered HTML... if I need something fancy I have the option of plugging in a framework or something later. Starting light feels so good...

You can get pretty far with just HTML and dropping in any one of those CSS frameworks.

Since you’re using Flask, I would just make some endpoints that serve HTML using Jinja2 templates. Depending on what you’re doing, you might not need JavaScript at all. You can trigger backend stuff using HTML forms with form actions. And with a classless CSS library, the form should look nice too.

If for some reason you want to keep the front end totally separate from the back end, a good framework for building web apps is Remix: https://remix.run/ . It makes it easy to build highly performant websites and has nice helpers for data loading and actions. I also like that it keeps client side JavaScript to a minimum, which keeps things simple and makes your website faster.

I use either Quasar, a Vue3 framework (vue it's very easy to learn and quasar does all the heavy lifting, plus has plenty of components), or recently Vite with Tailwind CSS (this allows you to better control the style).

I would recommend to study with an empty Quasar project and build from there.

I personally go for lit[1] and sometimes typescript, and that's it. Typically use open-wc[2] to have a starting template under a minute.

Then I use any of the front-end libraries that add bells and whistles. Vaadin coming on top [3]

I'm a backender, I don't have time to, nor want to learn the specificities of a framework. And I don't want my users to have to pay the cost of many dependencies that I'm not using the full power of.

Add firebase or supabase with netlify for deployment, and I'm done.

[1]http://lit.dev/ [2]https://open-wc.org/ [3]https://vaadin.com/docs/latest/components

I use these because I know them and I don't need to look for code or docs. And I feel the the tooling doesn't get in my way.

I feel that a UI components library is better suited for how I think, than a drag and drop config tool.

Passing props feels simpler than digging into menus to link that JSON to that calendar.

Other tools (except for Tachyons, these are maybe out of scope for a home lab):

- Tachyons [0] is a small (16K-ish) utility class framework.

- DaisyUI [1] is a free and open source component lib for Tailwind.

- WindiCSS [2] is built on Tailwind with some additional features.

- UnoCSS [3], an interesting on-demand atomic CSS engine that supports Tailwind CSS, WindiCSS, Bootstrap, and Tachyons.

[0]: https://tachyons.io/

[1]: https://daisyui.com/

[2]: https://windicss.org/guide/

[3]: https://github.com/unocss/unocss

I wondered if anyone’s working on the following:

Tailwind.js running on a cloudflare worker (so it’s a “CDN”) and calculates the postcss on first request and then caches it.

Wouldn’t that be the best of both worlds?

- Classless minimal CSS framework to make pages pretty without using css

- htmx

Try to avoid doing state management. If you have to do it, use a frontend framework at that point.

https://github.com/dbohdan/classless-css

:-)

[1]: https://kit.svelte.dev/

[2]: https://orbitjs.com/

[3]: https://www.jsonapi.net/

[4]: https://postgrest.org/en/stable/

[5]: https://typeorm.io/

But I think https://unpoly.com/ is nice also and works with any backend.

Tailwind for CSS is great too.

So even though I had bad experience with AngularJS, I still decided to learn Angular instead of React and Vue several years ago.

But if you only have some small projects, TypeScript is not better than JavaScript.

Dart is easy to learn and hasn't as many footguns as JS.

Didn't get that far with that project to see how it works when the code base scales. I would probably pick the same setup for my next greenfield project.

If you want more bells and whistles then bootstrap is fairly easy to understand, allows you to customise your js/css to only include what you are actually using but if you want the full scss experience to easily tweak parts of your design, it is all extra work to setup using gulp/webpack/visual studio code plugins or whatever.

I've been a front and back-end web dev for 20 years. For front-end I almost always use vanilla CSS, vanilla JavaScript, and vanilla HTML by way of the back-end SSR template system.

"mastered"

It‘s the ecosystem around it that is complex and hard to keep up with.

Otherwise you're diluting the meaning of "master".

Budibase.com

https://wave.h2o.ai/docs/getting-started

So we have used it for about 1.5 years for semi critical stuff.

To be honest we had some reliability issue and one where actually wrong requests have been send to the DB. (They fixed it quickly but that left a scar).

So I wouldn't feel comfortable using it for super critical things. But it is absolutely perfect for building MVPs.

For instance, I find vuejs to be way simpler as a non-frontend dev, and that's way overkill for what I'm interpreting the OP to want.

Is react/next complex? Sure. Everything is far more complex than it initially seems, HTML is complex, React is even more complex if for no other reason than it builds on top of HTML.

But websites are also complex. I've found that I can very quickly reach a website complexity where I feel more productive in React than bare HTML; very quickly indeed. And next is really, mostly, just nothing on top of that; its dev tooling, yeah you sometimes have to think about where the state is (server/client) and where the rendering is happen (if you use next export: its just always on the client, done). Experientially, these are small problems; and would potentially be intractable for a website that has attained the complexity to need to solve them, built on bare HTML.

There are a few new techs that I want to try, to see if they can capture the simplicity of HTML, with the good parts of react. Vue is definitely one, but I've been following Astro for a bit and it also seems interesting; granting the ability to just go basic HTML, or bridge into React, Svelte, anything.

[1] https://astro.build/

It is a very powerful tool for sure, but it is so misused in places where it is not needed.

https://retool.com/

This will get you a looong way and you don't even need npm for it.. just copy the minimized files into your source folder.

https://docs.lowdefy.com/introduction

You need Node.js installed so that you have npx, but otherwise you just write your UI in yaml, because why the hell not?

I don't think this is a good toolset in terms of simplicity...

All Python, no need for JavaScript, css, etc. Lots of example templates.