Ask HN: What's is your go to toolset for simple front end development? | Hacker News Reader

Ask HN: What's is your go to toolset for simple front end development?

304 pointsanakaine288 comments

I'm quite firmly in back end development. Often times I find myself wanting to have a simple front end to which I can attach some new experiments for home brew coding such as Flask.

I'd not mind if my front end looked a little bit nice, but don't want to spend forever learning, hand coding, and trouble shooting html, css, JavaScript.

What's in your toolkit for some simple front end drag and drop style block building that gives you enough of a template to get started? I've seen the odd one posted on HN over the years, but never had the foresight to save one.

Given its home lab style stuff I don't really want to dive into the likes of Webflow, Canva, etc.

View on HN

Ignore any recommendation of React, TypeScript, Vite, or Tailwind. Here are some recommendations that don't require NPM/Node.

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/

https://picocss.com/ is another option for a "classless" CSS

I haven't given CSSBed or basscss a good try yet, but I do like tailwind enough to find it worth a build system. It doesn't require NPM/Node if you don't already use that; it has a standalone cli now[1].

HTMX has been a joy to work with.

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

While Mithril is interesting unless you are resume-building I'd avoid anything React-like until you are a small team and just go Vanilla JS with events, it can go a long way if you are a solo dev, especially if you have a backend experience and can write clear and simple code.

Definitely agree with that. Vanilla JS has gotten very powerful in the last 10 years.

Can I ask a concrete question: say someone wants to render a table with data coming via an Ajax call to a JSON API. How should they do that with the tools you're suggesting? Use the native JS DOM API to synthesize table rows? (Just in case tone of voice doesn't come across, if that's the solution great, I'm not implicitly criticizing it in advance).

Yes, use Fetch API to retrieve the resources, and pass the resulting data to a function that uses the DOM APIs to create the table element + children. If you're not attaching event handlers to the elements, and if the data is properly sanitized, you can also use a combination of `innerHTML` + HTML written in template strings to dynamically create the markup.

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.

Thanks, that's really helpful to me. In particular, I wanted to know whether creating a table dynamically from Ajax data was sufficient reason to start using Preact/Mithril, and you made it clear that in your opinion it's not.

Why doesn't that scale? What would the optimizations be?

Don't know if this is directly related but the last time I fetched 9,000 elements to a select list, my browser went HRNGHHHH (on an M1 Macbook Pro). (No, 9,000 elements in a select list was not intentional.)

Because if you wanted to make changes to the table, and your rendering mechanism is rewriting to innerHTML, it's going to nuke all the elements and create new ones (even those that don't need to be recreated).

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.

Have any good recommendations on resources for learning vanilla js events?

Best recommendations.

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/

