Comment by MyFirstSass | Hacker News Reader

Comment by MyFirstSass | Hacker News Reader

As a 15+ years webdev my recent projects in the front-end are almost pure "vanilla JS" (Just JS) + Html, and CSS with only Petite Vue / Alpine on top.

I find the modern Vue, React etc. stacks absolutely insufferably complex and prone to breaking in 1000 places each time you upgrade some package, or change som random thing in the already stupidly complex "Tooling/Build" chains people are setting up by default.

And it's because no one, not even experts in the field seem to understand 5% the stuff that is contained in these monster codebases.

I found myself using 90% of my time on this setup and tooling, and i'm pretty sure most devs do not need these.

I'm wondering if i can somehow pivot into making only these elegant products for customers. Have anyone done this as a solo dev, contracting or in an agency? Maybe make a "frameworkless" agency? Will hopefully save my sanity and my career.

I find the code much easier to read, the codebase is way smaller, and the app's can do the same thing. You can always pull a library here and there if needed.

Also coding and putting together a project is suddenly fun again, and it seems most languages; CSS, JS etc. are now so mature you can do almost anything with them without the bloat.

And as a bonus you actually have time to understand the different underlying concepts like back in the day instead of using weeks in the issue trackers and playing tetris with dependencies.

Although I agree that many sites could get away without the bloat of client side JavaScript frameworks, sometimes the complexity is truly justified and it enables you to deliver a better product. Complex dashboards with data intensive interactions and explorations are so much easier with React or something similar

I do agree that advanced dashboards may still require some dependencies like texteditors, routing etc and i would have agreed in say Vue 2. Vue 3 is too complex just as React in my opinion.

For example if you just create a naming scheme or prefix vars in a scope i don't get why datasharing in an app between stuff right next to each other have become so cumbersome these days. You have to import and export absolutely everything in some microservice-like declarative way that is overkill in 99% of cases with code that looks way too complex and disallows binding unless you create complex subscription patterns.

Just let me emit, just let me share through the Window object between teams, everyone will save years of reading manuals and reinvent absolutely everything. If you name your data properly it will make sense. Especially when proxy's and listeners are now available in JS as it is.

Agree with you here. Also need the frameworks to scale work out to a team.

But that is what subdomains are for, dashboard.example.com will deal with all that over head, but forcing the marketing-friedly splash page on example.com to be in React is overkill.

React and JSX are still my preferred method for writing HTML - so much better than templating and there's no reason you can't have the output be a static site for something like a marketing friendly splash page. Now is React a great fit for that? Probably not, but it let's me use a consistent set of tools.

12 yr FE dev here, and I’m a big fan of static site again, when possible. Who needs SPA when your round trip cost requires no JS eval or boot time? I wrote this library that is intended for somewhat tech savvy folks to easily generate static sites using AWS: https://github.com/dclowd9901/posse

I agree: building sites like that brings the fun back to web development in a big way.

I would really love to know where you put imba.io in your tools evaluation.

It's the only one I can grok that allows me to work at high levels and just plain js when I need to. I hate that it has any external dependency, but I'm just blazingly fast building with it that I justify the 50kb extra.

What are you using server side?

I've been looking outside the JS world for an alternative for doing full stack dev and Laravel Livewire seems like an amazing alternative for like 80-90% of use cases. Something like Alpine, vanilla, or even Lit for the more sophisticated interactions.

I've used both Laravel and Python Flask. Both are very mature, fast and relatively simple of you strip them down. Though to be honest i'd like to go even more barebones on the backend and have experimented with pure PHP (which is also quite mature these days) + a few symphony - packages but isn't totally there yet.

I’ve been super impressed with Livewire on several small projects.

I’ve been sold these same sorts of promises before (yeah you write backend code and we put some glue in and then everything works like it’s running in browser) and usually it’s a case of a very narrow happy path and indescribable horror once you’ve fallen off and have to wade through or work around the “magic”. I did not go into Livewire with high hopes.

Everything I tried to do with it basically just worked. Coming from a background where I’ve worked with PHP/Laravel/Blade quite a bit already, it was really easy to pick up.

For stuff that Livewire isn’t necessarily the right fit for, alpine fills the gap perfectly and integrates well with Livewire.

My Livewire component has one PHP class that contains, basically, the “controller” that exposes the BE actions for the component and a blade template that contains the “view”, including any basic FE interactivity inline by way of alpine. I use Tailwind and Tailwind UI pretty heavily, so all my styling is inline as well. I’ve found this pretty simple and easy to follow, reason about, and maintain.

I’m pretty sure it’s the most fun I’ve had working on FE code in a long time. It’s definitely the most productive I’ve been. It takes no time to stand something up.

Thanks for confirming my suspicions :)

you would need to add alpine.js or something equivalent though. there is nothing wrong with a few core libraries that are long-lived, thoroughly debugged and understood etc.

You are totally right, i actually forgot that Petite-Vue is the only core library i'm using atm, also tried Alpine and they are great.

And their tiny scopes are actually nice dogmas to play around, i haven't yet experienced them not being enough, and when they aren't you hack together some stuff to extend them, and that actually makes coding fun again. It's like the demoscene, it's way more fun to code with some restrictions and limitations you have to be creative to solve, instead of setting up some dependency/folder hell.

Optimize, minimise, make more elegant, make more readable, that is where the fun is!

Reply on news.ycombinator.com