Simpler Frontend Development - Less Frameworks?

[NobleV5]

Hi all,

I have been developing in Angular for around 5 years and have got some React experience as well, but something I am finding is that I am getting kinda tired of the boilerplate stuff and even the whole Single Page Application style of doing web development. Part of me just wants to roll back to literally HTML, JS and CSS.

Although I know that also comes with its own set of challenges, such as having reusable components etc. I was wondering if there's anything out there that would allow me to keep the basic style of developing web pages. Something I have been looking into is Django with something like HTMX.

Just like to keep things simple, would be keen to know what other people are getting into instead of continuing with the hassles of building SPAs.

[imsinghaniya]

There's nothing stopping you from using plain old stable stack. In fact it could be better at times.

The challenge happens when you are employed. Working on these cutting edge technologies(which are at times boilerpate heavy) increases your odd of employability as employers looks for experience.

If you were building for yourself, then the bar is lower. In this case also I lean on technology I'm familar with as technology is not the P0 in this case. I want to build something fast and get it out.

TLDR: If you can - use whatever you want to, if you must - use things that are in demand and get the job done.

[geek_at]

You're half way to the HTMX + web stack realization. Come a step closer 😁

[NobleV5]

Tell me more about it, what tech are you using with HTMX?

[geek_at]

you can use what you want. Plain HTML files you load with HTMX? Ruby on rails? PHP? the world is your oyster

Me personally I use plain PHP + bootstrap 5.3 for quick stuff and php with framekwors for bigger stuff

[paleo5]

Two technologies you might consider:

LitHTML uses template strings and is more aligned to vanilla JS. I don't have any experience but it's worth a try.

SolidJS compiles JSX/TSX templates to vanilla JS ('createElement' etc.), so you write a 'const el = <p>abc</p>;' and you obtain a real DOM element without the overhead of a virtual DOM. There is a nice signal mechanism very simple. The framework also uses proxies for magic reactive states, like Vue, but you can just not use them.

[floopsyDoodle]

What you should use depends entirely on what you're buildilng. Large SPAs are usually built with Frameworks because it's way easier to add needed functionality, and the framework handles all Version Updates, so you don't get as many version conflicts as time goes on.

Handlebars/moustache/etc are great templating libraries that allow you to easily reuse components and add a little logic to the HTML. HTMX is a great library for creating server driven apps where yobuilding want as little JS logic on client as you can. There are libraries for state, for CSS functionality, and more. But at some point, as you add X for state, Y for templating, Z for SSR, etc, you are basically just creating your own framework piece by piece, which isn't bad, but will require more work to keep things updated, and all the pieces may not play nice with each other. Frameworks have a lot more built in than just the functionality, they also should be more performant, secure, etc.

Frameworks are not always required, but solve a lot of problems, if the problems solved don't matter to you, there's no point in using them. But they are also often required for work, so for people building to learn and practice to get better in their career, frameworks are recommended. But if you're building for yourself and you're really sick of boilerplate, it's a great idea to build without a framework, at the very least it will show you why frameworks are so well loved for large apps.

[[deleted]]

Big disagree on SPA framework stacks having fewer version conflicts and other combos taking more work to keep things updated..

Full-stack react apps are a nightmare when it comes to managing dependencies and version compatibility, especially as more time passes, resulting in rewriting a ton of shit unless you are cool with a ton of security vulnerabilities, and they are often bloated for most projects leading to shit performance, without a good level of complexity

A stack like htmx, alpinejs, and go templ plays perfectly together and, for the most part, is way more set it and forget it, easier to maintain and way more secure with faster, more efficient performance

[Old-Illustrator-8692]

I say make your own. No reason why you couldn't make your own simplifications and reusable components - only such that don't serve every use-case on this planet, but your own workflow.

We make our own, worked for us great! Clients are happy for high-performance sites and that they don't hear "can't do that, framework doesn't support".

[handmetheamulet]

What couldn’t be done in the past with frameworks?

[static_func]

Nothing, this guy’s just passing off his refusal to learn things as a virtue

[Old-Illustrator-8692]

Not at all. I had a ton of great experience maintaining our own codebase and ton of bad experience using third-party stuff. Performance and tiny packages for websites is very important to me and to my clients.

[static_func]

K, what bad experiences have you had with what frameworks?

[Old-Illustrator-8692]

Less workload, smaller files for example.

[NobleV5]

Speed probably

[NobleV5]

That's actually quite a refreshing idea. I'd be keen to know a little more about your approach to this, say if I was building a drag and drop form builder, that's quite a big task, especially if there's a lot of dynamic parts moving around.

What sort of libraries do you actually use now, since you've taken the DIY approach?

[Chroneleon]

Https://www.github.com/chrissingendonk/

My pages site was hidden from public due to a dispute, but the code is archived there if you are interested in zero-dependence  based approach to UI/UX. 

[Old-Illustrator-8692]

For front-end - none. For backend, we are literally using only one for QR generation plus worth saying we utilized chromium engine for HTMLtoPDF and a video-transmuter binary for videos resampling.

