
Framework vs. JavaScript, todo-list example - z3t4
http://www.webtigerteam.com/johan/en/blog/react_vs_vanilla_js.htm
======
tomw1808
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!

~~~
z3t4
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.

~~~
tomw1808
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.