Not only privacy, but also reliability in my experience. If you add in a CDN you now have a point of failure you have no control over that (Murphy's Law) fails at the most inopportune time. In all web frameworks it's pretty trivial to serve up static files with a future expiry date.

> a simple front end to which I can attach some new experiments for home brew coding

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!

> Pandering to niche neuroses about privacy

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.

I've been using htmx since the intercooler days, but I'm of the opinion that just using Next.js and treating React like simple HTML is much easier for starters.

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.

Unfortunately, "easier" does not always equal "simpler". Next.js/CRA is "easier" because it hides a lot of the complexity away from you. In my opinion, ignoring how it all works under the hood and just blindly accepting tools/clis because "it works" sets you up for confusion down the road. I've met several JS developers who don't know that JSX gets transformed to JavaScript function calls after a build step -- they just assume it's part of how browsers work at this point. And that is mindblowing to me.

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've met several JS developers who don't know that JSX gets transformed to JavaScript function calls after a build step -- they just assume it's part of how browsers work at this point. And that is mindblowing to me.

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.

failure of their mentors? To an early point, but beyond that everyone who considers themselves a professional needs to sit down with a book or three and understand stuff. 'mentors' is a small excuse IMO.

I'm currently mentoring some junior devs and perhaps I was thinking about them when answering. You are absolutely correct on that.

Ha! I've met web developers that didn't know that you could do form posts without a JSON API

This is a valid criticism of SSR and the complex mental model it requires to implement effectively, even with Next.js. You need a firm understanding of the HTTP request lifecycle and the serialization boundary. For a novice programmer starting with frontend dev, I would not recommend starting with Next for this reason (create-react-app would be better).

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.

As a non-js developer I found Alpine lacking. In the examples they use something like await axios get to get new content. I have no idea what any of those mean or why they have to there in that order with that syntax.

HTMX makes this incredibly simple:

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

What does "hx-get" do? Does it replace the HTML from that url? Why is it on a div, does it happen on load or does it wait for an event? It's a study on its own:

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.

Yeah... I'm about as far to the other side of this as you can get.

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.

Maybe that's enough internet for you today? No one is "fucking" making you do anything. Pick the tooling you like, ignore the ones you don't like.

These frontend tooling threads devolve quickly.

I wrote an internal tools framework on top of htmx with a desire to make things easier for backend contributors, but ran into exactly this problem - even htmx isn't quite simple. What I would have likely done next is try to create jinja abstractions around htmx

Ignore any recommendation telling you to blanket ignore technologies without reason

The reason is to avoid npm/node. And that's absolutely right -- I'm a backend engineer, and I've done Vue projects with npm, and npm is fantastic -- the quality and care that has gone into it is obvious; even the screen output is beautiful (compared e.g. to the mess that JVM developers make, who think of a shell as some weird thing that someone might need to use if their IDE is broken).

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.

Point taken; I admit I wrote that as a sort of frustration and reaction to the abundance of comments telling a newb at front-end developer to just take the deep dive and start installing a bunch of NPM packages / CLI tools. In my opinion, those tools hide amazing layers of complexity that become a problem as soon as you need to eject. I think any beginner at front-end development should realistically start by getting used to the bread 'n butter of HTML/CSS/Vanilla JS, things the browser already understands. Only once you start feeling the limitation of those tools should you start including libraries, and then maybe a package manager and view layer.

I think it just depends what you want to build. Once your UI reaches a certain level of complexity, the benefits of various tools begin to outweigh the cost.

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.

> Once your UI reaches a certain level of complexity, the benefits of various tools begin to outweigh the cost.

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.

But the earlier comment was saying to avoid NPM/Next/React because of the challenges that arise when you want to eject and add complexity. However, not using NPM/Next/React also comes with challenges when you want to add complexity.

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.

Do you really suggest https://htmx.org/? That thing has bold questions, like

> 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.

HTMX relies solely on client-side behavior, but it definitely supports falling back on server-side behavior:

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.

To be fair though, unless you use only backend frameworks plus CSS and JS for simple client only things, this will be the case.

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

htmx is a javascript library, I don't really see why you'd think it should work after turning off javascript in the browser.

Ignore advice that doesn't give a rationale. <-- Like that

Don't be afraid of Tailwind. It does not require NPM/Node. Utility CSS can be very helpful. If it works for you, tailwindcss is a great tool. By all means, give Basscss, etc a look as well.

Point taken. As mentioned in another 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.

> Ignore any recommendation of React, TypeScript, Vite, or Tailwind.

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

The Play CDN is the funky script I was referring to. It's not plain compiled CSS, it's a rather large (~100kb) JavaScript file that dynamically adds Tailwind classes to your document as you use them. It's also only intended for development purposes. I would recommend the CLI to OP over that, but my point was that it's largely unneeded for his use-case and more likely to cause confusion and more toolchain bloat for what are one-man homelab hobby projects.

I recently stood up my own website[1] and decided to write my own CSS, HTML, and JS in VS Code with the Live Server extension. It was exactly what I needed! It’s as if we’ve already been given all the tools we need for a nice, simple website.

[1] https://willswire.com/

Great thread all around! Have been hearing raves about "htmx" and finally clicked the above link. Chagrined to find the tight DOM element coupling is done via data-set string attributes. Mapping to data store keys. Kind of the inevitable no-framework pattern I just assumed everyone was implementing ;)

I looked through all the available styles from cssbed and quite a few did not have any styling for links that have already been clicked on. This seems weird to me. Why would you get rid of this styling? Sure, purple sticks out, but it's useful information when navigating a webpage (particularly when I'm trying to click every link in the list of styles to see what they all look like!).

If you need any kind of interactivity on the frontend, but are more comfortable with the backend, I would suggest looking at Phoenix LiveView [0] or a similar server-rendered HTML technology for your language of your choice [1].

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

A single logical app sounds great. There is great freedom and power in simplicity for small concerns.

Seconding this. I've been using LiveView in production for ~18 months now, on a couple of projects.

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

You or your company hiring, by any chance. I've been using that exact stack for a few years now, and Elixir+LV jobs are hard to come by :P.

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 are betting big on moving to liveview and are hiring.

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

people@polkadotskysoftware.com

How stable is it?

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.

Check the second link above. There are frameworks for this pattern in most languages, many with many years of effort into them. I can personally recommend Vaadin.

The web-components backed vaadin or vaadin flow (JSF-like, all-Java)?

After having learned & used all the major frontend frameworks (starting from jquery, backbone, ... react, svelte) I am now firmly in the camp of LiveView. No more "REST APIs"/fetch calls, SSR by default, no javascript alltogether, very simple programming model once you "get" it.

It's very cool. I'm actually working on a web framework called Bolts in the Rust ecosystem that will offer LiveView-like functionality, born from my hatred of modern js frameworks.