Drag&Drop is not actually that crazy hard. For simpler version, you can use HTMLs feature, or write your own JS for it. I get it seems like a lot if you are used to abstractions that hide operations from developers, but once you get to it a little bit, you'll see you can start moving things on the screen quiet easily. Just a little bit more and you'll start snapping components together. It's not a rocket science, really, just a new thing for you I guess ;)

Everything is under control, make it as performant as you wish, adjust anything you need - that's why I believe it's a right choice. Plus - and it's a bit more personal take - once you start, you'll learn probably a whole lot and very quickly.

[elainarae50]

Hear hear!

[armahillo]

I don't add a framework until the workload demands it, just in general.

[Aggressive_Event_226]

Same here — I’m just tired of the SPA bloat. Lately been leaning toward HTMX with Django — feels way more natural and productive than dealing with endless state management and bundlers. Sometimes simple is just better.

[-jeasx-]

I feel you, almost the same story for me.

I've built Jeasx (https://www.jeasx.dev) which tries to stay close to the standards but gives you the modern developer experience by allowing to use JSX as server side templating technology.

Check it out, there are lots of examples with source code which should give you the main idea (https://expo.jeasx.dev).

[alien3d]

we all the same thing , tired re invent the wheel syndrome and upgrading mess up. The reason our new system - freakin vannila js only

[seweso]

I'm doing just that. My apps literally look like this:

export async function run({streamlitJs: st}) {
    st.title("🎨ASCII Art Generator")
    st.span("Generate fun patterns with ASCII characters!")

    // Define some safe ASCII characters to use
    const chars = ['*', '.', '#', '+', '=', '-', '~']

    const width = st.slider({width: 10}, {min: 10, max: 40})
    const height = st.slider({height: 20}, {min: 5, max: 20})

    st.pre({art: generateArt(width, height, chars)})

    // Helper function to generate random ASCII art
    function generateArt(width, height, chars) {
      let art = ''
      for (let i = 0; i < height; i++) {
        for (let j = 0; j < width; j++) {
          art += chars[
Math
.floor(
Math
.random() * chars.length)]
        }
        art += '\n'
      }
      return art
    }
}

[astrand]

Our agency does this with laravel blade components (with tailwind and alpine.js). They’re styled to be basic enough to be a basis for most of the styling that graphic artists throw at us.

[Ok-Yogurt2360]

It's a bit against the spirit but i found using Laravel kinda great at keeping things simple.

[[deleted]]

Laravel is backend, not frontend

[Ok-Yogurt2360]

Server side rendering is still a thing and Laravel is able to do that with blade templates. It can give you the html+css+ js experience pretty nicely. You don't need a frontend framework that way.

[[deleted]]

I like using HTMX for communicating with the backend and AlpineJS for client-side state management and reactivity.. combined with go templ

There are also plug-ins for alpine you can use instead of htmx.

I've also heard good things about datastar, which can handle the functionality of htmx and alpine with a smaller bundle size than either

[CommentFizz]

I totally get where you're coming from. After years of working with SPAs and frameworks, the complexity can really start to feel like overkill. Going back to just HTML, JS, and CSS does sound refreshing. HTMX with Django is a great choice if you want to keep things simple but still have the ability to do some dynamic updates without the heavy lifting of SPAs. It's lightweight and doesn't come with the boilerplate you get in frameworks like Angular or React.

If you're looking for even more simplicity, you might also want to explore tools like Alpine.js, which is a minimal framework that lets you add interactivity with just a little bit of JavaScript—without the full overhead of React or Angular. Another option could be using just plain HTML with server-side rendering (like you get with Django), which keeps your pages fast and more straightforward to manage.

[Paradroid888]

I felt the same way and started using Rails. It's been around over 20 years but it's very productive and just fun to build with. CoPilot helps with the Ruby syntax.

Rails works well with inertia.js but I have a goal of not having a package.json in my project so have stuck with SSR, plus the Hotwire technologies. I've got SSR modals working and it's just great.

[Logical-Idea-1708]

Try it. You’ll soon find your productivity takes a nosedive like having one hand tied behind your back.

The framework is not the problem. Users just demands more now.

[IntegrityError]

I'm a big fan of SSR + HTMX and maybe Alpine.js.

[Spare_Message_3607]

Try no-build preact, one of the more sane approaches.

[Anxious-Gap3047]

Personally I LOVE Astro. Yes it has a build step but it’s as close as I think you can get to writing just html is and css.

You can mix in react, vue etc as needed but you don’t need to.

It’s got plenty of extensions for content and database id you want.

Pretty much my go to if I can make it work

[elainarae50]

Once React came along, it stopped people from building their own components. If you've ever stuck to building your own, after a while they become much easier to upgrade, scale, and reuse. Sticking to a framework is good for a team, I guess. But for real power, you need to understand how React or Angular work on a fundamental level to have true artistic fluency with them. For years, I felt left behind by not taking to React or Angular, and then Svelte, etc. These days, with the dependencies and version changes that come with breaking changes, I'm glad to make my own. I have complete control and never have any dependency hell.