Hacker News Reader

Comment by arcturus17 | Hacker News Reader

Every engineer I've ever talked to or read about going frameworkless says the same thing: we ended up rolling our own. And in most cases, with poor results and quite a bit of hair-pulling.

I like to keep an open-mind about all things engineering, and I agree that some of the complexity of the tooling and frameworks that engineers use daily can be overwhelming; there may be simpler ways to do things, and it's very healthy to question the default of using a framework for everything.

However, such a movement will also be judged stringently based on results. How many relatively large-scale and critical applications will it manage to produce economically, and with developers reporting high levels of happiness?

View on HN

I thought it was obvious that you, except for the most trivial systems, would have to roll some kind of replacement. The advantage of rolling your own would be that it could be a simpler, tighter, framework just for your specific use cases.

Just starting to code without any plan or architectural concerns, of course that will go to shit.

And maybe this points to one of the biggest advantages of frameworks. They force (inexperienced) developers into some kind of structure, where there otherwise would be none.

Personally I would consider any developer that advocates what this "movement" advocates as a developer that should never touch any production code. And this is the reason:

> Every engineer I've ever talked to or read about going frameworkless says the same thing: we ended up rolling our own.

Reading their critiques of frameworks the only thing I could say at every point was "yeah, but not using a framework is even worse".

I think this is nothing more than the "I am very smart" sentiment. Well I'm not smarter than (large, respected) framework designers. Most developers aren't. And it's not just a matter of "learning" but a fact that neither I, nor most other developer will ever be. And why should we be - that's just reinventing the wheel, isn't it? We should focus on our own specific domain challenges.

And yes, it means doing things "the framework way". Because most of the time it IS the better way, even if I can't realize that yet (oh, but I will in a few months).

Yeah I caught myself almost doing something similar when I wanted to implement some internal tools with a React webapp and a backend server that I was going to write in Go because I wanted to learn Go and it seemed like it would have better performance, yada yada.

Then I came to the (obvious) realisation that the other guys have predominantly experience in JS/TS so it would be kind of irresponsible of me to force anyone else who wants to contribute to this now or in the future to have to do it in a new language, rather than the one that we use in our main project. Ended up going with Typescript and I think it was definitely the right choice. For production code you just gotta go with what A) works. B) the rest of the team is familiar with (or has a reasonable chance of learning enough to read/contribute)

Irresponsible or good job security practice?

In theory you should deeply know how the frameworks that qualify for your project. You need to know it to make a good decision wether to take it or not.

You need to know it deeply if you use it, because frameworks usually offer relatively leaky abstractions where you need to know implementation details for the best results.

You need to know i if you roll your own code, so you understand which parts you can leave off and how to do the parts that you also need (if you cannot reuse code you should always try to copy the idea of existing code and adapt it to your problem first).

In my opinion using a framework or not should always be an informed decision.

Reply on news.ycombinator.com