10 ms·

> "You don't want to write "raw" html/js/sql/Java" Uhm I thought that was my job. It's not your job, any more than a firefighter's job is to be a hose operator

> "You don't want to write "raw" html/js/sql/Java" Uhm I thought that was my job. It's not your job, any more than a firefighter's job is to be a hose operator, or a nurse's job is to be a syringe operator. Your job is to produce software that meets the requirements of the business, as a member of a larger engineering organization which needs to be able to function well enough to deliver that software. Why are frameworks popular? Because they provide a standardized way for multiple engineers, and multiple engineering teams, to collaborate effectively on the same product -- and they make it easy to hire people who already know the frameworks. If everyone is writing "raw" JS/HTML/SQL/Java/whatever, they are actually building their own individual, unstandardized frameworks. That's not good for supporting software when the author leaves, and it raises the barrier enormously for onboarding new people. Above a certain scale it's just not workable. You can be cynical about this and say that it reduces engineers to interchangeable cogs in a machine. Or, you can understand why things are the way they are, understand how to succeed in this reality, and build a fulfilling career path for yourself by providing value that a mere cog cannot. I've worked with a lot of successful, happy engineers who are not cogs, and what separates them from the others is not coding skill -- it's that they all understand this reality.

emsy 5y ago
I don’t think you have a lot of experience with long software projects. The pros of frameworks are outweighed by their cons pretty quickly. This effect is accelerated by shorter support times and an ever growing number of frameworks.
- tluyben2 5y ago
  Maybe depends what tech you work in? In the Java and .NET sphere things are pretty much stable over many years. We hardly had to do any work to to move our systems (quite large ones) across the same well supported frameworks to new versions the past decades and the fact everyone in these ecosystems know the popular frameworks well and the design patterns, it scales well to many and new people.
- woojoo666 5y ago
  Do you have any examples of web apps or websites with millions of users, and don't use any frameworks? The only one I can think of is HackerNews, funny enough.
  - robocat 5y ago
    The more users, the less likely you are to use an off-the-shelf framework. Netflix: https://netflixtechblog.com/building-the-new-netflix-experience-for-tv-920d71d875de https://netflixtechblog.com/building-the-new-netflix-experie... Facebook: https://blog.risingstack.com/the-history-of-react-js-on-a-timeline/ https://blog.risingstack.com/the-history-of-react-js-on-a-ti... Edit: find out what framework (although it didn’t work on some urls I tried): https://www.wappalyzer.com/ https://www.wappalyzer.com/
    - twblalock 5y ago
      It's really more about the size of the company -- those companies have enough engineers to have large teams dedicated to their various frameworks and build systems. Some of the popular open source frameworks are derivatives of what these companies had already developed internally for themselves, e.g. React.
    - woojoo666 5y ago
      I may be wrong since this article is from 2018 but it seems like Netfix uses React for everything but their homepage [1]. Facebook uses it's own framework since, well, that framework is React. But their framework isn't some special-purposes framework built for Facebook's purposes either, it's a general purpose framework, used by tons of companies including Netfix. So I don't think many web tech companies are going to find success building their own special-purposes front-end frameworks, like some earlier comments seem to suggest. [1]: https://medium.com/dev-channel/a-netflix-web-performance-case-study-c0bcde26a9d9 https://medium.com/dev-channel/a-netflix-web-performance-cas...
jjnoakes 5y ago
Not op but I have to disagree with this sweeping assessment. I think there is room for both approaches. I for one believe that the best solutions I've produced over the years were things that side-stepped the popular or established frameworks and were more customized and focused solutions. They gave the business an undeniable edge over the cookie cutter competition, and by being well versed in the full stack, my team was able to implement new features at a fraction of the cost. Anyone who knows the underlying technology can pick up our work in not much more time than learning any off-the-shelf framework simply because our solution has fewer moving parts and the relationships between the business logic and the bedrock are direct and intuitive.
- scarface74 5y ago
  They gave the business an edge until someone else had to use your framework instead of a popular well documented one
