Classifying your code is something you might do when it's finished. But while most code bases are constantly changing, classes does not make any sense! They will just make it harder to re-factor the code, and you will end up with a bunch of unused code just because you decided to classify early on instead of just prototyping.
Import is another concept that will eventually make your code base unable to manage. You'll end up with imports everywhere, with a weird spaghetti, where it would be much better to use the modular pattern of breaking up the code in separate reusable modules.
As to classes, there are some places where they make sense, but for the most part, your code really represents workflows against objects (not necessarily classes) as your code/flow really doesn't care if it's a duck as long as it quack()'s.
As to the second part of your comment regarding imports... import really isn't any different than require, and in that vein is easy enough to reason against, and work through. For the most part, your discrete modules should be hierarchical in nature, and exposed as collections/wrappers via directory/index structures... this will make it easier to avoid spaghetti.
Comments
Classifying your code is something you might do when it's finished. But while most code bases are constantly changing, classes does not make any sense! They will just make it harder to re-factor the code, and you will end up with a bunch of unused code just because you decided to classify early on instead of just prototyping.
Import is another concept that will eventually make your code base unable to manage. You'll end up with imports everywhere, with a weird spaghetti, where it would be much better to use the modular pattern of breaking up the code in separate reusable modules.
As to classes, there are some places where they make sense, but for the most part, your code really represents workflows against objects (not necessarily classes) as your code/flow really doesn't care if it's a duck as long as it quack()'s.
As to the second part of your comment regarding imports... import really isn't any different than require, and in that vein is easy enough to reason against, and work through. For the most part, your discrete modules should be hierarchical in nature, and exposed as collections/wrappers via directory/index structures... this will make it easier to avoid spaghetti.