The irony is you will have to code a lot of javascript to make this ;)

eh as long as it's _myyyy_ javascript I don't mind at all

I'm in the same camp, I've slowly "regressed" backwards from overcomplicated SPA's back to server side rendering. When LiveView hit and I was already using Phoenix it was just perfect. It's a slight embelishment on top of multi-page server rendered pages which gives all the benefits I need and nothing more.

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.

How do you deal with more complex/dynamic forms? As someone who learnt frontend mostly in React I've always struggled wrapping my head around how you would do that with server-side rendering.

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

LiveView can handle that pretty well, you can setup a click or validation handler for your live view / component. It then hits the handler function on the backend and you can have the component updated in place. Since it only sends the diffs down it's pretty efficient on the round trip, at least not something to worry about compared to the hundreds of api calls most SPA's will make.

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.

Its actually recommended with Liveview for pure client side stuff (hiding form elements, etc.) to do that in the client. There are hooks to do such things. Granted I've only built admin-y tools that are pure liveview but did hear/read there are options for client side JS.

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.

This is really cool and makes me want to learn Elixir.

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.

I came across something that is somewhere in the middle. Maybe a happy medium? It's a Python library called IDOM [0]. Best way I can explain it is that it is server-side bindings for React, where state and diffs are passed back and forth for you via web sockets. You implement your components in Python with a React-like API and IDOM builds the equivalent React components for you on the client-side and then wires up your server-side state handlers. It is also web framework agnostic, works with all the most popular ASGI web frameworks in Python.

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

there's also justpy, uses vue and is closer to liveview in that it generates all the frontend code for you. https://justpy.io/

I've been involved in two projects that use LiveView and both of them have similar path.

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.

Thanks for writing up your experience. I’ve been wondering how well liveview works when interacting with the page with variable latency. I tried to search some sites made with liveview in the past, but couldnt find any apart from some official examples.

I just read that you didn't want to troubleshoot html, css and js, so my goto toolkit for simple UIs might not fit your bill, but hear me out :)

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".

I do this for internal science stuff at my work. The scientists love it. Simple and fast.

I recently took a similar approach for a couple of simple websites (https://abyteofcoding.com/survey/ and https://crosspromote.io), and found that surprisingly people don't really care that much. It's still very annoying to deal with responsive stuff (changing design based on screen size) though.

Your site is broken for crosspromote - things are too wide for the viewport leading to things being clipped and so unreadable (at least on mobile).

Ugh, dammit. Thanks for catching that.

A small bit of CSS will clean this up no problem :)

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

this

It would only take a tiny amount CSS to make it usable.

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

https://motherfuckingwebsite.com/

http://bettermotherfuckingwebsite.com/

Ugh, way to overdo it... #444 is WAY too low contrast.

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?

https://evenbettermotherfucking.website/

https://thebestmotherfucking.website

I pretty much do this as well. The only thing I do different is, when I need to present it to someone, I will drop in a minimalist css library like PureCSS or Milligram.

There's a ton of very simple "minimalist" or "classless" or "markdown" [0] CSS files that you can apply to plain HTML to get modest good looks versus browser default styles these days. No changes to your markup, just use that raw HTML you are already comfortable with and LINK tag in a single CSS file.

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.

Bang on. We have internal tools like that and they just work - something which dumps a list of switches and information for example, trivial to find what's plugged in etc. The interface doesn't get in the way. Dynamic pages are a matter of "print" stuck in the middle of the php.

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.

Man, given all the comments suggesting frameworks that will require you to do html/css/js it seems like no one has really read your post.

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

Have you tried budibase

That looks pretty cool, I'll have to check it out :)

Now this is what the OP was looking for, and it so happens that I'm going to look into these too! Thanks!

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!

Indeed. OP should have asked for "easy" or "simple to use" because "simple" means something else entirely.

Assembly language is simple.

I'm not sure about ToolJet, but I know it's possible to use external auth systems with AppSmith.

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.

Thank you. At work we've been having a look at these. Decent for in house stuff.

https://svelte.dev/tutorial/basics - easy to get started with but really powerful for complex stuff too

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.

I don't consider Svelte a simple toolset because it can't be published statically

If you are in a larger scale SEO project this does blazing fast static generation with Svelte: https://github.com/Elderjs/elderjs

Can attest to this. We used it to build https://findenergy.com which has over 15k pages and a TON of data.

I think you are incorrect here. Sveltekit comes with a number of adapters designed to ship either a SSR site or a static SPA.

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.

Unless I'm misunderstanding you, Svelte can absolutely be published statically. If you leverage SvelteKit and the SSR it offers, then yes you need to deploy a server, but regular Svelte builds a statically deployable bundle just like React, Vue, or any other big UI lib/framework

