Hacker News Reader

Comment by Crabber | Hacker News Reader

I think a lot of programmers in the industry just follow trends, they don't really understand the benefits and drawbacks of the technology they are using.

I have coworkers who host personal projects for their own use and put them in docker, set up CI pipelines, host them on a cloud service, use an enterprise level database on the backend. One of my coworkers made a completely static portfolio website with a single page and used react.

I don't mean this in a judgemental way, people are free to use whatever they like. But it does sadden me that instead of seeing tools and processes as having certain benefits and certain overheads it's now just "this is the tool we use for everything", and therefore "everything now has this overhead". Where the overhead is performance, time, complexity.

View on HN

I understand your viewpoint because but also have you considered that your approach adds nothing to the builder?

I don't mean this in a judgemental way. In your scenario, I spend learning 50 different technologies that I will never use because they are not hired for. Whereas the colleague makes 50 different projects, gets comfortable with the technology and maybe hits an interesting edge case or two to talk about at their next interview, if they are lucky.

I am saying this as someone, who has tried to think about complexity and what not in my projects. But it turns out that I get a lot more mileage from practicing deployment with k3s than know what Dokku and Kamal do and how to deploy the app directly as a process.

> In your scenario, I spend learning 50 different technologies that I will never use because they are not hired for

I'm actually saying the opposite of this. To learn react you also need to know html, css and javascript, so I am saying if you need to make a static website that is just a single page you may as well just write it in HTML. I am saying you should use less technology.

Similarly to learn Docker you need to know bash so you already have the skills to just skip over docker and deploy your app directly by running bash commands on a linux server.

The "50 different technologies" is how I see the flavour-of-the-month cloud platforms that take something that's relatively simple (copying code to a server and running a command to start it) and turning it into a proprietary cloud platform you now have to learn. Whereas you could have just learnt how to deploy software to a linux server instead and have a skill that was valuable 20 years ago, is still valuable, and will still be the way software is fundamentally run in 20 years time as well I am sure. Meanwhile I have no idea what Dokku and Kamal even are - I'm sure they won't last as long as linux and bash have.

Dokku maintainer here.

I'm sure bash will outlast me. I do hope to work on Dokku for another 10/20/40 years, but if there's a better project out there, I'd be happy to help users migrate and bow out of the deployment space.

I maintain Dokku for the folks that don't want to build and maintain a bespoke deployment process around docker, and the k3s implementation uses helm at its core, so users can eject when Dokku has run its course. I think there is value in that - maybe not for everyone, but at least for folks busy with building product on a budget.

That said, I'm happy to see folks continue to build new tools and iterate on ideas in this space. Definitely cool to see how everyone improves on stuff I - and others - been working on for the last two decades.

I think the gp is saying the exact opposite of what you gave an example for, and in line with what you are saying i.e. less technology.

one more thing is you tried both kamal and dokku, and then made a deliberate choice of sticking to k3s because suits you the best rather than making a mindless descision about using k3s, which most people do!

> One of my coworkers made a completely static portfolio website with a single page and used react.

People love hating on react, but I mean this is pretty common. Raw is fine, but even in a "static" thing, you'll eventually go "ok now I want to reuse some text here.." Or have some common elements with x things shared. So I'm gonna have to write some hacky imperative JS? Or messy CSS? And what starts as static very easily becomes slightly dynamic. I hate overengineering, so if React were hard to setup or deploy I'd agree (eg Kube), but the cost-benefit of React makes it worth it in most cases for me

Yeah pretty much this. I tend to use Astro but I think your point still stands.

I wanted to make a basic online agenda in a few different formats for a Toastmasters club and though I could have used raw html and css to build it, but each agenda had slightly different layout that would have been a lot of copy pasting in html and lots of room for error.

With astro and react islands it was fairly simple to implement.

I had a similar problem and used 11ty to build static html from templates and markdown files. Works great and keeps you close to the metal

That sounds nifty, I'll check it out!

Reply on news.ycombinator.com