Hacker News Reader

Comment by jaeming | Hacker News Reader

What's funny to me is that whenever I get stuck with docker or docker-compose (or getting our various docker services talking to each other), I'm told by a certain engineer that I ask for help from, "It's really not that complicated.". Then a week later he's asking me for help setting up eslint and vscode auto-correct/format, telling me he's been trying to get it working half the day, emphasizing how terrible JS tooling is. I of course sent him on his way with a working set-up five minutes later.

I guess the difference between us is I'm in JS everyday while he's primarily backend. I've made peace with my tooling as has he. I've also made peace with the fact that my tooling is going to continue to change every few years. From Gulp to Webpack to Parcel to Snowpack and onwards.

View on HN

Am I the only one that doesn't mind the changes? The move from Gulp to Webpack to Rollup to now Snowpack aren't really big heavy architectural upheavals, but I suppose many people haven't written module bundlers from scratch as a learning exercise.

As is the case with much of the front end tooling, once you peel back the curtain, it isn't too terribly complicated. The biggest issue is following the data transformations through the code base because JS being a dynamic language, a lot of magical transformations can happen, but thankfully TS and other compile-to-js languages are helping a lot on that front.

Meanwhile, trying to peel back the layers of k8s, the authors of which seemingly hellbent on bringing Java-esque levels of over-engineered, over-architectured coding styles to a language which ironically supports simplicity and readability over all is a brain melting exercise. I understand Paxos and SAML better than most modern backend cloud tooling codebases. Then like a parent commentor mentioned, throw in AWS services soup in the mix, call services that have a mixture of async and sync calls with a nice mixture of some responses being consistent, some eventually consistent, some probably consistent, throw some observability, and control and data planes and you got a nice recipe for a big bowl of spaghetti you will truly never understand.

But everyone demands these things now, so what are you going to do.

>> once you peel back the curtain, it isn't too terribly complicated

I am not sure if anyone has mentioned it already but in my experience, oftentimes it is not the particular 'complexity' of what is revealed 'once you peel back the curtain', but rather the sheer number of different curtains that must peeled in order to build a 'modern' solution.

My gut impression is also that the challenges are more about aggregate-quirks across the many tools that comprise a solution than it is due to the aggregate-complexity.

This illustrates really nicely how the "Full Stack Developer" is becoming more and more impossible to be. It's not enough to know how to set up a couple of servers with routing and IP blacklisting and load-balancing, you have to build a mountain of microservices with an even bigger mountain of tools.

For frontend it's no longer enough to know HTML, CSS, basic JavaScript and maybe JQuery. It's not enough to render static templates on the server. You have to build a SPA with dynamic bindings and a build pipeline with webpack or whatever else.

It's all just ballooned like crazy and personally I found it incredibly hard to keep up with all of it. So I'm trying to transition into either front or back end, so I'm not trying to learn full stack everything anymore.

I've just come back to standard web architecture these days. Just use Rails, Laravel, or Phoenix. While your compatriots will still be configuring their prettierrc and eslint, you'll have released your first set of features.

Yeah. It's fine for personal projects or small things but good luck convincing a big company that what they really need is 2009 technology nowadays.

Well they are relying on 1995 technology (JavaScript).

This is a weird statement. You are completely ignoring how the JS API in browsers has evolved.

And the parent was calling Phoenix and Laravel, neither of which even existed in 2009, 2009 technology.

Was referring to rails, but sure.

And yes, I was wrong, rails has been around longer than that, it was just a guess.

It's still called Rails but it's a radically different framework now. 2009 was before the big merge with Merb (a then competing framework).

Is Phoenix really that mainstream now?

The person you're answering said nothing about Phoenix being mainstream, but it's mainstream enough for Discord and Brex to build unicorns on its back.

The reason I've been teaching it myself, despite Elixir being a young, niche language is that I believe it's an ideal choice for a solo-founder or small team trying to build an ambitious web app. It's a tool I personally want to have at my disposal.

Discord is a great model: start with a simple Phoenix app, ship way faster than the competition, build out more sophisticated infrastructure with scale, and then finally rewrite core loops as NIFs (natively invoked functions) that are implemented in Rust. They were in a crowded market with extremely well-funded competitors and they still built a considerable lead in product and infrastructure.

Right. I did hear that Elixir and Phoenix works really well for concurrency

I'll bite: What kind of frontend stuff can't be done without HTML, CSS, basic JavaScript and maybe JQuery?

I am not saying those things are insufficient to build good websites and apps.

I am saying it does not matter if they are sufficient on their own. If you want to find professional work as a frontend dev in 2021 you will be expected to learn larger and more complex toolchains.

As a backend dev I have spent a fair bit of time in the last few years fixing shitty outdated frontend stuff. Angular 1, Dojo at present. It would have been so much easier and more maintainable if these apps had been done with server side rending and a bit of JQuery.

I am sure there are plenty of applications in maintenance mode using simpler tech (or possibly not, because the lower complexity means that there are far less bugs?)

Reply on news.ycombinator.com