I think they meant that svelte cannot be used without a build step.

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

It can quite easily with https://primo.so

Have you even used Svelte yourself?

Since when did frontend require building or packaging?

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

Why is that bad?

over complex mes

Our front end devs were drawing diagrams of react components with arrows everywhere. All the app is doing are some fairly basic forms with a bit of validation. NPM install to get the thing running on a development machine, and it seems to download half of the internet. What an absolute shitshow "full stack" development is these days.

Preact [0] + htm [1]

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.

The drag and drop is more a rapid build tool than anything else. I'm, frankly, not likely to put all the love an effort in to the front end that I will the back end for small projects.

No build pipeline is very helpful, actually.

if you really don't want a build pipeline, then in js land your options are limited to alpine and vue. there may be more, but these two are more popular ones

preact is great: https://gist.github.com/developit/3631edd9033df8df5975786b19...

Ah no NPM! Vanilla JS with no build step. This is very interesting. Thanks.

See code example here: https://gist.github.com/developit/3631edd9033df8df5975786b19...

I used Lit for web components, with no build steps. I loaded it from unpkg [0]; but there are probably more production-ready CDNs in existence. It worked pretty well, especially since CSS styles can also be encapsulated inside of the shadow DOM of the components.

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

I'm thinking of trying ts + deno at some point since deno has built-in ts support.

It won't help with the browser-side part of the story though :-)

There's Deno Fresh now (https://fresh.deno.dev/) which looks like a pretty interesting new web framework so far.

Came here to say preact is pretty nice and the no build pipeline thing is wonderful.

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!

