What's an indie-friendly frontend framework?
I want to learn to build better and more dynamic UIs. I moved away from my old boring Django and Jinja2 setup and tried out Django+Vue.... it's dreadful 😅
I see the benefit of these frameworks, they break down complex UIs, give them states... but there are so many hoops to hop through and changes to be made, it just extends development time by so much
I am thinking about just using Alpine now, but wanted to ask here first: what are indiehacker-friendly UI frameworks? Something that allows you to build fast, own the whole stack, no need for all sorts of idioms and structure if you don't need it...
Trending on Indie Hackers
Well, you said it almost : avoid UI framework at all cost. VueJS and friends are fantastic for big teams that ship big products. Try to render everything from the server, and if you can't, redesign the UI so that it is server-based. You will save the most precious asset : time. Sprinkle jQuery or AlpineJS in very last resort. The value of your product do not lie in perfect , top-notch UX. Correct, sufficient design can be achieved with server-rendered page.
I think it really depends on what the product does! For some it's really important to have a very interactive UI that can respond in real time to server sent events for example. Using a JS framework will be a big help. For others the value is more in the info that is presented and server side rendering is sufficient.
Phoenix LiveView is/can be even more efficient than SPA architecture, so this is not generally true.
I want to agree, but then I look at what @csallen built (Indie Hackers) using ELM and it's hard to compete with server rendered html. There are so many nice touches Indie Hackers UI has it's really impressive (especially to me as a backend developer)
Phoenix Liveview (https://www.phoenixframework.org/blog/build-a-real-time-twitter-clone-in-15-minutes-with-live-view-and-phoenix-1-5) and Laravel Livewire (https://laravel-livewire.com/) show promise that backend design may be possible.
@hwatkins Didn’t heard about Livewire before. It seems great! Thank you !
@csallen built a beautiful product, but the core value of it is not the UI, I would argue it started with quality content/interviews/newsletter and only after a while developed into this forum. Like @bdavidxyz said, focus on the value that your product provides and avoid time distractions like complicated UI.
I think it's just a matter of knowledge.
I know React.js deeply and this allows me to create MVPs at a crazy pace.
Like literally, once I coded fully functional and good looking job board in 2 days.
Every framework will seem bloated and pointless if you don't know it well.
My advice - choose ONE tech stack and use it always, no matter what is the product. After a year or two you will be coding at unprecedented pace.
And no, vanilla JS is DEFINITELY not faster to develop. It seems faster for someone who does not know the framework well, but it's 100% not.
I wanted to let the smoke clear here a bit so I could leave my message with less interference from haters and ankle-biters. :)
In short: I would strongly urge you towards using a server-side rendered framework with updates delivered live over the wire. My preferred stack is Rails + StimulusReflex, and using StimulusJS for any client-side "sprinkles" that you require and Turbolinks to make everything crazy fast. (I think AlpineJS is an elaborate troll, or possibly an AI from the future is fucking with us. Burn it with fire.)
You might have noticed all of the (well-deserved) hype around the HEY email system that came out last week. All of the hardcore React/Vue types have been losing their minds because their choice of tooling has become so central to their identity that the idea you could build something that runs that quickly and smoothly with server-rendered tech suddenly makes them realize that the incredibly complex thing they've put all of their eggs into has just been revealed for exactly what it is: a masochistic, labor-intensive Rube Goldberg machine that can only truly be loved by the Accounts Receivable departments of consulting companies. The idea that it's faster to build things like HEY in React isn't just a misconception, it's a fraud.
The secret sauce of HEY and sites like it is that there simply is no concept of client state. If you stop and think about it, all of the complexity and the most stressful aspects of modern web development are trying to keep clients in sync with the server in a secure, speedy way. You end up having to bend over backwards compiling JSON into UIs and figuring out how to bundle everything... on HEY, when you click a button, that event is captured and sent to the server. The server transforms whatever data is appropriate and then serves up the minimum amount of markup over websockets or an Ajax long poll to update the client; the result is a 7kb JS bundle that doesn't make any attempt to render anything, it just inserts HTML.
Now, full disclosure: I've been working in Rails for 16 years and I am on the StimulusReflex core team. I spend a lot of energy showing anyone who will pay attention that Stimulus (the JS library) seems simple but is ludicrously powerful. It was created by the same guy that made Prototype, which was the original inspiration for jQuery. He's an incredibly smart fellow.
Rails in particular gets written off as old or boring, but in reality it is the fastest and most enjoyable way to get an MVP off the ground. All of the other frameworks - Django, Laravel, Express, Phoenix - are all implementations of Rails in their host languages. My opinion is that you should get your water from the mountain source.
You don't need UI frameworks unless you're already Facebook. You should look into StimulusReflex, but all of this stands even if you're a Python developer. (There's a Python version based on SR called SockPuppet!)
https://docs.stimulusreflex.com
https://stimulusjs.org
https://www.youtube.com/watch?v=F5hA79vKE_E
https://www.youtube.com/watch?v=SWEts0rlezA&t=202
Good luck. Let me know if you have any questions.
@leastbad what do you find wrong with alpineJS?
That's a really important question, and it's inspired me to write a post about it.
It comes down to a combination of objective truths, lived experience and believing that there is a demonstrably better way. Top it all off with "we deserve better".
Long before anyone was talking about SPAs (let's say 2004-2009) there was a lot of churn in the standards communities around best paths forward. Would we embrace XHTML and the "semantic web" or would we move towards HTML5? Should we use classes on elements to convey data as well as style, or should we use custom DOM attributes for data? Would you believe that I was once called horrible names for suggesting that we should fearlessly use attributes because while validators might not like them, every browser in use didn't care.
Lo and behold, data- attributes were introduced into the standard and suddenly all of the people who would literally come up to me at conferences and scream in my face that classes were the answer suddenly were writing posts about how great attributes were.
I'm sure you also remember how people who used inline onclick etc event handlers and inline style tags were "morons". You might as well use tables to hold your blinking gifs inside of your frames.
On the server side of things, there was another war being fought: how much logic do you push into the template? On one extreme was Cold Fusion, which pioneered tag attributes instructing the interpreter to loop over collections. On the other side you had... everyone else, where your templates could include server-side processing directives, allowing you to split your logic from your markup. Short version: splitting out logic won, although the idea of x-loop attributes lived on in tools like Vue and now Alpine.
Today, we can take much better tools for granted. We have real options for both server-rendered and client-rendered frameworks that have learned important lessons from history. We have incredible libraries like Stimulus which allow us to use data-attributes to imbue functionality into our elements. For example, I have a library called stimulus-zoom coming out soon. If you have an img tag and put data-controller="zoom" on it, when your users click on it, it will lightbox that image. It's simple and literally that easy. People can add Stimulus controllers to their elements and build up functionality using a compositional style. It's easy to read, easy to extend.
That brings me to the final point: Alpine doesn't just forgive spaghetti code; it creates a culture that actively celebrates terrible coding practices. This is because there is no emphasis put on creating opinionated conventions around how to do common things. This means that if you ask N Alpine developers to add simple functionality to a page, you will end up with N wildly different approaches, all full of subtle bugs. This is amplified by the fact that if this takes off, over time the percentage of people using these scripts will be copying and pasting them from Stack Overflow and W3Schools. They will cargo cult and not be able to fix problems that emerge when beginners jam scripts from multiple sources which they do not properly understand together.
This means that people who are inhering markup with embedded Alpine script not only have to learn Alpine, but they also have to mentally parse the logic now woven into the page, which could have come from questionable sources and likely has lots of bugs and idiosyncratic coding conventions. All of this without any notion of package versioning (I can fix a bug in my stimulus-zoom controller and everyone can just yarn install to get the latest). If there's a bug in an Alpine directive in 150 places on your site, that means you have to manually correct 150 elements and each time you're potentially introducing errors due to the inherent boredom of fixing 150 almost-but-not-quite-identical instances of a dumb bug.
For all of these reasons and more that I have forgotten, Alpine is not the correct path forward for the web. Stimulus is a better choice in every meaningful way.
A nitpick, but Django was built around the same time as Rails and was not a reimplementation of it. I think it just happened to be open-sourced a year or so later by the company which developed it but the two frameworks are of the same vintage.
I was actively working in both Ruby and Python at the time when Rails came out, and it was a quantum leap when the first beta releases started to hit in late summer of 2004. I have no doubt that the Django team had started building a web framework at the same time Basecamp was still under development. However, it's disingenuous to claim that the Django team didn't immediately start hoovering feature ideas into their vision, because EVERYONE did. Rails was the talk of the town. There could not have been more excitement in the OSS community for anything than there was for Rails when it was released, and of course Jacob and co were paying close attention.
That's not throwing shade.
I'm glad that they did. It's great for more people to have access to powerful innovations.
I second Stimulus.js. But Alpine or Unpoly are good choices too if they fit what you are trying to do.
Alpine is a great choice if you're planning to leave your job because you discover they are subtly poisoning your food in the common fridge, like, every day.
I built the website for Everbase in Next.js and I've had a mixed experience. Next is probably the best framework to build a hybrid website (React + server-side rendering). But I experienced tons of issues because of this approach, some of them rather difficult to figure out. The complexity of the whole stack is insane, there are so many parts that you have to glue together. Next takes care of most of it, except sometimes you do need to configure webpack/babel/etc, and now you also have to account for Next.js quirks.
This doesn't mean I wouldn't pick a stack like that again, but I wish we'd one day just redo the whole web stack from scratch. Until then, I'll probably keep using React, because it's still the best we've got.
Django and Vue actually work very nicely together. The great thing about Vue as opposed to, say, React, is that it doesn't force you to do anything you don't want to. Vue is a great "container" for organizing your code that would otherwise be written as unstructued jQuery code or something like that.
I'm all for doing server-side rendering of templates, but these sayd it's very hard to avoid writing some JS front end code. I really urge you to look at Vue, it's very lightweight and I think you will appreciate its benefits.
Hi. Are you using Django+Vue through rest or as templating?
For now using it with the basic templates. I can see how later down the road I'll want to switch to REST, but for now templates + Vue give me all the power I need.
Why was Django + Vue so bad for you. Where you using it calling rest from Vue? Or integrating Vue into Django views itself (by changing delimeter)? I ask because I am considering going this route..
I guess you've just asked one of the most frequent questions and there's a lot of discussion around it. Personally, I tend to follow one rule - use tools which you're most productive and comfortable with. The MVP phase for the most part is not tech dependent, BUT - if you're absolutely tired with your current stack and want to try smth new, I would suggest mastering the latest tech there is - and that is Svelte (Sapper for Svelte SSR). It's quick to pickup, omits a lot of boilerplate and delivers small bundles (with correct usage). Good luck!
Try Flutter...It's the first front end framework that felt right to me. You can make mobile as well as web apps. Web is still relatively new, but they are making alot of progress.
For me the biggest barrier to getting a side project done is momentum: time + motivation to work on something and get it out there and in front of real users. Therefore I look to what gets the most done in the shortest time, before I lose interest, or life gets in the way and the opportunity or focus is not there any more.
I have the skill set to build an SPA: I'm good with Django, and pretty OK with Vue. But if I'm serious about building something I'll avoid building an SPA unless the idea absolutely requires it - and there are very few ideas for web applications that really need to be an SPA. The reason is that I end up juggling two codebases - a backend and frontend - and that implies more work in testing, integration, deployment and so on. More rabbit holes and bugs and issues when my focus should be on building the damn thing and - hopefully not too far in the future - growing the user base and keeping them happy. A large team of specialists working on a monthly salary doesn't have that problem, they can afford to build a complex SPA with lots of moving parts. As a single developer I know I won't have the capacity for that, so I have to be conservative in how I choose my tech stack.
Otherwise - others in this thread have mentioned Stimulus and Turbolinks - I wholly recommend these even if you are not working with Rails, they are very easy to add to other projects and greatly improve UX at little cost. I'm also having a lot of fun working with Tailwind - there's a bit of a learning curve but it's replaced Bootstrap as my default go-to CSS framework.
My take is:
I had no trouble pairing React with Phoenix, because Phoenix default setup gives you instant hot reloading that just works (tm). I never liked using single React components in Rails. The integration/hot reloading is not there. Everything felt slow and clunky.
With Rails I prefer using Turbolinks and Stimulus.js which are specifically designed with Rails in mind, so it's a pair made in heaven. To leverage them in different stacks might need taking some of their design decisions in mind.
Apart from Alpine.js I recommend looking into Unpoly and Stimulus.js. I would use React for more complex needs (but hopefully not).
Above all else, choose what you know :).
Hey I'm in almost the exact same spot as you! Just starting build a new project with Django and have been looking for a JS counterpart. I've decided upon Alpine too and vanilla JS for API calls. It's working well so far.
But it depends on what kind of site you're building.
If you don't NEED a Django server I can highly recommend Firebase. By using it you can go full JS and not worry about managing the server. It has a generous free tier, it's easy to setup, and deployment is a simple file upload.
I built this site with it using pure React. The DB, storage, CDN, analytics, etc is all Firebase. Developing locally is quite nice too. The webpack dev server auto reloads and makes it quick to launch things.
Happy to share my webpack setup you go that route.
Be wary of any overly-opinionated comments. It ultimately just depends on how you like to work.
I personally enjoy using Next.js, React, and Vercel. Super easy to build with, inexpensive to get started with, lots of libraries and documentation, etc. It is a serverless paradigm, though, so if you prefer backend development / working with servers obviously this is not for you.
I'd recommend just giving a bunch of things a try. Nothing beats having first-hand experience! You'll eventually figure out a great workflow for yourself.
Some UI libraries you might want to check out:
This comment was deleted 5 years ago.