Not using a JS Framework? Congratulations, you've just built your own ad hoc JS Framework.
Suddenly, anyone who joins moot will have to invest tons of effort in your custom framework instead of being able to hit the ground running.
Suddenly, anyone who joins moot will have to invest tons of effort in your custom framework instead of being able to hit the ground running.
We used to call that part of software development “design”, and learning basic design skills and becoming familiar with the common strategies and techniques were prerequisites for being a useful developer. Perhaps losing that baseline is an unfortunate side effect of having readily available black box code to do many common jobs in the Internet age and being able to get moderately good results just by joining up those boxes. I don’t think this is a good thing, though. The idea that learning to find your way around a design when you start working on a new project might be considered difficult and not just something everyone routinely does is not a happy one.
Granted that may not be quite at the level of designing your own complete framework from scratch, but imho it's the happiest middle ground between personal skill development and standing on the shoulders of giants that FOSS has enabled.
That's the framework party line. Not necesarilly true. For one, somebody not familiar with, say, Angular would still have to get to know Angular (a huge task in itself) and then your application code too.
Why not just have them understand the application code only? Since it's tailored to your application it also omits needless features and workarounds for framework issues.
Most frameworks weren't built out of thin air, but because of real application needs. Sure they have more than is necessary, but it is often the case in any non-trivial application that you end up writing a bunch of custom common "framework" code which duplicates the work that readily available frameworks (that you avoided using) had.
Any new developers then have to learn your new "lightweight templating language", "lightweight database mapper", "lightweight MVC layer", and what have you (which now you have to support even though it's not core to what your application does, but is just a support layer).
Though I guess the best part is most of these frameworks being discussed came about because an internal team wasn't happy with what was available and decided to roll their own, which eventually became big enough to release as a standalone unit.
There are trivial apps (no need of framework, small enough), medium apps (can use a framework maybe) and serious non-trivial large apps, apps you bet your company on.
The latter are often better to NOT base into a framework. If they do anything novel, and they want to do, they'd hit framework limits. The framework will impose its logic upon your code, whether it fits or not, and you'll have all the baggage of assorted layers it offers you'll feel obliged to use.
>Any new developers then have to learn your new "lightweight templating language", "lightweight database mapper", "lightweight MVC layer", and what have you
That's totally orthogonal. That you don't use a framework, doesn't mean you can handpick any of the popular template language libs, database mapper libs etc. Instead of being constrained by the set the framework authors chose.
That is: libs, instead of frameworks.
>Though I guess the best part is most of these frameworks being discussed came about because an internal team wasn't happy with what was available and decided to roll their own, which eventually became big enough to release as a standalone unit.
That's not ironic in the slightest though. It reinforces what I said: since those teams evaluated whats available and they didn't fit their needs and rolled their one to solve their particular problems they way they want to solve them, what makes third companies think those "hand-rolled" frameworks are a good fit for THEIR needs?
The message to take away, when a company rolls her own framework is not "frameworks are good, I should use theirs", but "they saw it fit to roll their own stuff. Perhaps I should too".
After all, if you're a startup your competitive advantage is your code. You shouldn't constrain it to fit anything external.
Now, if you are a consultant or web designer delivering cookie cutter projects for a company, or an enterprise developer doing some CRUD, by all means use a framework. Especially if you aren't doing anything very creative or original in the first place.
How can you expect to ask for raises if all devs are basically interchangeable? If we've eradicated all notions of design, and follow prescriptive rules of structuring and solving problems that anybody can Google and follow, then what avenues are left to express technical ability? What differentiates you?
And sure, then you have people who can come in and "hit the ground running" but they're little more than overpaid glue sticks. They don't understand true software engineering. They just know how to glue framework code together.
Is it possible that some of us have an idea about what we're doing, but have to do enough different projects that learning a common framework has enough of a benefit to outweigh writing bespoke code for everything?
I don't feel the need to write a whole language for every problem I need to solve, and I don't generally think of the language functions I don't use on a given project as "cruft".
More seriously, I can understand where you might be coming from with the implication that frameworks are a crutch for developers who don't bother to learn, or aren't capable of learning, the language in which the framework is implemented; I've had to clean up the wreckage left behind by Ruby on Rails hacks, too.
But what's important to keep in mind is that the Rails dev community is extremely atypical in its extremely low average level of basic programming capability, and the Rails framework is likewise anomalous in the degree to which it forgives such incompetence. These traits, I stress, are not common to frameworks in general or to the developers who employ them, and consequently it is very much a mistake to use the Rails ghetto as a basis for extrapolation to more or less anything else. It's your mistake to make, of course, and if you insist upon it, then I won't go to any further effort on your behalf. But you can't say no one tried to warn you.
I prototype slower, but nobody cares.
But excellence should mean using the right design for a program, not the Good Enough one advocated by today's fashionable framework. I'm more concerned about collective effects (such as negating the need for analysis and design).
This is yet another instance of Worse is Better.
In the post, it is clear that moot has a set of concerns that a typical business software developer doesn't have.
So, pick the right tool for your business situation, which may include a framework, or not. But I have to say, as a developer, the times when I thought I had to start from scratch and been right were far fewer than the times I wanted to start from scratch and been wrong.
That may be a testament to my skill, the problems I work on, or both.
Automation is desirable because it increases efficiency and lowers costs.
Automation is undesirable because it eliminates jobs and automatons are not consumers.
The profession isn't commoditized, the lower end of the profession gets better, and those with the skills move up a notch and do more and more challenging things.
I used to build single-page javascript apps in pure javascript (pre-jQuery), and it was a pain. Once jQuery came along, things were easier. I actually don't think I'd have too much trouble going back and using just jQuery, but I don't think I'd be as productive as I am with backbone, angular or knockout.
I never did desktop development so don't know about there, but some must have been good.
I'm assuming you mean they are on CRUD as in most projects are what I call 'simple I/O'. Data goes into a database, data comes out of a database, and the job of the developer is just to make that happen.
For the most part, that is true, but I don't think you can blame that on the 'industry', that's the 'market'. The majority of the market didn't/doesn't need anything more than that.
However, if you have the skills, there are lots of jobs out there in data-analytics, robotics, etc. etc. (depending on where you are) that probably wouldn't have been available if we were ALL neck deep building every CRUD app from scratch. The frameworks make average people right faster and better code.
Hell, they help me write better and faster code. I'm no coding genius, but I've built apps in rails, and it is faster than when I was building everything by hand in PHP.
I haven't been doing much CRUD lately, seems like Front-End has taken the majority of my time in the last few years, but that's part of the 'craft' of being a developer. I actually find front-end more challenging and rewarding than CRUD (these days) simply because frameworks have made CRUD so easy.
I dunno, maybe actually solving problems for clients instead of playing endless rounds of "my JS is smaller than yours"?
This is how the nodejs guys are doing this via npm and I must say, it's staggering. The core node "framework" has a tiny API, and the heart of it is simply require().
I coded single page HTML5 apps in JS and Node.js/PHP and avoided any frameworks. A few helper functions are enough and I got a codebase that is easy to read, refactore and the overall code size is small and the execution is fast.
It's not that I am generally against 3rd party code, JavaScript is just a bit special in that case. The quality of JavaScript libraries is just so outright bad that I don't have any use for most of them. I have a personal policy to only include code that satisfies my personal quality standards, if a codebase makes me cringe I will not use it but rather write my own.
If someone works on a popular framework, it makes it easier to get the next job.