+1. We use preact + htm and no build approach to build Moochee (https://app.moochee.us/tryout). Super simple to use yet very powerful!

Glad to see this. I used Preact and htm to build a small, events-flying-everywhere app that helped me get my current job, which I love. https://github.com/spaceaardvark/react-control-chaos

Highly recommend.

I started off like you on the backend development. When I had to build small webapps, I looked at the various frameworks and then settled on KnockoutJS. KnockoutJS is a very small and simple JS library. This is several years ago and at that time I didn't even know Javascript. The reason I say that is because even for a JS newbie, the KnockoutJS library was simple to use. (I read somewhere that MS Azure used KnockoutJS for their frontend dashboards in their earlier version. Not sure if they still do.)

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.

Great advice. Thank you. What have you been doing to help with page layouts, if anything?

I mostly use Bootstrap for prototypes. For most of my use cases, I just use card styled divs. There is basic support for different types of container divs in bootstrap. There's card-group, card-deck and even card-columns. Never had to go beyond these for my requirements. Forms are a breeze and come out looking great, right out of the box.

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.

My own advice, on the other hand, is to use Tailwind. Tailwind is far more flexible than Bootstrap and it's super easy to understand. If you pair it with the Intellisense plugin, it's a total game changer. I've been writing CSS for over a decade and I'll never go back to normal CSS after trying it.

I was a huge fan of Knockout for many years. Durandal was neat at the time, too, as a very simple "SPA framework" on top of just Knockout.

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".)

One of the issues I had with KnockoutJS is that it's pretty easy to leak memory and quite easy to use a lot of CPU. Maybe we were "using KnockoutJS wrong" (entirely possible!), but we had several independent teams working on different products and they all suffered from these problems. Eventually we switched most things to VueJS and the performance difference was remarkable.

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.

Sveltekit with typescript and adapter-static.

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.

I'm not familiar with svelte[kit]; if half your files need a lot of JS, do you have to choose between manually adding it to all those files or adding it to all files including the ones that don't need it?

Svelte compiles so the bundle is very minimal. https://svelte.dev

I use AlpineJS for reactivity. Along with JS Template literals[1], I can reach quite close to the ergonomics of having react like re-usable functional components without bringing in the whole complexity of react ecosystem. Works quite well for smallish projects.

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...

Not drag and drop style block building, but:

1. https://htmx.org

2. https://simplecss.org

I prefer https://picocss.com/. Default styling just seems nicer.

Thanks didn't know that one.

I've been doing this for so long that I've gained years of experience in React, Angular, and Vue. You said simple front-end development and there's nothing easier than Vue, hands down. The syntax is so easy and segregated perfectly; no JSX wild-west ugliness or fucking with a minefield of observable and subscriber pipe functions. It's easy to get started, encourages clean code, and very readable. It boggles my mind how there's so few VueJS jobs available despite the advantage. I think part of it is just developer laziness in picking up yet another library, which I totally understand. Unfortunately I'm stuck in React and Angular land 90% of the time and hate it.

I’ve used React, Vue, Knockout, and just plain vanilla JS, and Vue is what I reach for now for personal projects. React is great if it’s already set up but I don’t want to waste any time with a build system for personal projects. With Vue I just add a link to a CDN, copy paste the hello world code in and I’m off to the races.

Honestly? React [0], Tailwind [1] and Vite [2]. Using Vite so setup the environment and tailwind components for css I have never been able to create front end faster than now. It feels like a super power.

[0] https://reactjs.org/

[1] https://tailwindcss.com/

[2] https://vitejs.dev/

OP mentioned they are backend developers-- and you are asking them to do a whole frontend setup? Your answer is a bit like "Oh just recompile the Linux kernel if you want feature X, its so easy LOL"

Thanks for taking charge on this one. You've stated my feelings when it comes to doing all the css, javascript and html

It’s really not a huge hurdle. You have to install a few tools. If you’re a backend developer, this shouldn’t be too challenging. And what you get in return is:

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

Some might disagree with these arguments on the account of smaller projects not necessarily "needing" all of that functionality, but personally I think that you do bring up some nice points!

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.

Bad analogy. It's more akin to installing postgres and rails for backend development, which is not an unfair ask.

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.

I totally agree. This is a super stack. The productivity it enables is insane. I like to use Chakra instead of Tailwind, but same principle.

React is one tool that a primary backend developer should stay away from.

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

> I'm quite firmly in back end development.

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.

You are probably thinking of Vaadin[1] for Java web apps.

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

* Bootstrap 5 for CSS and customized styling: https://getbootstrap.com/

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

How simple are we talking about when you say "simple frontend development"?

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.

For home-lab/internal UIs, you can go a long way with the auto-generated model-admin pages from Django. If you just need CRUD and actions triggered on a list of models, you can typically avoid any UI work and just define a few Admin classes, and if you need to make custom forms it's quite easy using Django's templating machinery to override individual pages.

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.

React with create-react-app [0] and Netlify for deployment, github as git repo. This way you can have a hello world app that has a full CI pipeline in ~30 mins.

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

If your domain is already on Route53, you can replace Netlify with AWS Amplify and save another 10 mins…

And install React-Router, Redux, set TypeScript

Redux is absolutely not a requirement for "simple" front-end dev. There are many simpler, less boilerplate-y, and more modern ways to manage state in a React application. See https://blog.logrocket.com/modern-guide-react-state-patterns...

Even with up to medium complexities a simple useContext or React.Context is enough.

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

And if you want a drag'n'drop GUI for this workflow, there's React Studio (macOS only):

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.

Wish I had a mac sometimes.

Use vite instead of CRA these days!

Take a look at Pinegrow [0] (I'm the author). It is a desktop app that lets you visually work with standard HTML & CSS files and supports frameworks such as Bootstrap, Tailwind CSS or just plain old CSS. There are also more advanced features, for example live SASS compilation, components, interactions and even exporting WordPress themes and blocks.

[0] https://pinegrow.com

Tried Pinegrow(and similar UI tools), didnt like it. They expect you to still know all the low level details, at which point you might as well write straigth css

Any plan to compile this to webassembly and make it run in the browser? Webflow is killing it. I had no idea there were other options.

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.

Pinegrow is a web app (mostly vanilla JS, HTML and CSS) packaged with NWJS [0] into a desktop app that runs on Mac, Windows and Linux.

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/

One single piece of CSS instantly improves the look of plain html pages:

  body {font-family:sans-serif;}

Beyond that, all other CSS is optional imho.

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

No thanks, I very much prefer my serif fonts. If you prefer sans-serif for plain html pages, why don't you change the default font in your own browser instead of trying to convince everyone to force their preference onto everyone else? That way we can all have the kind of fonts we prefer...

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.

Please look at Svelte.

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

The syntax is also very pleasant.

Svelte should also be considered before React/Vue/Angular, because it's a generation ahead of all of them -- in many ways. The recommendations for React in here are no bueno unless you're just looking for the framework with the most job postings.

I often use plain HTML and a classless CSS (e.g. Water.css[0]) for personal projects.

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/

This should be the top answer. Simple Css libraries (I use MVP.css) that just work with no hassle is the way to go

This looks nice. Nothing wrong with this

I really like the ultra simple approach of MVP.css (https://andybrewer.github.io/mvp/). It looks better than no styling at all and doesn't require me to get into Bootstrap. Only minimal html tags needed. Perfect for small side projects.

Bootstrap is 100% the answer. Pulling in everything from a CDN is the easiest route.

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.

Yeah, going to the Bootstrap examples, “view page source”, and seeing how the elements are put together is what made simple front-ends for internal tools so easy for me. Lots of examples and minimal pages to start from.

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.

It's hard to know exactly what you mean by "simple", but I'm fairly sure you want to avoid any frameworks, as those tend to have a learning curve, even for the easiest ones. Same goes for build tools like Webpack, which I still have trouble with after years of use.

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.

I use vuejs with create-vue for scaffolding. And then, google my way through.

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.

You may want to give Quasar a try then. It is Vue with batteries included.

Pyramid for backend. HTML+css for the front end. Often just bootstrap. Vuejs applied to very specific places that need to be interactive, but without any build/bundling/whatever - just referencing a single minified file.

Seconded on these recommendations (except Pyramid which I have not used). Vuejs just applied to certain places as needed with no build/bundle/npm packages and bootstrap and that's it.

i would even recommend https://deformdemo.pylonsproject.org/ ;) i used it for internal tools all the time

This thread is amazing. Every other comment mentions a new tool I've never heard of. And I thought building APIs is hard. Ignorance is bliss

Yeah, even as a frontend dev myself... half of these I haven't heard of. Frontend dev tools desperately needs some consolidation. Everyone seems to be trying to solve the exact same problems over and over again.

I personally love how wild west the javascript world is. I don't think any of the tools listed in the thread are the same, so it would be hard to consolidate all of them. The only reason why there's all these different libraries is because people have different preferences, and want libraries/frameworks that fit their preferences.

HTML, plain CSS, vanilla JavaScript to fetch data / interactivity when required.

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

IMO, the problem with vanilla JS on anything other than trivial pages is you end up having to implement a bunch of common patterns (such as interpolation and form binding) and before long you’ve got what is effectively a private framework that you’ve kludged together in an ad hoc way while simultaneously trying not to be distracted from solving your actual problem. But because it’s come about in this organic, unfocussed way, it will have a bunch of bugs and caveats, and it will be a bit of a mess. And don’t even get me started on browser engine differences.

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.

I prefer my own mess over someone else’s mess :)

I do fully agree with this normally! But Vue and a few others are so lightweight and well tested that I feel like I’m being crazy if I reimplement them. Of course YMMV, I do a lot more backend than frontend.

I made http://divjoy.com, which lets you assemble blocks into a multi-page web app and then export as a React/Node codebase. Works best if you want the backend in Node, but you can swap out for your own API.

Elm.

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.

Cosigned. And if the backend is yet to be written then put the whole thing on Lamdera.

I'm trying to understand Lamdera, but I dont really get it.

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

I think that's exactly how it works. The whole backend model persists for every user. Your backend model is what would be your DB state in another stack.

So persistence is just text files (that's what I got from scanning through the source).

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..

secound, espeicaly together with elm street for generating code from Haskell

I like to skip the backend all together and write the Elm app directly to something like Hasura (GraphQL with authorization on top of PG).

https://tailwindui.com/ - lots of pre-made templates using tailwind css. Some are free, but the more advanced ones require payment.

This looks pretty useful. I'll have to do a bit of digging and see how hard they are to put together.

Also see DaisyUI [0], a free/open source component library for Tailwind.

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

This.

What is the proper way to use it? Is it a collection of code snippets to copy/paste into our projects?

HTML + CSS + JS, if really needed

Since you like Python and want a turnkey React/Python integration with a Django backend, check out https://www.reactivated.io.

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.

I've run the gamut recently trying to find one that was suitable for a project of mine—nothing crazy, just a server-rendered front end for a CMS/other data source.

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...

Definitely agree with other answers that you should look into classless CSS frameworks. You can see a list of popular options here: https://www.designinspiration.info/classless-css-frameworks/

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.

htmx (https://htmx.org/) in backend templates (flask would work) and tailwindcss (https://tailwindcss.com/) and you can get very far without touching css and Javascript. Html writing would still be needed.

I am in a similar situation as you (with the addition that I am an amateur dev).

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.

It's not purely drag and drop, but not complex either

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

NextJS + MaterialUI + TypeScript + Vercel

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.

For those recommending Tailwind, it's huge if you're using it from the CDN (318K uncompressed).

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

Regarding Tailwind, shouldn’t you always run postcss in production?

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?

Yes, always purge / treeshake and then tailwind will have a significantly smaller footprint.

- Jinja templating as standalone or in Flask.

- 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

sveltekit [1], orbit.js [2], JsonApiDotNet [3] and postgrest [4], additionally docker-compose, sometimes typeorm[5] + express. Good for prototyping and small home projects :-) Production readiness is questionable for the first 2 mentions...

:-)

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

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

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

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

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

I like https://tallstack.dev/ a lot.

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

Tailwind for CSS is great too.

I am the developer of xlwings, so this is heavily biased. Anyhow, ever since I’ve added support for Google Sheets, I am building all internal tools with it. No HTML/JS/CSS required whatsoever and everybody knows how to interact with a spreadsheet UI. There are a few sample projects on GitHub, e.g., https://github.com/xlwings/xlwings-googlesheets-pandas-plots (they use FastAPI, but it’s trivial to adapt for Flask). On top, Google Sheets let you easily authorize the user on the backend, so you can give certain users read-only access to a database, as an example.

Really tired to find all kinds of modules for different function.

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.

Simple? vanilla html, css and js.

I'm doing mosly machine learning/backend. For a PoC I needed a frontend, I choose Flutter web. The tooling works great and is unlikely to change everything week like in the JS world.

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

My last experiment was with bulma css and vanilla javascript (typescript) with web components for components that needed custom/complex interactions. Nice thing with this approach is that you can "just" render the web components with the backend's template engine as if those were your normal html tags. Because of typescript, a build step was required. For this I used esbuild (esbuild itself didn't do the type checking so I ran tsc with --noEmit and --watch next to it).

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.

Back end dev here as well. Useful thread. Thanks.

It depends a bit. If you want a real "micro" framework so it is super fast loading, then that will narrow down your options (I looked at purecss which is really small) but then it is likely to lack the more powerful controls you get with something like bootstrap.

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.

You really want to use drag and drop as a dev?

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.

React.js is the gateway drug for you to dig into frontend development. I myself mastered it in 2 weeks as a backend engineer. There's no simple way, there's only the first step. Good luck.

> mastered it in 2 weeks as a backend engineer

"mastered"

Why not? React is a simple concept / library.

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

You can't be a master in the abstract. I think it's reasonable to say that a React master needs to be familiar with a great deal of the React ecosystem.

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

What tutorial would you recommend to learn React fast, for someone who already knows JS well?

Read the Thinking in React.js article in reactj.org. Understand the why first before jumping right in the code.

The official documentation.

Budibase is perfect for this use case. It is open source and super simple to build an app with. It's used at Apple, Google, Space X and other incredible orgs (power of open source)

Budibase.com

Thanks for recommending this!

Not drag and drop but for a 100% python solution h2o wave is pretty cool. It has a focus on data-based dashboards but can be used to pretty easily create very good looking frontends for all sorts of applications. And you never have to leave python (whether that's a pro or a con is up for debate :))

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

I've been using Next.js for years to deploy static sites deployed to Github pages as well as experiments. It is quite simple and keeps my code organized.

Being no frontend dev myself, the rare times I have to do a webpage I go for jquery and bootstrap. May sound old-fashioned, and perhaps it is, but it works.

I reach for Vue + Vuetify (a Material Design UI component library) to get things going quickly. Vue is extremely easy to learn and can be incorporated with a script tag if you prefer. Vuetify faithfully implements almost the entire Material Web Components spec, so you have everything you need to build polished, functional web apps. It’s also got very nice documentation.

I am using Retool for that. Pretty happy. It is true drag and drop. Looks decent and there has been nothing I couldn't build with it.

Cool, can you build production stuff / products or is it focused on personal projects?

People use it for production. It is thought for internal use but you can also make it external.

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.

May be unpopular, but: nextjs + react (+ bringing in typescript later if it starts feeling like types would be valuable).

1) React/jsx is legitimately nice for templating. Lets say I have a list of ten things I need to display; I know these things at build-time, its not dynamic like from an API or whatever. These ten things are reasonably complex; div+spans+borders+etc. React is all about components; it makes that easy, write once and copy-paste one line. There are ways to get similar behavior in plain HTML+CSS, but it tends to be leveraging web technologies that I'm not super familiar with (web components?).

2) React has an EXTREMELY good developer community. Everything you could possibly want, there's a component out there, and its an npm i away. In comparison, the more pure HTML/CSS world is more fragmented and less developed.

