>These types of posts are popping up more and more these days. I like to call them "JavaScript luddite" posts: posts that worship single-digit kb apps with zero dependencies as universally good ideas.
So something like "the UNIX way". And that's wrong because?
>Abstraction is an important part of what we do as SW engineers.
Which is why we should be able to handle it and craft it properly, and not outsource it to some ready-made one-size-fits-all framework.
There are other outlets for code reuse, and they are called libraries.
>"Small size" -- cry me a river. Yes, byte size is important but it's not more important than code reuse and all the benefits that come with it (security, dev speed, support etc).
Code reuse? Ever heard of libraries?
In fact adopting a framework makes pretty sure that it will be hard to reuse both best-of-breed third party libraries (because frameworks favor their built-in stuff) and it also makes it pretty sure that your code will not be reusable outside of it, e.g when you move to a better framework. E.g. all those Ember objects will be tied to Embder, and the logic will be tied to Ember logic of doing things.
>By the way, the Retina image on the blog post was 46kb over the wire which is bigger than all the JS in his app.
Beside the point, for one his app is not his blog, and second, a one-page style app can function while some image is loading, but not while the main JS files are.
>"Special needs" -- moot's engineering challenges were not unique, they just didn't like the trendy frameworks.
Moots might not have been, but your startups better be, else you're doing commodity work churning out stuff. In which case, yes, use a framework.
So something like "the UNIX way". And that's wrong because?
>Abstraction is an important part of what we do as SW engineers.
Which is why we should be able to handle it and craft it properly, and not outsource it to some ready-made one-size-fits-all framework.
There are other outlets for code reuse, and they are called libraries.
>"Small size" -- cry me a river. Yes, byte size is important but it's not more important than code reuse and all the benefits that come with it (security, dev speed, support etc).
Code reuse? Ever heard of libraries?
In fact adopting a framework makes pretty sure that it will be hard to reuse both best-of-breed third party libraries (because frameworks favor their built-in stuff) and it also makes it pretty sure that your code will not be reusable outside of it, e.g when you move to a better framework. E.g. all those Ember objects will be tied to Embder, and the logic will be tied to Ember logic of doing things.
>By the way, the Retina image on the blog post was 46kb over the wire which is bigger than all the JS in his app.
Beside the point, for one his app is not his blog, and second, a one-page style app can function while some image is loading, but not while the main JS files are.
>"Special needs" -- moot's engineering challenges were not unique, they just didn't like the trendy frameworks.
Moots might not have been, but your startups better be, else you're doing commodity work churning out stuff. In which case, yes, use a framework.