5 ms·

To me this kind of thinking sounds so strange. A framework is (like it's namesake) a frame that you can build around, it's a tool that enforces restrictions on

To me this kind of thinking sounds so strange. A framework is (like it's namesake) a frame that you can build around, it's a tool that enforces restrictions on you by design. Obviously there is some overhead to learning that framework, but the idea is that the framework is built by someone who spends their day-job building the framework. They are going to do a better job of designing a framework than you will in most cases. Yes, you can build something great without them, but for any moderately sized project, you will end up re-inventing a set of rules and restrictions to apply to your own internal code. You will in-essence create your own framework. And that's fine, I'm almost positive that your "framework" will do some things very well, probably better than most of the competition, but you need to ask yourself what your main goal is. Are you setting out to build a framework? And/Or are you trying to build a product? If the answer is that you only want a working product, time spent on building your own framework is time wasted, as in my experience you will spend significantly more time writing your own from scratch than you will ever learning one. Doubly so if that framework isn't designed to be reusable at least in your organization. Not to mention the overhead of having all new devs have to learn it anyway. However if the answer is that you are setting out to build your own framework (because the current ones have a limitation that you can't deal with, or some problem that you need to solve yourself), then by all means go for it! But that can't be given as "general advice" as for many people (I'd guess most people), as they don't have those same goals as you do. Frameworks are a tool, and telling people to forgo "pre-made" tools and create them yourself is going to be the wrong advice in most cases. (but not all cases!)

OtterCoder 9y ago
Yes, frameworks are tools, but they're typically overspecialized and poorly designed. If vanilla JS is a cnc machine, Angular is an injection mold for a toy truck. If you're building a toy truck, that's awesome. If you're building anything else, say, a hand mixer, you're going to spend just as much time on the cnc machine trying to design toy truck whisk attachments as you would have spent just building a new mold with the incredibly powerful cnc you already have.
- cormacrelf 9y ago
  That metaphor doesn't help with the default thinking behind a large proportion of engineering decisions. It goes like this: This is hard => I want to do one or two slightly different things => Building custom things feels like valuable work => Use the CNC machine! This is exactly the thinking that created the Juicero[1] (which actually uses many CNC parts), and we all make fun of them even though the same process is a huge driver behind decisions everywhere. It's like an engineering strawman. Create engineering problems because those are easier than actually building the thing. The word 'overspecialized' is a bit sour for web frameworks. There are billions of web sites, most of which are astoundingly similar. Squint at the front-end UI and most engineers are basically building Asana, over and over again, like a boot stamping on a human face – forever. The ways they are differentiated are generally not related to code at all, instead business or meta-engineering needs (e.g. NYT dataviz graphics production, or a small team trying to maximize output). In contrast, everyone needs a router/nav, a wrapper around XHR/an API, some rendering to HTML, and some buttons to do things. If you think Angular (which, stripped down, is ~20kb gz and very basic indeed), or really any framework is too specialized for some set of needs which includes the above four things, you are attacking a very frightened-looking scarecrow with the might of the U.S. Navy. Framework churn is part of this problem; people think they have such big engineering tasks ahead only the new shiny thing can solve it. The point is, needing the whole CNC is _very rare_. Anyone who thinks that all of the big or even little front-end frameworks are too specialized should go look in the mirror. If, when you do that, you literally see a company with 300 engineers or incredibly specialized needs – like immersive interactive media, or you need IE6 compat, then go build your crazy stuff while the rest of us churn out decent apps with near-zero friction. [1]: https://blog.bolt.io/heres-why-juicero-s-press-is-so-expensive-6add74594e50 https://blog.bolt.io/heres-why-juicero-s-press-is-so-expensi...
  - OtterCoder 9y ago
    But Angular isn't simply "a router/nav, a wrapper around XHR/an API, some rendering to HTML, and some buttons to do things". That's JQuery you're describing. Angular determines the shape of the extensions you can build for it, and general, standard components don't fit its philosophy out of the box. With the cnc, you can pick parts and modules from a much bigger pool, then cut your enclosure to match. A widgetized, self-contained module is much easier to adapt to a particular use than a framework, for the same end result.
rhapsodic 9y ago
> They are going to do a better job of designing a framework than you will in most cases. My own framework will do exactly what I need. No more, and no less. It will only solve problems that I actually have, not ones that I don't. My framework will suit my needs better than theirs will, each and every single time. >If the answer is that you only want a working product, time spent on building your own framework is time wasted, as in my experience you will spend significantly more time writing your own from scratch than you will ever learning one. Time is not the main factor. I would rather have something lightweight that does exactly what I want, and only what I want, than some sort of generic one-size-fits-all thing. I don't want to deal with upgrades that are not backward-compatible. I don't want to spend days debugging someone else's to figure out what I did wrong. > Frameworks are a tool, and telling people to forgo "pre-made" tools and create them yourself is going to be the wrong advice in most cases. I'm not telling anyone to do anything. I'm only sharing my own personal views on the subject of the article. For a lot of people, I don't doubt that React or Angular is the best course, for a variety of possible reasons. It's obvious to me that you and I approach the craft of software development from two entirely different angles. It's obvious that you perceive a great deal of value in these framework, so your best bet is to continue using them.
- Klathmon 9y ago
  If time isn't the main factor, then by all means you have the right idea! But I've never really been in a situation where I can afford the time and manpower to do everything myself, so my view is skewed by that. And I do apologise for going off on the tangent there about not telling people to do X or Y. I got a little wrapped up in it and that comment was less targeted at you and more at other people I see advocating for it. Also, I wouldn't say I perceive a great deal of value in these frameworks, just that I use them like tools where they make sense. Across our codebase we have 2 react applications (one with webpack, one with just script tags), one node.js application without any real framework, and one jquery+vanilla-js codebase. We use the frameworks where they make sense, and don't where they don't. And while i'm absolutely certain that a purpose-built framework would serve us better in many areas than something like react will, I don't have confidence in my skills to create something that will stand the test of time. I know what I don't know, and I'm pretty sure that I made the right choice externalizing that work on to someone who has a team of people working just on that aspect. I try to spend my time where it's best used, and in the vast majority of cases I've found that it's best spent working directly on my problem domain, and not on aspects like state management, rendering performance, cross-platform compatibility issues, and more where it's not needed.

