Framework vs. JavaScript, todo-list example | Hacker News Reader

Framework vs. JavaScript, todo-list example

webtigerteam.com

3 pointsz3t43 comments

I see your rant here, and I say this to all our developers who do not want to go mainstream.

You write your own code, very performance driven, fine with that. That doesn't really work well in a team. Hire new people, tell them "yeah, learn our codebase of 100k lines. No, we don't really have any real documentation. Yeah, there is some sort of coding style here, but its merely performance driven and adapted as we go along."

Compare that to: "Hiring react/angular/famousframework-developer." Measureable knowledge. Streamlined. Replicable HR.

Frameworks have many upsides and some downsides. One of the downsides is mostly performance. For me the upsides outweight the downsides by far - so far. If you have very simple and basic things to write (ToDo List) it doesn't make much sense to use React or full blown Angular.

If you, on the other hand, write apps that require routing, auth, services, etc. you'd be happy to have this level of abstraction to _not_ have the ultimate complexity chaos of writing your own vanilla language.

In addition you get a huge community around all frameworks.

My rant against framework rants!

I understand the HR problem, hiring developers is hard, you want developers to be as replaceable as a bolt in a machinery. But as a developer you learn new things every day and technology changes fast especially in web development. Even if the new dev knows the framework, every team does things different, and that is because different problems requires different solutions.

Basically, you could just take anyone willing to learn and that person would become productive within a month or discover that programming isn't for them.

Although if you want someone able to create new architecture you need someone with experience. Although developers get that experience by actually building stuff.

I see you are trying to make a point here, but I simply think it is not valid and I honestly think you are making a huge mistake by writing vanilla JS for bigger projects.

One thing is the HR standpoint: It is not only the reason new people are easier to find. I don't think they are replicable, but I think it is easier to get them started on projects. It is testable knowledge. It is a terrible idea to introduce "star-based" developers in bigger projects. In practice its one developer who is really good at the things he is doing and the rest of the team is suffering from the non-documented things someone was writing in the name of slightly better performance and less code-overhead.

There are a bazillion frameworks out there. They all have a different purpose for different tasks and aim at different levels of abstraction. Btw React is just a view layer for me, not a whole framework. And I am definitely not a fan of React.

The other thing is popularity and collaboration: It is also a fact that a popular framework incorporates hundreds, often thousands of eyes looking at bugs, improving functionality, enhancing features. How many times do we have to see developers reinventing the wheel because they don't like to work with frameworks? Routing, Authentication/Authorization, Internationalization, (API) connectivity, Security, Dataflow, Scalability, Error handling, Logging... How many times developers figure out that they did things wrong somewhere at the beginning and have to redo everything from scratch after a few months in, just because they did not go the framework- and best-practice-route?

Write your small apps like ToDo lists without frameworks. The ToDo list is just the modern hello world after all. But please, write large production apps on top of frameworks and do not try to re-invent the wheel. Your future colleagues will thank you.

Reply on news.ycombinator.com