3) `next export`. When people think nextjs, they think SSR. Don't bother with it. Just `next export`. I leverage next for the local dev tooling, the runtime can take care of itself.

4) Or; I want server-side functionality. You can build backend-only API routes, in Next, and its actually awesome. Of course, you have to give up the static export, but its the first full stack JS "framework" where I've started thinking, this actually works & feels productive. Usually I leverage that for really simple stuff; server-side OAuth logins for hacky dashboards, things like that.

For deployment: netlify is nice, or I'll use digitalocean apps if its not a static export.

React is so far from "simple" it's not funny, then to throw nextjs in there too...

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.

I like react, and next. I use it at work and it pays my bills. But I 100% agree with you, the complexity is mind blowing. And I'm pretty scared of all the upcoming server components, etc...

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

Well, I never used the word "simple", mostly intentionally. Except to describe next's backend API stuff, which is pretty simple (just a node server at the end of the day).

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/

Sure, but the ask was explicitly "simple"

https://github.com/vladocar/femtoJS https://github.com/vladocar/Basic.css

Backend: Django / Celery - Front-end: TailwindCSS, daisyUI, HTMX, Hyperscript - Devops: VS Code dev containers than I can duplicate easily between projects to keep configuration.

I've written about just this subject as part of a series on my toolkit for building tiny apps. I use Material UI... React bindings for Material: https://link.medium.com/qPechTPYsrb

