|
|
|
|
|
by mbrock
3977 days ago
|
|
Well, one thing about JavaScript is that it's a very flexible language in itself without any additions. It's similar to something like Scheme. And good Schemers can accomplish a lot of cool stuff with the proverbial Notepad. I'd rather hire someone with no clue about Gulp or npm but who understands all of JavaScript and knows how to do stuff in the simplest possible way, than someone who's mastered all of these tools and can't do anything without a framework. Forgive my bluntness. I disagree with the premise that sophistication requires complexity. I prefer to see it the other way around. Maybe I'm growing older. When I see a complex build tool replaced with three lines of bash, that makes me happy. And when I notice someone has given a bit of thought to making a simple solution based on fundamental needs instead of installing all kinds of stuff, like the commenter who mentioned downloading 200 MB of code just to initialize a project... |
|
Amen to that! I think what I'm trying to say, and I suspect that we agree, is that there's the right tool for a job. Setting up a project to use 200mb of over-complicated npm modules and tools probably signifies the work of an inexperienced craftsman. Likewise, a non-trivial project built entirely from home-grown native Javascript may well run into complexity problems too as it re-implements features for which simple, well-tested and widely-used open source modules are available. Our desire for simplicity will lead us variously towards either of these extremes, and our experience tells us how to tread. We want our projects to be "simple", but that doesn't mean they're going to be "easy". The barrier to entry for frontend development is increasing in terms of developer capability, but that doesn't mean complexity is increasing, or that well architected projects that use modern tooling aren't simple.