- twblalock 5y ago
  > I for one believe that the best solutions I've produced over the years were things that side-stepped the popular or established frameworks and were more customized and focused solutions. They gave the business an undeniable edge over the cookie cutter competition, and by being well versed in the full stack, my team was able to implement new features at a fraction of the cost. Yes but that's different from being a cowboy coder or a cynic who rejects the concept of frameworks in the first place. You built a new framework customized to your business needs. To do that, you needed to understand the context of the business and your tech stack, understand why existing frameworks didn't fit, and build a new one that works well. It's a good example of not being a cog, which is what I was encouraging in my comment.
  - jjnoakes 5y ago
    That's just it though - I wouldn't call anything we've built a "framework" at all. All of the projects were much simpler at their core than most frameworks I've ever dealt with. Of course, "framework" might have different definitions for different people. To me, by definition, a framework tries to be more generic than a custom solution, has more features that appeal to more than one use-case, and is designed to be flexible and fit multiple projects. The solutions I've had major success with were none of those things because the benefits we got (deeper knowledge of our stack, faster iterations, and features no one else could touch) way outweighed any perceived benefits of using something mostly off-the-shelf.
wackget 5y ago
> If everyone is writing "raw" JS/HTML/SQL/Java/whatever, they are actually building their own individual, unstandardized frameworks. That is only "technically" true, in the way that if you develop any kind of sufficiently complex program then you will have, by necessity, built something which could be called a framework. Realistically, though, your point is invalid and misses the mark. To say that programmers shouldn't write pure code without an existing framework is akin to saying that a house builder shouldn't use bricks and lumber to build a house; they should buy a pre-fab kit instead. Which is, of course, nonsense unless you want the shittiest quality most generic house possible.
- arinlen 5y ago
  > To say that programmers shouldn't write pure code without an existing framework (...) That's not what's been argued. The overall thesis is that developers end up using higher-level abstractions, and between wasting time writing and debugging your custom high-level abstractions and simply adopting a feature-complete, stable, and standard high-level abstractions, you'd have a hard time trying to justify wasting time rolling your own when others already did all that work.
  - TuringTest 5y ago
    > between wasting time writing and debugging your custom high-level abstractions and simply adopting a feature-complete, stable, and standard high-level abstractions, you'd have a hard time trying to justify wasting time rolling your own when others already did all that work. That's only true when all the abstractions you need have already been implemented by others. Most of the time though, in addition to off-the-shelf abstractions, you need to build new abstractions which are specific to the business problem at hand; and shoehorning those abstractions on top of an existing framework which was not created with them in mind may be more work and may provide a less robust, way more complex solution.
    - woojoo666 5y ago
      It's really just a cost-benefit analysis of whether it's worth it to build your own solution or build on top of somebody else's. I think a few years of experience gives everybody an idea of the general tradeoffs of each approach, some people will just tend to lean one way while others lean the other way
marcosdumay 5y ago
> Why are frameworks popular? Because they make it very quick to get a 70% working system that you can sell to people (internally too) before the people with the capacity to get a 100% working system gets their first version.
- jseban 5y ago
  In other words: they make sense for making prototypes.
  - marcosdumay 5y ago
    And then your prototype gets into production, and you can never rewrite it. So, no, they do not make sense for making prototypes. They do make work when you want a 70% solved problem and won't care about never reaching 100%. On the other cases, you still need to use them, because if somebody gets those 70% first, you will have problems, but they make no sense at all.
x-shadowban 5y ago
His argument was more that that there are hose-operating-tooling (and tooling for that tooling) that many fire departments are using but if you want to adjust the nozzle aperture well that's not implemented yet and you need the schematics
commandlinefan 5y ago
> Your job is to produce software that meets the requirements of the business In “raw" html/js/sql/Java.
thewarrior 5y ago
Honest question - how does one provide value in this reality. It’s something I’m trying to understand
- john567 5y ago
  Start simple. Educate co-workers on why a specific approach is good. Build culture. Slowly but surely you should all be working towards the same goal. It's a slow process but with many moving parts. Take on a single piece at a time. That's the only thing that works.
  - jseban 5y ago
    This is the worst type of working environment, when everyone on the team is trying to "educate" and evangelise and "build culture" which is nothing but sucking up to the manager, instead of trying to be realistic about solving issues and delivering value.
- woojoo666 5y ago
  At least if I'm understanding your question properly, frameworks only provide the frame, you have to fill in the rest
