Hacker News Reader

Comment by awayto | Hacker News Reader

> We started on Heroku, because in 2012 if you did any Ruby on Rails tutorial that included deploying your app, you ended up with a Heroku account.

Couldn't be more accurate. Heroku and Rails is almost as much of a throwback as Node and Express. You just had to be there. And it was great. Web dev was always a hobby for me as a teen, but then I turned to the rails book as a means of learning a professionally designed system, when I wanted to get serious as a dev. It definitely served me well. Heroku, at the time, offered a very streamlined and accessible way to integrate rails. It was a great time to learn.

View on HN

I sometimes wonder how my career (and life) would've differed if 11 years ago, I had chosen to learn rails instead of laravel because of familiarity with php via Wordpress. From there it went on to C# (windows), JS (frontend), scala/go/node.js backend + JS front end. Lots of JS.

Here being Japan, there were a lot of opportunities to pick up ruby/rails along the way but I stuck on the JS trajectory partially because I didn't want to 'start over' with rails _now_. There were only a few times when not knowing ruby/rails meant I was limited to specific tasks so it was never really career limiting. It did mean that I actively avoided working in ruby shops, for better or worse.

If I had picked rails instead then, would I have transitioned into more of a backend engineer with some frontend duties instead of the reverse?

Not that it matters, but there definitely is a tendency in our industry to 'look down' on frontenders as not real engineers and thus not consider them for leadership positions.

> Not that it matters, but there definitely is a tendency in our industry to 'look down' on frontenders as not real engineers and thus not consider them for leadership positions.

I think that's funny because there some to be a ton of backenders that can't do frontend at all. And then they want to look down on FE when they can't do it themselves? It's not just basic HTML and CSS if you're building a complex app.

I do both (FE & BE) so... I've seen it all and enjoy it all. Not sure one is easier than the other.

I agree. My daily tasks are more FE than BE simply because there are more FE things to do.

I had the same experience with some backend engineers, they constantly looked down on the front-end engineers, ridiculing JavaScript and CSS. And while all those frontend engineers picked up backend languages and became fullstack developers. Those backend engineers couldn't do the most basic frontend things to save their lives.

Meh. FE, BE, system, embedded; they all go deep. A good engineer can learn one or more in any order, but only fools look down on a discipline they don't understand.

To be fair to BE focused folks the Web exploded from being a bad document environment you did ugly hacks and cargo-culting on to make something interesting, to an actual platform at quite a high speed.

And additionally to this during the time it became viable a lots of FE folks still had to continue battling IE6 in their daily lives so online documentation still lagged and had a clear smell of the cargo-culting. Heck even today you see people complaining about Javascript here on HN.

But being left behind today, you gotta blame yourself. Early realtime Google-suggestions using AJAX came already back around 2005 (?) and if you didn't take notice and still missed people were doing decent realtime games by 2010 you were doing your best to live under a rock.

... while quite a few understand the fundamentals of infrastructure they consume, and end up in undesirable places (with major impact on performance, costs, or a combination of both). I fairly recently worked for a few months in a web3/blockchain/NFT/<other buzzwords>/crypto-wallet company, and the fact that I had to explain in ELI5 mode how diff types of databases (and how critical such a choice is), name resolution (a.k.a. DNS), global vs local load balancers of different types work, which measurements and logs to enable, and where, reality of redundancy and recovery times, on prem(NO - you cannot rely on moving VMs over L2 connected DCs!) and in the cloud, etc., to "app" (whatever end) folks, with no understanding how these fundamental services [kept] impact[ing] their clients, was an experience I would certainly not remember too dearly. Even a comprehensive explanation of email client headers reading, to an office full of FE and BE engineers, who failed our security tests (joyfully clicked on anything having a link, in a message, 'cause it was presented as an "API PoC"), was revealing in regards to the missing basics. /rant

Kernel/compiler/OS/formal verification engineer here.

This all seems silly.

It's not too late to go back! Rails and Laravel are still insanely popular and productive for getting work done.

I'm also disappointed that real frontend expertise is not valued as highly as a traditional backend engineer. Think about someone like an Architect. You could say that they are glorified artists (yes, I know they do more than that) and they are highly valued for their artistic input as well as their professional advice; but it's also not unheard of to have an architect solely provide artistic direction and a structural engineer provide support.

> Node and Express. You just had to be there. And it was great.

I agree and Node and Express are still great when going with just js. Node and Koa more now but still great. Socket.io for real-time. All are great for getting things up quickly, simple and shipping things.

For sure. If it ain't broke don't fix it. Node and express are still great. I still use them. Heroku and rails would still be great to this day, too.

Node and Express are definitely winners for my use case.

In context of your comment, what became better than Node and Express?

Reply on news.ycombinator.com