I used svelte for ( fabform . io )

Retool

https://retool.com/

Just use some simple CSS framework that you like/are used to plus maybe jquery if you need more than vanilla javascript.

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.

Check out:

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?

Took a few seconds to load a purely text-based page on my browser, with several roundtrip requests.

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

Development is simple. What happens next is another story altogether.

Blade (Laravel), Tailwind and, unless I need complex state management, jQuery.

Check out shuffle.dev, they have generators and components for the most popular frameworks. A great way to learn is to create the same pages with different libraries and observe the similarities and differences.

Whatever JEE, Spring and ASP.NET support for SSR with components and vanilaJS.

Does AppSmith count? It's drag and drop and has themes. Easy to use with micro services. https://www.appsmith.com/

For real homebrew stuff that no one else is going to see, Flask with plain HTML. If someone else might actually see it, django and vue with one of the quickstart css things (Bootstrap, tailwind).

Related discussion from 2021 https://news.ycombinator.com/item?id=29311761

I usually just pull in fomantic ui (fork of semantic ui). It has all the components (and variants) I need, it’s easy to use and the components look much nicer than other ui frameworks.

Check out streamlit: https://streamlit.io/

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

+1 for Svelte/SvelteKit. Svelte's DX feels like you are just using JS, CSS, and HTML - but you get all the new hottness of the other framework packages as you need it.

