Pretty funny, reminds of the last in-loco project I worked with. We had a simple Python backend which served a webpage with one or two templating directives - that in turn loaded a single JS library that we used to do everything. I'm a simple guy and I like to keep things simple so no fancy frameworks, just basic javascript and that one library which was pretty useful but not over-used. Our server-side code was pretty small, with one file per AJAX functionality and the client-code was pretty much one HTML per page/section.
Then the new guy came in. Since our technical management was pretty much inexistent to enforce any type of style or quality control in a couple weeks the project had grown over 50 javascript files, most of them 10 lines long, each with 6 lines or so of boilerplate code (like wrapping everything in a function{}()). And there was grunt and npm and probably a dozen other libraries which were as much of a problem as they were solutions - practically overnight. The code was now minified, obfuscated and impossible to debug. Our project that wasn't even 2 months old or so now had 5 or more grunt tasks. It was now impossible to catch any sort of debug information in the browser.
I don't blame him really - it was just how he was used to doing things in his last job so he took advantage of the lack of oversight to turn his new job into his old job as fast as possible for a few reasons: 1. he didn't want to learn anything new; 2. he wanted everyone to feel like he knew what he was doing and the only way to do that is to convert the project into the only way of working he knew of; 3. to make sure that as everything else broke and the project became unproductive he was the go-to guy to get answers from (about the problems he introduced in the first place). I may sound resentful but I am not, of him - the fault lies with the management who didn't even know what was happening and when problems started to arise did nothing but wash their hands of any responsibility. A few weeks later I was let go in a very weird way (agreed by my coworkers) and the only guy working in the project was him. I really don't feel bad over it, he got what he wanted - now he is the only shitty person working on a shitty project with shitty code and I don't mind it. If that's what the company wants I'm more glad to go away, really!
Meanwhile I'm working on my own projects. I've worked for two years on another one which doesn't use a single external Javascript library. It's a two-year project that doesn't use jQuery, doesn't connect to a database, just does some server-side rendering with 3 javascript files and maybe 2 or 3 very small JSP files server-side (100 lines of code?). And it works fine. A bit unconventional but designed way of doing things. May take a new programmer a day or two of reading the code but when the entire project is not even 10 files big there's really not much to learn. Someone who fancies himself a programmer will not be able to work the project but any real programmer will - with a day or two of reading code at most.
So in the end I don't feel like doing things the "fancy way" is actually necessarily beneficial. I'd rather have a project with 2 or 3 500-line long javascript files (which are really not that big if you ask me) than a hundred 10-line long impossible-to-maintain files which are 50% boilerplate code and juggling around several pieces of implied and "magical" infrastructure around that does something but you can't really tell what they're doing, when or how and will break on any type of updating since there's so many working together. It sure makes it awkward when I go to an interview and tell the guys "welp no, I don't know how to use any of these next-gen libraries because I actually never need them* but as long as I can build a decent project that reaches their objectives with the basics, in a productive and well-designed manner, I think I'll be fine.
External frameworks and libraries are fine when selected during the design stage to fit the project as a whole and become a huge help. Mostly though, unfortunately, they're just tools required by bad programmers to avoid actually designing and writing good source code.
1 comment
5 u/omegletrollz 04 Oct 2016 17:20
Pretty funny, reminds of the last in-loco project I worked with. We had a simple Python backend which served a webpage with one or two templating directives - that in turn loaded a single JS library that we used to do everything. I'm a simple guy and I like to keep things simple so no fancy frameworks, just basic javascript and that one library which was pretty useful but not over-used. Our server-side code was pretty small, with one file per AJAX functionality and the client-code was pretty much one HTML per page/section.
Then the new guy came in. Since our technical management was pretty much inexistent to enforce any type of style or quality control in a couple weeks the project had grown over 50 javascript files, most of them 10 lines long, each with 6 lines or so of boilerplate code (like wrapping everything in a
function{}()). And there was grunt and npm and probably a dozen other libraries which were as much of a problem as they were solutions - practically overnight. The code was now minified, obfuscated and impossible to debug. Our project that wasn't even 2 months old or so now had 5 or moregrunttasks. It was now impossible to catch any sort of debug information in the browser.I don't blame him really - it was just how he was used to doing things in his last job so he took advantage of the lack of oversight to turn his new job into his old job as fast as possible for a few reasons: 1. he didn't want to learn anything new; 2. he wanted everyone to feel like he knew what he was doing and the only way to do that is to convert the project into the only way of working he knew of; 3. to make sure that as everything else broke and the project became unproductive he was the go-to guy to get answers from (about the problems he introduced in the first place). I may sound resentful but I am not, of him - the fault lies with the management who didn't even know what was happening and when problems started to arise did nothing but wash their hands of any responsibility. A few weeks later I was let go in a very weird way (agreed by my coworkers) and the only guy working in the project was him. I really don't feel bad over it, he got what he wanted - now he is the only shitty person working on a shitty project with shitty code and I don't mind it. If that's what the company wants I'm more glad to go away, really!
Meanwhile I'm working on my own projects. I've worked for two years on another one which doesn't use a single external Javascript library. It's a two-year project that doesn't use jQuery, doesn't connect to a database, just does some server-side rendering with 3 javascript files and maybe 2 or 3 very small JSP files server-side (100 lines of code?). And it works fine. A bit unconventional but designed way of doing things. May take a new programmer a day or two of reading the code but when the entire project is not even 10 files big there's really not much to learn. Someone who fancies himself a programmer will not be able to work the project but any real programmer will - with a day or two of reading code at most.
So in the end I don't feel like doing things the "fancy way" is actually necessarily beneficial. I'd rather have a project with 2 or 3 500-line long javascript files (which are really not that big if you ask me) than a hundred 10-line long impossible-to-maintain files which are 50% boilerplate code and juggling around several pieces of implied and "magical" infrastructure around that does something but you can't really tell what they're doing, when or how and will break on any type of updating since there's so many working together. It sure makes it awkward when I go to an interview and tell the guys "welp no, I don't know how to use any of these next-gen libraries because I actually never need them* but as long as I can build a decent project that reaches their objectives with the basics, in a productive and well-designed manner, I think I'll be fine.
External frameworks and libraries are fine when selected during the design stage to fit the project as a whole and become a huge help. Mostly though, unfortunately, they're just tools required by bad programmers to avoid actually designing and writing good source code.