4 ms·

> I've worked on a few applications with 'rich/complex interactions' and everyone on the team was opposed to using any sort of JS framework Ah but if you actua

> I've worked on a few applications with 'rich/complex interactions' and everyone on the team was opposed to using any sort of JS framework Ah but if you actually looked at what you built, I am 100% sure you folks built your own framework instead. A framework that has no community support, no stackoverflow articles to help out and most likely minimal explicit documentation. You will never be able to hire talent that already knows the tools for your framework. You'll be spending all of the next eternity cobbling together features that you could have had out of the box had you adopted somebody else's framework instead. The choice is never "use a framework" vs. "don't use a framework". The choice is "do we use somebody else's framework" vs. "do we build our own framework". What you implicitly and unknowingly chose was the "we are gonna build our own framework" option. In my experience, the minute the few folks who pushed the "no framework" option leave the company, all the rest of the developers smile and scramble to replace the hot mess of a codebase with something using an industry accepted framework.

crtlaltdel 7y ago
i've seen a shop start as a "no-framework" effort and it did indeed become an "internal framework" project. imo it was a strange choice, given how much effort had to go into maintaining and bugfixing the internal framework...mostly issues that would have been flushed out in something with wider support. before being involved in mostly "modern saas", i was heavy in electrical/electronics mfg and there was always a tension between "not-invented-here" and "borrow-buy-build" camps. NIH would stress that all components in our designs should be in-house (electrical metering, data acquisition, etc) while the BBB camp would turn every effort into a 3rd party integrations exercise. at times this even applied to the factory floor. i seriously know a person who was like "hrm, lets build our own pick-and-place for the smt line..."
- spookthesunset 7y ago
  > i seriously know a person who was like "hrm, lets build our own pick-and-place for the smt line..." I mean, how hard could building our own pick & place be, right? Once you strip out all the bloat the vendors add to make a sale, it is nothing you couldn't do with a couple servos and a $5 Arduino, right? I think the "build everything ourselves" attitude comes from a not at all understanding opportunity costs and comparative advantage. Plus in the software industry, tons of developers I've encountered are super paranoid about "vendor lockin" without realizing that once they roll their own library/framework/pick-and-place-machine they have effectively locked their employer into a vendor as well. Only instead of a third party vendor with all the benefits that may come with it, they've "purchased" a product from a really shitty vendor--themselves! It is never a choice between: "Platform or no platform" "Framework or no framework" "Vendor lock-in or no vendor lock-in" You will always be on a platform. You will always be using a framework and you'll always be locked into a vendor. The trick is to make sure you don't lock yourself into a shitty vendor who makes a shitty platform or framework.
flukus 7y ago
> A framework that has no community support, no stackoverflow articles to help out and most likely minimal explicit documentation. But there are gains too. The custom framework is probably much smaller and less complex, easier to know 100% of. It can be stepped through in the debugger. It's much easier to change and add features that your company needs, there's no outside bureaucracy to get in the way. I disagree you're inventing your own framework too, there is a distinction to be made between libraries and frameworks. Just because I'm not using a framework doesn't mean I'm reinventing it, I could be using something like knockoutjs instead, or even postbacks.
- arvinsim 7y ago
  React, Vue and Angular can all step through debuggers.
- spookthesunset 7y ago
  Mark my words, you’ll be spending the rest of your days poorly reinventing what was already done in a real framework. I’ve seen what comes of these “I don’t want to use a bloated framework” shops and it is never pretty. The second the people who eschew mainstream frameworks leave, the devs who are still are around will quickly rebuild around a real framework.
FpUser 7y ago
Not directly related to web front end but having extensive developer experience I tend to shy big frameworks (with a couple of exceptions) . Instead I am using set of battle proven libraries that change depending on needs. My reasons are: I do not need to learn a monster If framework goes down/becomes unpopular etc. etc. I could care less Libraries are easily abstracted and replaceable. Yes I/team do end up implementing our own framework but this framework is very tiny comparatively to you common monstrous frameworks and any sane person can get a grip in a day or less and it only has enough to accomplish a project. Also it can be easily sliced/diced and needed accumulated bits and pieces can be used for next project.

crtlaltdel 7y ago

i've seen a shop start as a "no-framework" effort and it did indeed become an "internal framework" project. imo it was a strange choice, given how much effort had to go into maintaining and bugfixing the internal framework...mostly issues that would have been flushed out in something with wider support. before being involved in mostly "modern saas", i was heavy in electrical/electronics mfg and there was always a tension between "not-invented-here" and "borrow-buy-build" camps. NIH would stress that all components in our designs should be in-house (electrical metering, data acquisition, etc) while the BBB camp would turn every effort into a 3rd party integrations exercise. at times this even applied to the factory floor. i seriously know a person who was like "hrm, lets build our own pick-and-place for the smt line..."

spookthesunset 7y ago
> i seriously know a person who was like "hrm, lets build our own pick-and-place for the smt line..." I mean, how hard could building our own pick & place be, right? Once you strip out all the bloat the vendors add to make a sale, it is nothing you couldn't do with a couple servos and a $5 Arduino, right? I think the "build everything ourselves" attitude comes from a not at all understanding opportunity costs and comparative advantage. Plus in the software industry, tons of developers I've encountered are super paranoid about "vendor lockin" without realizing that once they roll their own library/framework/pick-and-place-machine they have effectively locked their employer into a vendor as well. Only instead of a third party vendor with all the benefits that may come with it, they've "purchased" a product from a really shitty vendor--themselves! It is never a choice between: "Platform or no platform" "Framework or no framework" "Vendor lock-in or no vendor lock-in" You will always be on a platform. You will always be using a framework and you'll always be locked into a vendor. The trick is to make sure you don't lock yourself into a shitty vendor who makes a shitty platform or framework.

flukus 7y ago

> A framework that has no community support, no stackoverflow articles to help out and most likely minimal explicit documentation. But there are gains too. The custom framework is probably much smaller and less complex, easier to know 100% of. It can be stepped through in the debugger. It's much easier to change and add features that your company needs, there's no outside bureaucracy to get in the way. I disagree you're inventing your own framework too, there is a distinction to be made between libraries and frameworks. Just because I'm not using a framework doesn't mean I'm reinventing it, I could be using something like knockoutjs instead, or even postbacks.

arvinsim 7y ago
React, Vue and Angular can all step through debuggers.
spookthesunset 7y ago
Mark my words, you’ll be spending the rest of your days poorly reinventing what was already done in a real framework. I’ve seen what comes of these “I don’t want to use a bloated framework” shops and it is never pretty. The second the people who eschew mainstream frameworks leave, the devs who are still are around will quickly rebuild around a real framework.

FpUser 7y ago

Not directly related to web front end but having extensive developer experience I tend to shy big frameworks (with a couple of exceptions) . Instead I am using set of battle proven libraries that change depending on needs. My reasons are: I do not need to learn a monster If framework goes down/becomes unpopular etc. etc. I could care less Libraries are easily abstracted and replaceable. Yes I/team do end up implementing our own framework but this framework is very tiny comparatively to you common monstrous frameworks and any sane person can get a grip in a day or less and it only has enough to accomplish a project. Also it can be easily sliced/diced and needed accumulated bits and pieces can be used for next project.