Check out Imba [https://imba.io/] It makes really simple to do what you're asking for.

Just use Bootstrap and axios library for making API requests to your REST API endpoints. You can find lots of free/paid templates and themes for Bootstrap.

Last time I did this, I bought a bootstrap template and just used django. Worked great, but you aren't gonna win friends on the internet talking about it.

Would Flutter be an option? You'd have to learn Dart but if you're familiar with JS its not hard to pick up. Run everywhere too, desktop, mobile, web.

Not sure that's what you're looking for, but my product www.jigdev.com definitely allows you to make simple UIs to interact with backend services

i recommend taking a boilerplate that is based on fast compiler (esbuild for example) and has tailwind set up. then add alpinejs for basic interactions. I think this stack has lowest barrier of entry for backend Devs, while having still a lot of room for growth. if you don't know tailwind, skip that part, it doesn't matter much, you can use whatever bootstrap-like library with great results.

https://github.com/Shopify/draggable

- Bootstrap

- Bootswatch

- Some custom scss to pop it up

- Some basic jQuery for everything dynamic

Simple yet super effective

For drag and drop try https://devdojo.com/tails

Wisej is just god-sent.

It has all I need, and lets me focus on business logic, rather than plumbing.

It is all one simple layer, no front-end/back-end.

This actually looks alright. I got burned with .Net Razor pages in a previous professional project, so am a little wary of .net based setups. The advertising material looks good tho.

This looks interesting for businesses but at $1,000 per year and up it's a bit too expensive for casual projects.

In a similar position, I just went with 100% static Next.js, no over complicated server rendering, just basic React

I use Wordpress for drag and drop. More complex stuff Ruby on Rails with bootstrap.

JavaScript, HTML, CSS, PHP.

changes all the time. i like to learn new stuff so i always have a go at whatever shows up on HN.

if i had to pick, i'm a fan of nuxt. spinup is quick and easy and i'm a vuejs guy so its not that hard.

if you don't need a web application, pyqt can get you a desktop app up and running very quickly. it takes a little bit to understand the signal/slot design, but it's not too bad

I still use Adobe Dreamweaver for basic fronted development.

Vite + Vue.js 2 + Scss

I always use Vue. It's simple, flexible and powerful.

how about: html + css + js. The interactivity part can be done through preact + htm with JSX like syntax? Don’t need tools like webpack, vite, etc.

Took me a moment to realize that frontend here means HTML+js, not the HTTP server (that is the first server that handles user's request, therefore being the frontend to everything else).

the irony of this thread is beautiful.

I don't think that's irony. Just shows you that the state of web-dev has not settled to a global minimum. Lots of local minima that different people prefer for different reasons.

I use Html + bootstrap + htmx + django

i just use bootstrap and jquery. no compilation or building. they have served me well for years

SwiftUI, HTMX

- Haskell (backend)

- SwiftUI (iOS/macOS)

- Rust (backend)

- VueJS

- Tailwind

- Netlify

Phoenix Framework

pnpm + Vite + Svelte + TypeScript + UnoCSS

Sveltekit

htmx or unpoly

dronahq

TailwindUI ?

Another recommended this, seems good.

AngularJS 1.8

Reply on news.ycombinator.com