OtterCoder 9y ago

Yes, frameworks are tools, but they're typically overspecialized and poorly designed. If vanilla JS is a cnc machine, Angular is an injection mold for a toy truck. If you're building a toy truck, that's awesome. If you're building anything else, say, a hand mixer, you're going to spend just as much time on the cnc machine trying to design toy truck whisk attachments as you would have spent just building a new mold with the incredibly powerful cnc you already have.

cormacrelf 9y ago
That metaphor doesn't help with the default thinking behind a large proportion of engineering decisions. It goes like this: This is hard => I want to do one or two slightly different things => Building custom things feels like valuable work => Use the CNC machine! This is exactly the thinking that created the Juicero[1] (which actually uses many CNC parts), and we all make fun of them even though the same process is a huge driver behind decisions everywhere. It's like an engineering strawman. Create engineering problems because those are easier than actually building the thing. The word 'overspecialized' is a bit sour for web frameworks. There are billions of web sites, most of which are astoundingly similar. Squint at the front-end UI and most engineers are basically building Asana, over and over again, like a boot stamping on a human face – forever. The ways they are differentiated are generally not related to code at all, instead business or meta-engineering needs (e.g. NYT dataviz graphics production, or a small team trying to maximize output). In contrast, everyone needs a router/nav, a wrapper around XHR/an API, some rendering to HTML, and some buttons to do things. If you think Angular (which, stripped down, is ~20kb gz and very basic indeed), or really any framework is too specialized for some set of needs which includes the above four things, you are attacking a very frightened-looking scarecrow with the might of the U.S. Navy. Framework churn is part of this problem; people think they have such big engineering tasks ahead only the new shiny thing can solve it. The point is, needing the whole CNC is _very rare_. Anyone who thinks that all of the big or even little front-end frameworks are too specialized should go look in the mirror. If, when you do that, you literally see a company with 300 engineers or incredibly specialized needs – like immersive interactive media, or you need IE6 compat, then go build your crazy stuff while the rest of us churn out decent apps with near-zero friction. [1]: https://blog.bolt.io/heres-why-juicero-s-press-is-so-expensive-6add74594e50 https://blog.bolt.io/heres-why-juicero-s-press-is-so-expensi...
- OtterCoder 9y ago
  But Angular isn't simply "a router/nav, a wrapper around XHR/an API, some rendering to HTML, and some buttons to do things". That's JQuery you're describing. Angular determines the shape of the extensions you can build for it, and general, standard components don't fit its philosophy out of the box. With the cnc, you can pick parts and modules from a much bigger pool, then cut your enclosure to match. A widgetized, self-contained module is much easier to adapt to a particular use than a framework, for the same end result.

rhapsodic 9y ago

> They are going to do a better job of designing a framework than you will in most cases. My own framework will do exactly what I need. No more, and no less. It will only solve problems that I actually have, not ones that I don't. My framework will suit my needs better than theirs will, each and every single time. >If the answer is that you only want a working product, time spent on building your own framework is time wasted, as in my experience you will spend significantly more time writing your own from scratch than you will ever learning one. Time is not the main factor. I would rather have something lightweight that does exactly what I want, and only what I want, than some sort of generic one-size-fits-all thing. I don't want to deal with upgrades that are not backward-compatible. I don't want to spend days debugging someone else's to figure out what I did wrong. > Frameworks are a tool, and telling people to forgo "pre-made" tools and create them yourself is going to be the wrong advice in most cases. I'm not telling anyone to do anything. I'm only sharing my own personal views on the subject of the article. For a lot of people, I don't doubt that React or Angular is the best course, for a variety of possible reasons. It's obvious to me that you and I approach the craft of software development from two entirely different angles. It's obvious that you perceive a great deal of value in these framework, so your best bet is to continue using them.

Klathmon 9y ago
If time isn't the main factor, then by all means you have the right idea! But I've never really been in a situation where I can afford the time and manpower to do everything myself, so my view is skewed by that. And I do apologise for going off on the tangent there about not telling people to do X or Y. I got a little wrapped up in it and that comment was less targeted at you and more at other people I see advocating for it. Also, I wouldn't say I perceive a great deal of value in these frameworks, just that I use them like tools where they make sense. Across our codebase we have 2 react applications (one with webpack, one with just script tags), one node.js application without any real framework, and one jquery+vanilla-js codebase. We use the frameworks where they make sense, and don't where they don't. And while i'm absolutely certain that a purpose-built framework would serve us better in many areas than something like react will, I don't have confidence in my skills to create something that will stand the test of time. I know what I don't know, and I'm pretty sure that I made the right choice externalizing that work on to someone who has a team of people working just on that aspect. I try to spend my time where it's best used, and in the vast majority of cases I've found that it's best spent working directly on my problem domain, and not on aspects like state management, rendering performance, cross-platform compatibility issues, and more where it's not needed.