- closeparen 5y ago
  The business itself is like a computer process. There are flows of information and resources. There is state. There are subroutines. There are bottlenecks and bugs and wasted efforts and errors that may or may not be getting detected or mitigated. There are various intents that customers and stakeholders might have that are unreasonably difficult to fulfill under the current layout of things. You add value when you optimize, debug, and refactor the business operation. Increasingly in old-economy companies, but especially in Silicon Valley companies, the business operation is largely defined in code. So this is something software engineers can do, through well-chosen code changes. Outside of startups, engineers rarely do this alone. There are executives, business analysts, product managers, data scientists, etc. with very similar tasking. But you want to get into a position where these people see you as a full intellectual partner, not as an implementation resource to type in their already-baked ideas.
belter 5y ago
And how to avoid ending up with a: "General-Purpose Tool-Building Factory Factory Factory"? "Why I Hate Frameworks": https://www.gwern.net/docs/cs/2005-09-30-smith-whyihateframeworks.html https://www.gwern.net/docs/cs/2005-09-30-smith-whyihateframe...
com2kid 5y ago
> If everyone is writing "raw" JS/HTML/SQL/Java/whatever, they are actually building their own individual, unstandardized frameworks. It depends. If you have a nail, and you are using a jackhammer of a framework to pound it in, every developer that comes after you has to learn how to use that jackhammer unless they have previous experience with it. And honestly, most complex frameworks have so many different potential usage patterns that future developers will still have a heck of a learning curve. (I've never seen two uses of redux that remotely resembled each other! After using redux for 3 years I can easily find redux code that I have literally next to no idea what it is doing!) If you use a hammer, even if it is a bespoke hammer, future developers just have to learn how to pick up that hammer. Obviously at some point it pays to switch to using an Industry Standard(tm) solution, but for many problems plain old JS or HTML may very well be appropriate. For example, I was making ad campaign landing pages for my now defunct startup. To ensure speed I wanted them to all be static HTML. I could have used a static site generator of some sort, configured templates and all that jazz, or, instead, I could just write HTML + CSS for 3 landing pages. (Actually I only had to write the CSS once). Now if I needed to programmatically generate dozens of landing pages, then sure, adopting some static site generating framework may have been worthwhile. But in my case it wasn't. Raw HTML was the correct solution.
- chii 5y ago
  aka, right tool for the job. there's no mantra that should be followed without thought in software engineering. Frameworks helps in a lot of cases, and should be used - but this decision require someone with experience to make, and this experience has to have been hard earned from previous failures or projects.
- explaingarlic 5y ago
  > To ensure speed I wanted them to all be static HTML Feels like people shoehorn Gatsby too much into those kinds of situations. Bless you for keeping the dream alive - every time I see well written and small HTML/CSS/JS code on a landing page I want to scream. Despite knowing React and being familiar enough with Vue, Angular etc. I still get imposter syndrome when I see a site's markup and see weird artefacting that comes from some framework that I have never heard of.
explaingarlic 5y ago
> Why are frameworks popular? Because... That's an extremely open question, and I wouldn't agree that frameworks, in any way, "provide a way for people to collaborate" any more than a whip does. They seem to me to limit the ability to write the code you want for no value other than providing confirmation bias. The idea that the same thing being outputted on the screen will have two implementations by two uncommunicative engineers that vary in such a way that they become impractical, impossible or even at all harder to debug, is simply a myth. I highlighted the word "engineer" because that's the key point - if you are hired to solve a problem, you are probably going to solve it the easiest and most convenient way. You are trusted to write code, not use an API. I find it hard to buy the idea that 20 year old aspx code is any easier to debug than pure JavaScript written around that time. As far as why frameworks have become the norm, I would personally put it down to, in no particular order, the following ideas: - Some are genuinely useful - functionality is limited in the parent environment's API and must be implemented in some way. This is rare, in my (mild) experience. - The company had learned the lesson that contractors (especially ones that win the bidding wars) write horrific and unmanageable code. Therefore, it decided that a cost-free way to alleviate this issue is to force all engineers, permanent or on-contract, to use a specific framework. - The above point spread between companies as people (directors of engineering) shifted around, word spread that someone was able to make significant cost savings etc. - They are in place to allow one to follow idioms better. I recently interviewed for a company that followed, quite closely, the clean architecture book by Martin Fowler, with their own internal framework. They had a good plan in mind - they wanted components to be interchangeable, usually at compile time, and needed to ensure that they followed procedure in order to write code that was manageable at scale in order to achieve this. They made their own framework and have used it for 10+ years. This proper, elegant use of a framework is very rare. I do not mean to say that frameworks are useless - however, JQuery has always been absolutely worthless to me in my personal endeavours - which often included quite bespoke DOM manipulations - the exact place that JQuery is meant to shine. To me, it is a great example of something that was phased in as a Band-Aid solution to people writing terrible code as they had no ownership of the product. I will admit that I use little helpers, such as function $(usuallyASwearWord){ // Yes I really use element by id for this when writing my own fun code. Not query selector. return document.getElementById(usuallyASwearWord); } and I wouldn't be using these if JQuery never exploded in popularity - but it's just a skeuomorph. A cute little oddity that has some minor, pointless, boring history/flavour behind it. I don't think that JQuery has provided the world with any significant net effort savings, and that it is far from the only framework that will have this legacy.
atotic 5y ago
I think that the decision on whether to use a framework is very hard. When using a framework, you get most of the benefits right away, and most of the costs happen much later, when abandoning the framework is costly. Besides pure technical quality, you have to consider more murky issues: who wrote the framework? how long will they be around for? Does their problem match your problem? Will your interests remain aligned in the future? Is there a succession plan? Will new hires be familiar with it? What's the learning curve? Does it integrate with the other N tools you are using? Ideally, the decision to use the framework or not should be made by someone who has used it before. This is often not the case. My personal preference is to always use simplest tools that get the job done. I wish that hiring technical writers to write docs was more common. Most of the new libraries I have to use have documentation that is so poor, I have to use stack overflow + write test cases. Currently, I am in the middle of taking over a go code hairball from someone who left, and who loved external dependencies. Out of 31 direct dependencies, 11 are not at release 1.0 yet. Many have poor documentation. I believe that when I am done with it, our code will have fewer dependencies, and be half the size.
hkt 5y ago
I agree with most of this, but > it raises the barrier enormously for onboarding new people. is.. a little ironic. I've never met any of the gazillion frameworks out there that have made it easier to get people up to speed, despite promises to that effect.
KronisLV 5y ago
> Why are frameworks popular? Because they provide a standardized way for multiple engineers, and multiple engineering teams, to collaborate effectively on the same product -- and they make it easy to hire people who already know the frameworks. Hmm, i'd say that there are frameworks that actually make things easier and better, and some that are much like the incomprehensible Rube Goldberg machines that the previous poster complained about. For an example of this, you needn't look any further than the Spring framework in Java, perhaps the ultimate example of enterprise bloat of poorly understandable (unless you spend all your time digging into the internals) and overly abstracted non-solutions for problems, and that's even before you pull in 50-100 dependencies for making your dated monolith do whatever the business wants. There is an absurd amount of XML configuration needed, except that sometimes you need to mess around with annotations in your source code as well, except for those cases when instead you'll want to just overwrite some class with your custom logic inside of the methods, which will be initialized by some Eldritch abomination of class loading and reflection, or maybe you'll need to change a bunch of properties in a config file, with all of this leading to long and arduous error messages that will make you waste hours digging through Stack Overflow. I was in charge of migrating an older Spring app to Spring Boot, which attempts to alleviate some of these issues (and there was also the fact that the particular Spring version was EOL at that point) and after wasting more time than i'd like to admit of an error after an error after an error, it was decided to just update Spring itself as far as possible and let it chug along in a barely alive state. The framework wasn't a way of managing risks or "getting things done", it ended up being a risk in of itself and was a massive pain once the system needed to be supported, maintained and also have new functionality developed for 5-10 years or so. That's not to say that there aren't better frameworks out there, but there definitely are some that will be more trouble than they're worth, unless you want to have a person or two full-time just to wrangle them in order and continuously maintain and update them, which for many of the smaller orgs out there is unacceptable. > If everyone is writing "raw" JS/HTML/SQL/Java/whatever, they are actually building their own individual, unstandardized frameworks. I've also seem bespoke frameworks be used and those were generally worse - while there was the occasional good idea in them and they could be decent to work with in a limited set of circumstances, getting help when something goes wrong with them was impossible and you were stuck reading the source and mucking about in it. Why is that bad? Because with the larger and more popular frameworks out there you can instead look up solutions for problems or integrations that someone else has written. I'll admit that pulling in dependencies carries certain risks in of itself, but you'll very quickly realize how nice it is to let someone else step on rakes before and learn from their problems and mistakes, instead of attempt to translate code comments from Lithuanian to your own language when prod is running into issues, because the original devs are long gone and there is no documentation, nor examples of how to use anything in place. Thus, it is better to use frameworks that have tens of thousands of collective man hours put into them, or even more, as long as they don't suck. So, in the end, it's probably better to use frameworks that keep you closer to the code that is actually running, like Spring Boot (where at least parts of the config can be done in plain Java), or even look at ones like .NET (the newer ones are a bit like Spring Boot), rather than DSL hell. You can put a breakpoint in your Java code and see why something isn't initializing properly. You cannot put a breakpoint into your .properties, .xml or .yaml file (or even feasibly find where to put into the over-abstracted configuration read mechanism, or find how it connects to the bit that is actually initializing your data).

emsy 5y ago

I don’t think you have a lot of experience with long software projects. The pros of frameworks are outweighed by their cons pretty quickly. This effect is accelerated by shorter support times and an ever growing number of frameworks.

tluyben2 5y ago
Maybe depends what tech you work in? In the Java and .NET sphere things are pretty much stable over many years. We hardly had to do any work to to move our systems (quite large ones) across the same well supported frameworks to new versions the past decades and the fact everyone in these ecosystems know the popular frameworks well and the design patterns, it scales well to many and new people.
woojoo666 5y ago
Do you have any examples of web apps or websites with millions of users, and don't use any frameworks? The only one I can think of is HackerNews, funny enough.
- robocat 5y ago
  The more users, the less likely you are to use an off-the-shelf framework. Netflix: https://netflixtechblog.com/building-the-new-netflix-experience-for-tv-920d71d875de https://netflixtechblog.com/building-the-new-netflix-experie... Facebook: https://blog.risingstack.com/the-history-of-react-js-on-a-timeline/ https://blog.risingstack.com/the-history-of-react-js-on-a-ti... Edit: find out what framework (although it didn’t work on some urls I tried): https://www.wappalyzer.com/ https://www.wappalyzer.com/
  - twblalock 5y ago
    It's really more about the size of the company -- those companies have enough engineers to have large teams dedicated to their various frameworks and build systems. Some of the popular open source frameworks are derivatives of what these companies had already developed internally for themselves, e.g. React.
  - woojoo666 5y ago
    I may be wrong since this article is from 2018 but it seems like Netfix uses React for everything but their homepage [1]. Facebook uses it's own framework since, well, that framework is React. But their framework isn't some special-purposes framework built for Facebook's purposes either, it's a general purpose framework, used by tons of companies including Netfix. So I don't think many web tech companies are going to find success building their own special-purposes front-end frameworks, like some earlier comments seem to suggest. [1]: https://medium.com/dev-channel/a-netflix-web-performance-case-study-c0bcde26a9d9 https://medium.com/dev-channel/a-netflix-web-performance-cas...

jjnoakes 5y ago

Not op but I have to disagree with this sweeping assessment. I think there is room for both approaches. I for one believe that the best solutions I've produced over the years were things that side-stepped the popular or established frameworks and were more customized and focused solutions. They gave the business an undeniable edge over the cookie cutter competition, and by being well versed in the full stack, my team was able to implement new features at a fraction of the cost. Anyone who knows the underlying technology can pick up our work in not much more time than learning any off-the-shelf framework simply because our solution has fewer moving parts and the relationships between the business logic and the bedrock are direct and intuitive.

scarface74 5y ago
They gave the business an edge until someone else had to use your framework instead of a popular well documented one
twblalock 5y ago
> I for one believe that the best solutions I've produced over the years were things that side-stepped the popular or established frameworks and were more customized and focused solutions. They gave the business an undeniable edge over the cookie cutter competition, and by being well versed in the full stack, my team was able to implement new features at a fraction of the cost. Yes but that's different from being a cowboy coder or a cynic who rejects the concept of frameworks in the first place. You built a new framework customized to your business needs. To do that, you needed to understand the context of the business and your tech stack, understand why existing frameworks didn't fit, and build a new one that works well. It's a good example of not being a cog, which is what I was encouraging in my comment.
- jjnoakes 5y ago
  That's just it though - I wouldn't call anything we've built a "framework" at all. All of the projects were much simpler at their core than most frameworks I've ever dealt with. Of course, "framework" might have different definitions for different people. To me, by definition, a framework tries to be more generic than a custom solution, has more features that appeal to more than one use-case, and is designed to be flexible and fit multiple projects. The solutions I've had major success with were none of those things because the benefits we got (deeper knowledge of our stack, faster iterations, and features no one else could touch) way outweighed any perceived benefits of using something mostly off-the-shelf.

wackget 5y ago

> If everyone is writing "raw" JS/HTML/SQL/Java/whatever, they are actually building their own individual, unstandardized frameworks. That is only "technically" true, in the way that if you develop any kind of sufficiently complex program then you will have, by necessity, built something which could be called a framework. Realistically, though, your point is invalid and misses the mark. To say that programmers shouldn't write pure code without an existing framework is akin to saying that a house builder shouldn't use bricks and lumber to build a house; they should buy a pre-fab kit instead. Which is, of course, nonsense unless you want the shittiest quality most generic house possible.

arinlen 5y ago
> To say that programmers shouldn't write pure code without an existing framework (...) That's not what's been argued. The overall thesis is that developers end up using higher-level abstractions, and between wasting time writing and debugging your custom high-level abstractions and simply adopting a feature-complete, stable, and standard high-level abstractions, you'd have a hard time trying to justify wasting time rolling your own when others already did all that work.
- TuringTest 5y ago
  > between wasting time writing and debugging your custom high-level abstractions and simply adopting a feature-complete, stable, and standard high-level abstractions, you'd have a hard time trying to justify wasting time rolling your own when others already did all that work. That's only true when all the abstractions you need have already been implemented by others. Most of the time though, in addition to off-the-shelf abstractions, you need to build new abstractions which are specific to the business problem at hand; and shoehorning those abstractions on top of an existing framework which was not created with them in mind may be more work and may provide a less robust, way more complex solution.
  - woojoo666 5y ago
    It's really just a cost-benefit analysis of whether it's worth it to build your own solution or build on top of somebody else's. I think a few years of experience gives everybody an idea of the general tradeoffs of each approach, some people will just tend to lean one way while others lean the other way

marcosdumay 5y ago

> Why are frameworks popular? Because they make it very quick to get a 70% working system that you can sell to people (internally too) before the people with the capacity to get a 100% working system gets their first version.

jseban 5y ago
In other words: they make sense for making prototypes.
- marcosdumay 5y ago
  And then your prototype gets into production, and you can never rewrite it. So, no, they do not make sense for making prototypes. They do make work when you want a 70% solved problem and won't care about never reaching 100%. On the other cases, you still need to use them, because if somebody gets those 70% first, you will have problems, but they make no sense at all.

x-shadowban 5y ago

His argument was more that that there are hose-operating-tooling (and tooling for that tooling) that many fire departments are using but if you want to adjust the nozzle aperture well that's not implemented yet and you need the schematics

commandlinefan 5y ago

> Your job is to produce software that meets the requirements of the business In “raw" html/js/sql/Java.

thewarrior 5y ago

Honest question - how does one provide value in this reality. It’s something I’m trying to understand

john567 5y ago
Start simple. Educate co-workers on why a specific approach is good. Build culture. Slowly but surely you should all be working towards the same goal. It's a slow process but with many moving parts. Take on a single piece at a time. That's the only thing that works.
- jseban 5y ago
  This is the worst type of working environment, when everyone on the team is trying to "educate" and evangelise and "build culture" which is nothing but sucking up to the manager, instead of trying to be realistic about solving issues and delivering value.
woojoo666 5y ago
At least if I'm understanding your question properly, frameworks only provide the frame, you have to fill in the rest
closeparen 5y ago
The business itself is like a computer process. There are flows of information and resources. There is state. There are subroutines. There are bottlenecks and bugs and wasted efforts and errors that may or may not be getting detected or mitigated. There are various intents that customers and stakeholders might have that are unreasonably difficult to fulfill under the current layout of things. You add value when you optimize, debug, and refactor the business operation. Increasingly in old-economy companies, but especially in Silicon Valley companies, the business operation is largely defined in code. So this is something software engineers can do, through well-chosen code changes. Outside of startups, engineers rarely do this alone. There are executives, business analysts, product managers, data scientists, etc. with very similar tasking. But you want to get into a position where these people see you as a full intellectual partner, not as an implementation resource to type in their already-baked ideas.

belter 5y ago

And how to avoid ending up with a: "General-Purpose Tool-Building Factory Factory Factory"? "Why I Hate Frameworks": https://www.gwern.net/docs/cs/2005-09-30-smith-whyihateframeworks.html https://www.gwern.net/docs/cs/2005-09-30-smith-whyihateframe...

com2kid 5y ago

> If everyone is writing "raw" JS/HTML/SQL/Java/whatever, they are actually building their own individual, unstandardized frameworks. It depends. If you have a nail, and you are using a jackhammer of a framework to pound it in, every developer that comes after you has to learn how to use that jackhammer unless they have previous experience with it. And honestly, most complex frameworks have so many different potential usage patterns that future developers will still have a heck of a learning curve. (I've never seen two uses of redux that remotely resembled each other! After using redux for 3 years I can easily find redux code that I have literally next to no idea what it is doing!) If you use a hammer, even if it is a bespoke hammer, future developers just have to learn how to pick up that hammer. Obviously at some point it pays to switch to using an Industry Standard(tm) solution, but for many problems plain old JS or HTML may very well be appropriate. For example, I was making ad campaign landing pages for my now defunct startup. To ensure speed I wanted them to all be static HTML. I could have used a static site generator of some sort, configured templates and all that jazz, or, instead, I could just write HTML + CSS for 3 landing pages. (Actually I only had to write the CSS once). Now if I needed to programmatically generate dozens of landing pages, then sure, adopting some static site generating framework may have been worthwhile. But in my case it wasn't. Raw HTML was the correct solution.

chii 5y ago
aka, right tool for the job. there's no mantra that should be followed without thought in software engineering. Frameworks helps in a lot of cases, and should be used - but this decision require someone with experience to make, and this experience has to have been hard earned from previous failures or projects.
explaingarlic 5y ago
> To ensure speed I wanted them to all be static HTML Feels like people shoehorn Gatsby too much into those kinds of situations. Bless you for keeping the dream alive - every time I see well written and small HTML/CSS/JS code on a landing page I want to scream. Despite knowing React and being familiar enough with Vue, Angular etc. I still get imposter syndrome when I see a site's markup and see weird artefacting that comes from some framework that I have never heard of.

explaingarlic 5y ago

> Why are frameworks popular? Because... That's an extremely open question, and I wouldn't agree that frameworks, in any way, "provide a way for people to collaborate" any more than a whip does. They seem to me to limit the ability to write the code you want for no value other than providing confirmation bias. The idea that the same thing being outputted on the screen will have two implementations by two uncommunicative engineers that vary in such a way that they become impractical, impossible or even at all harder to debug, is simply a myth. I highlighted the word "engineer" because that's the key point - if you are hired to solve a problem, you are probably going to solve it the easiest and most convenient way. You are trusted to write code, not use an API. I find it hard to buy the idea that 20 year old aspx code is any easier to debug than pure JavaScript written around that time. As far as why frameworks have become the norm, I would personally put it down to, in no particular order, the following ideas: - Some are genuinely useful - functionality is limited in the parent environment's API and must be implemented in some way. This is rare, in my (mild) experience. - The company had learned the lesson that contractors (especially ones that win the bidding wars) write horrific and unmanageable code. Therefore, it decided that a cost-free way to alleviate this issue is to force all engineers, permanent or on-contract, to use a specific framework. - The above point spread between companies as people (directors of engineering) shifted around, word spread that someone was able to make significant cost savings etc. - They are in place to allow one to follow idioms better. I recently interviewed for a company that followed, quite closely, the clean architecture book by Martin Fowler, with their own internal framework. They had a good plan in mind - they wanted components to be interchangeable, usually at compile time, and needed to ensure that they followed procedure in order to write code that was manageable at scale in order to achieve this. They made their own framework and have used it for 10+ years. This proper, elegant use of a framework is very rare. I do not mean to say that frameworks are useless - however, JQuery has always been absolutely worthless to me in my personal endeavours - which often included quite bespoke DOM manipulations - the exact place that JQuery is meant to shine. To me, it is a great example of something that was phased in as a Band-Aid solution to people writing terrible code as they had no ownership of the product. I will admit that I use little helpers, such as function $(usuallyASwearWord){ // Yes I really use element by id for this when writing my own fun code. Not query selector. return document.getElementById(usuallyASwearWord); } and I wouldn't be using these if JQuery never exploded in popularity - but it's just a skeuomorph. A cute little oddity that has some minor, pointless, boring history/flavour behind it. I don't think that JQuery has provided the world with any significant net effort savings, and that it is far from the only framework that will have this legacy.

atotic 5y ago

I think that the decision on whether to use a framework is very hard. When using a framework, you get most of the benefits right away, and most of the costs happen much later, when abandoning the framework is costly. Besides pure technical quality, you have to consider more murky issues: who wrote the framework? how long will they be around for? Does their problem match your problem? Will your interests remain aligned in the future? Is there a succession plan? Will new hires be familiar with it? What's the learning curve? Does it integrate with the other N tools you are using? Ideally, the decision to use the framework or not should be made by someone who has used it before. This is often not the case. My personal preference is to always use simplest tools that get the job done. I wish that hiring technical writers to write docs was more common. Most of the new libraries I have to use have documentation that is so poor, I have to use stack overflow + write test cases. Currently, I am in the middle of taking over a go code hairball from someone who left, and who loved external dependencies. Out of 31 direct dependencies, 11 are not at release 1.0 yet. Many have poor documentation. I believe that when I am done with it, our code will have fewer dependencies, and be half the size.

hkt 5y ago

I agree with most of this, but > it raises the barrier enormously for onboarding new people. is.. a little ironic. I've never met any of the gazillion frameworks out there that have made it easier to get people up to speed, despite promises to that effect.

KronisLV 5y ago

> Why are frameworks popular? Because they provide a standardized way for multiple engineers, and multiple engineering teams, to collaborate effectively on the same product -- and they make it easy to hire people who already know the frameworks. Hmm, i'd say that there are frameworks that actually make things easier and better, and some that are much like the incomprehensible Rube Goldberg machines that the previous poster complained about. For an example of this, you needn't look any further than the Spring framework in Java, perhaps the ultimate example of enterprise bloat of poorly understandable (unless you spend all your time digging into the internals) and overly abstracted non-solutions for problems, and that's even before you pull in 50-100 dependencies for making your dated monolith do whatever the business wants. There is an absurd amount of XML configuration needed, except that sometimes you need to mess around with annotations in your source code as well, except for those cases when instead you'll want to just overwrite some class with your custom logic inside of the methods, which will be initialized by some Eldritch abomination of class loading and reflection, or maybe you'll need to change a bunch of properties in a config file, with all of this leading to long and arduous error messages that will make you waste hours digging through Stack Overflow. I was in charge of migrating an older Spring app to Spring Boot, which attempts to alleviate some of these issues (and there was also the fact that the particular Spring version was EOL at that point) and after wasting more time than i'd like to admit of an error after an error after an error, it was decided to just update Spring itself as far as possible and let it chug along in a barely alive state. The framework wasn't a way of managing risks or "getting things done", it ended up being a risk in of itself and was a massive pain once the system needed to be supported, maintained and also have new functionality developed for 5-10 years or so. That's not to say that there aren't better frameworks out there, but there definitely are some that will be more trouble than they're worth, unless you want to have a person or two full-time just to wrangle them in order and continuously maintain and update them, which for many of the smaller orgs out there is unacceptable. > If everyone is writing "raw" JS/HTML/SQL/Java/whatever, they are actually building their own individual, unstandardized frameworks. I've also seem bespoke frameworks be used and those were generally worse - while there was the occasional good idea in them and they could be decent to work with in a limited set of circumstances, getting help when something goes wrong with them was impossible and you were stuck reading the source and mucking about in it. Why is that bad? Because with the larger and more popular frameworks out there you can instead look up solutions for problems or integrations that someone else has written. I'll admit that pulling in dependencies carries certain risks in of itself, but you'll very quickly realize how nice it is to let someone else step on rakes before and learn from their problems and mistakes, instead of attempt to translate code comments from Lithuanian to your own language when prod is running into issues, because the original devs are long gone and there is no documentation, nor examples of how to use anything in place. Thus, it is better to use frameworks that have tens of thousands of collective man hours put into them, or even more, as long as they don't suck. So, in the end, it's probably better to use frameworks that keep you closer to the code that is actually running, like Spring Boot (where at least parts of the config can be done in plain Java), or even look at ones like .NET (the newer ones are a bit like Spring Boot), rather than DSL hell. You can put a breakpoint in your Java code and see why something isn't initializing properly. You cannot put a breakpoint into your .properties, .xml or .yaml file (or even feasibly find where to put into the over-abstracted configuration read mechanism, or find how it connects to the bit that is actually initializing your data).