Ask HN: What's is your go to toolset for simple front end development?
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.
294 comments
[ 3.4 ms ] story [ 248 ms ] thread[0]: https://daisyui.com/
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".
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
?
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.
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.
[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
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.
* HTMX (formerly "Intercooler") for interactive (Ajax) functionality: https://htmx.org/
- Bootswatch
- Some custom scss to pop it up
- Some basic jQuery for everything dynamic
Simple yet super effective
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.
1. https://htmx.org
2. https://simplecss.org
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.
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.
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/
[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/
[0] https://reactjs.org/docs/create-a-new-react-app.html#create-...
And with NextJS it makes react state management very scalable and rarely need redux at all IMO.
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.
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
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.
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
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.
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...