7 ms·

I can relate to your experience but you, just as me, seem not to be a typical front-end developer - the "web-boys" (a term which probably got you the down-votes

by jlg23 11y ago

I can relate to your experience but you, just as me, seem not to be a typical front-end developer - the "web-boys" (a term which probably got you the down-votes) on the other hand are. If one asks them why they do things the way they do them, they usually have a coherent answer and are happy to explain it. As someone else pointed out in this thread, a great advantage of established frameworks is that they provide a coding standard for a team. People who do this stuff every day can easily follow the standard, understand the flow and be very productive. They did invest lots of time to learn about all those tools and libraries and probably had an overall productivity gain compared to writing native JS. If you don't really enjoy front-end development, and your comment reads like you don't, get on your high horse and join me for a ride while the "web-boys" make our hacked UIs usable for end-users and maintainable for the next "web-boys" who have to hack on it. When we get back we'll probably be very grateful for a great UI(X). ;)

exodust 11y ago
> "They did invest lots of time to learn about all those tools and libraries" Unfortunately that claim doesn't hold up to what I suspect is happening most of the time. At least in my experience at work I've seen tech leads or someone similar introduce frameworks without so much as "apparently it's quite good, so let's use it". One case in particular, Angular was chosen and turned out not to be suitable - it ran very slowly with the tasks it was chosen to do in the browser on a particularly busy web page. Learning the limitations of Angular would have gone a long way to avoiding the poor result. Not enough learning, too much embracing shiny new things.
- jlg23 11y ago
  > introduce frameworks without so much as "apparently it's quite good, so let's use it" And if they all want to use it - let them use it. The productivity gained by agreeing on a framework usually outweighs the performance loss over the "best" solution. Yes, my native JS implementation of a gallery app is much faster than the React version (reviewed by an experienced React-dev and judged "good") but if that project goes public and other people have to work on it I'll be damned if I make them learn my way of doing things. I'd expect these devs to implement a feature quickly and that means they use the framework they are most comfortable with. If it is good enough, it is good enough. Aiming for perfection killed way too many projects, accepting that the productive path is not always the nicest or cleanest (according to some arbitrary metric) is what makes projects succeed. e.g.: Writing perl code is definitely not the best thing to do, performance wise (when counting clock cycles), but it does (did) allow some folks to be incredibly successful. See this awesome essay of this very site's founder: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
  - exodust 11y ago
    Good point. Team unity and shared understanding of the methods, I'm all for that. Personally I consider everything and don't rule anything out. I wouldn't rule out be-spoke is my main argument. It's just that, you know, life can be more rewarding if you not only aim for perfection or near-perfection, but achieve it. There's a philosophical angle here that may be more suited to the start-ups thinking and dreaming big and original, vs the company who just wants "something that works/MVP".
    - jlg23 11y ago
      > life can be more rewarding if you not only aim for perfection or near-perfection, but achieve it I do that with my own software in my spare time, but from an economic point of view I cannot justify to spend that time when working for someone else. And since projects are always evolving also in requirements "perfection" is a moving target.
  - fsloth 11y ago
    " I'd expect these devs to implement a feature quickly " Isn't that basic sin of software development - weighing speed of implementation (which is just a tiny part of the lifetime cost of software) over anything else. I'm not arguing against 'good enough', I just don't think this is a particularly strong argument for that. It's like surgeon not washing his hands and sterilizing his equipment because that way implementing the surgery takes less effort.
    - jlg23 11y ago
      "lifetime cost of software" means what? 99% of the software we write is obsolete within 2 years. We should not confuse big enterprise, long term support software with modern web development. IMHO, if you want to invest into software viable on the long term, rather spend your time writing functional tests and good documentation so the current implementation can easily be replaced with a new one that uses the then hip framework. EDIT, to make my point clear: The surgeon comparison is not valid because a surgeon deals with a much longer lifetime than not only the average but most software projects.
- josephcooney 11y ago
  Sounds like "Resume Driven Development" http://imgur.com/DQcks8ul http://imgur.com/DQcks8ul
- jerf 11y ago
  "At least in my experience at work I've seen tech leads or someone similar introduce frameworks without so much as "apparently it's quite good, so let's use it"." I completely agree. Web people quite often commit to frameworks based on their marketing copy and maybe one guy they read on the internet saying "seems pretty AWESOME after I've played with it for two days!" and a testimonial or two. Of course, I've seen development languages chosen that way, NoSQL databases chosen that way, "which Linux variant do we base our company on" chosen that way, bug trackers chosen that way, chat systems chosen that way, devops management chosen that way, VM and/or containerization chosen that way (or, indeed, people just declaring "we need containers" for what appears to be "because we aren't cool if we don't have them")... you know, this may not really be just a "web" thing....
  - neppo 11y ago
    Serious question: How else can you adopt a new technology, without investing significant amount of time? It would be nice to exhaustively explore a tech before using it, but that's often simply not feasible due to lack of resources.
    - jerf 11y ago
      There's a range of options between "I watched an hour video and saw a cool demo" and "I invested six months into prototyping and testing the tech before I chose it." I mean, that really ought to answer your question, but to be concrete: Never bet anything but maybe your startup on a tech that you can't find anybody else your size trying out. Try searching "$TECH sucks" and similar queries on the Internet. If you can't find anything, that's not a sign the tech is too awesome to have flaws... it's a sign nobody's using it! Of course, you need to learn how to balance the hype vs. the "sucks" options. The question is not whether somebody has something bad to say, the question is what bad things they say. Are they clearly using it wrong? Are they clearly using it in a use case the software doesn't even claim to support? Or... are they using it in exactly your use case in exactly the way you wanted to use it and encountered fundamental problems? Even once you think you've settled on a choice, what other choices are there? The existence of a "good" choice does not preclude better choices. If you do do a test deployment, don't fall into the trap of deploying at a radically smaller size than you need. If you're going to need the tech to work in clustered mode, for instance, don't deploy it to a single server and deploy three records to it. Deploy it in a cluster mode and load it up with 10-100x times the data you think it's going to have. You can't practically test the complexity of the app you wan to write without actually writing it, but you usually can test the size. Test your most complicated case; if you've got a web app and you want a framework to help you out, don't make the simple "user prefs" page, as soon as you can start working on the most complicated page in the site, which is probably the one that's the payload. Easy things being easy isn't an interesting test; check the hard things. Find someone with a experience-hardened intuition to do this with you. Realize that any tiny issue you experience and can't get through now will become a large issue later. Realize that you generally always end up with some of those issues anyhow, so it's a question of picking which you go with. Don't underestimate the established choices. They're big for a reason, especially if they've been around for years. The new hotness will play up the old guard's flaws while minimizing their own. You can make anything look good by only considering the positives, you can make anything look bad by only considering the negatives. Always look at both for all options. Get that experienced person to help you through it. For whatever task it is you are looking to do, figure out which problems you are most likely to have, and prioritize your analysis to focus on those. Do you know you need total CP consistency? Then you can quickly eliminate entire choices by whether they even claim it, and further eliminate more by checking whether they actually maintain it in the field on their user fora. Do you have price constraints? Bam, entire choices knocked out. I've never personally been in the situation where I got to the point where I needed to start kicking tires and I had a dozen equally-good choices; there was always a clear hierarchy. And, in the end, do consider the joy-of-use of a tech... just don't make it your only consideration. An fun-to-use tech that completely fails to solve your problems rapidly becomes a nightmare-to-use tech anyhow. Ask around you about framework regret; anybody with a few years in should have at least one story of when they expected something to be awesome and it wasn't. Even putting a week into something as important as "what database will we choose" can pay off huge, easily being the difference between project success or failure. You don't necessarily need to work everything out for months.
mbrutsch 11y ago
> As someone else pointed out in this thread, a great advantage of established frameworks is that they provide a coding standard for a team. So it's useful for young, inexperienced developers. Do you kids really not have in-house coding standards anymore, or do you rely on your toolsets to provide that for you?
- sbarre 11y ago
  A counter-point to your argument: In-house coding standards smells a little bit of NIH syndrome. Odds are good that even if you are not a "young, inexperienced" developer, widely-adopted coding standards (that most frameworks probably use) have had more thought and reasoning put into them than you would ever be able to do on your own. So I agree with your overall point of "don't just blindly adopt something", but the case can be also made for not naively doing everything your own personal way (including at the team/company level). For example, "go fmt" exists for a reason.
  - mbrutsch 11y ago
    > naively doing everything your own personal way (including at the team/company level). You, and my downvoters, all assume (naively) that any in-house standard must somehow be different than "widely-adopted coding standards (that most frameworks probably use)". Obviously, that need not be true, and in my limited 40 years of experience, it rarely is. Not sure how you even got there.
    - sbarre 11y ago
      I actually upvoted you, for the record. But you drew a distinction between "in-house standards" and "the framework's standards" (which are by definition probably taken from widely adopted standards). If you were implying that those two things might be identical then you did a bad job of conveying that (and then why even comment?)
      - mbrutsch 11y ago
        > I actually upvoted you, for the record. That's why I said "you and my downvoters", rather than "you and my other downvoters". I am apparently very bad at making simple points. > But you drew a distinction between "in-house standards" and "the framework's standards" One is used in-house for all things relevant, one applies to a framework. In that, they are distinct. > (which are by definition probably taken from widely adopted standards). Probably. > If you were implying that those two things might be identical then you did a bad job of conveying that. sigh. Two things can be true at the same time. I give up.
mattmanser 11y ago
They're not a standard though. Everything's only a year old and gets replaced next year. Where's Backbone gone? Or Knockout? Or Handlebars? Is it NPM, Bower or a mix of the two? Or etc. etc. Are you writing coffeescript still, why not typescript? Did you make an app in Durandal? Haha! Time for Aurelia! Angular 1, one of the longer lived projects, is literally just being turned into a non-standard after a whole lifetime of about that of the family hamster. So they're not standards, they're all today's hotness that won't be used on tomorrows projects. It takes a couple of years for coding standards in new languages and libraries to even evolve, no-one knows how to use it properly to begin with and everyone makes a mess in a different way as they deal with the quirks and build non-trivial projects, but eventually a consensus is born. In JS frameworks, just as that is happening, the whole thing is abandoned rapidly for the new hotness.
- nilliams 11y ago
  Just want to be the counterpoint here. I've been building stuff at my last 2 jobs in Backbone (plus good OOP) for the last 5 years, and am only now considering a move to React or Vue, Vue being the conservative choice I may well go with. Not everyone jumps on the new frameworks just because. The JS community is massive and very good at publicising their tools, so there are lots of (very visible) options, and it can give the impression that everyone is constantly switching tools, but that doesn't mean you actually have to.
- maaaats 11y ago
  That doesn't invalidate the point, though. I'd rather maintain an old Backbone app, where I can read tutorials and search SO for answer, than some home-made framework.

by jlg23 11y ago

exodust 11y ago

> "They did invest lots of time to learn about all those tools and libraries" Unfortunately that claim doesn't hold up to what I suspect is happening most of the time. At least in my experience at work I've seen tech leads or someone similar introduce frameworks without so much as "apparently it's quite good, so let's use it". One case in particular, Angular was chosen and turned out not to be suitable - it ran very slowly with the tasks it was chosen to do in the browser on a particularly busy web page. Learning the limitations of Angular would have gone a long way to avoiding the poor result. Not enough learning, too much embracing shiny new things.

jlg23 11y ago
> introduce frameworks without so much as "apparently it's quite good, so let's use it" And if they all want to use it - let them use it. The productivity gained by agreeing on a framework usually outweighs the performance loss over the "best" solution. Yes, my native JS implementation of a gallery app is much faster than the React version (reviewed by an experienced React-dev and judged "good") but if that project goes public and other people have to work on it I'll be damned if I make them learn my way of doing things. I'd expect these devs to implement a feature quickly and that means they use the framework they are most comfortable with. If it is good enough, it is good enough. Aiming for perfection killed way too many projects, accepting that the productive path is not always the nicest or cleanest (according to some arbitrary metric) is what makes projects succeed. e.g.: Writing perl code is definitely not the best thing to do, performance wise (when counting clock cycles), but it does (did) allow some folks to be incredibly successful. See this awesome essay of this very site's founder: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
- exodust 11y ago
  Good point. Team unity and shared understanding of the methods, I'm all for that. Personally I consider everything and don't rule anything out. I wouldn't rule out be-spoke is my main argument. It's just that, you know, life can be more rewarding if you not only aim for perfection or near-perfection, but achieve it. There's a philosophical angle here that may be more suited to the start-ups thinking and dreaming big and original, vs the company who just wants "something that works/MVP".
  - jlg23 11y ago
    > life can be more rewarding if you not only aim for perfection or near-perfection, but achieve it I do that with my own software in my spare time, but from an economic point of view I cannot justify to spend that time when working for someone else. And since projects are always evolving also in requirements "perfection" is a moving target.
- fsloth 11y ago
  " I'd expect these devs to implement a feature quickly " Isn't that basic sin of software development - weighing speed of implementation (which is just a tiny part of the lifetime cost of software) over anything else. I'm not arguing against 'good enough', I just don't think this is a particularly strong argument for that. It's like surgeon not washing his hands and sterilizing his equipment because that way implementing the surgery takes less effort.
  - jlg23 11y ago
    "lifetime cost of software" means what? 99% of the software we write is obsolete within 2 years. We should not confuse big enterprise, long term support software with modern web development. IMHO, if you want to invest into software viable on the long term, rather spend your time writing functional tests and good documentation so the current implementation can easily be replaced with a new one that uses the then hip framework. EDIT, to make my point clear: The surgeon comparison is not valid because a surgeon deals with a much longer lifetime than not only the average but most software projects.
josephcooney 11y ago
Sounds like "Resume Driven Development" http://imgur.com/DQcks8ul http://imgur.com/DQcks8ul
jerf 11y ago
"At least in my experience at work I've seen tech leads or someone similar introduce frameworks without so much as "apparently it's quite good, so let's use it"." I completely agree. Web people quite often commit to frameworks based on their marketing copy and maybe one guy they read on the internet saying "seems pretty AWESOME after I've played with it for two days!" and a testimonial or two. Of course, I've seen development languages chosen that way, NoSQL databases chosen that way, "which Linux variant do we base our company on" chosen that way, bug trackers chosen that way, chat systems chosen that way, devops management chosen that way, VM and/or containerization chosen that way (or, indeed, people just declaring "we need containers" for what appears to be "because we aren't cool if we don't have them")... you know, this may not really be just a "web" thing....
- neppo 11y ago
  Serious question: How else can you adopt a new technology, without investing significant amount of time? It would be nice to exhaustively explore a tech before using it, but that's often simply not feasible due to lack of resources.
  - jerf 11y ago
    There's a range of options between "I watched an hour video and saw a cool demo" and "I invested six months into prototyping and testing the tech before I chose it." I mean, that really ought to answer your question, but to be concrete: Never bet anything but maybe your startup on a tech that you can't find anybody else your size trying out. Try searching "$TECH sucks" and similar queries on the Internet. If you can't find anything, that's not a sign the tech is too awesome to have flaws... it's a sign nobody's using it! Of course, you need to learn how to balance the hype vs. the "sucks" options. The question is not whether somebody has something bad to say, the question is what bad things they say. Are they clearly using it wrong? Are they clearly using it in a use case the software doesn't even claim to support? Or... are they using it in exactly your use case in exactly the way you wanted to use it and encountered fundamental problems? Even once you think you've settled on a choice, what other choices are there? The existence of a "good" choice does not preclude better choices. If you do do a test deployment, don't fall into the trap of deploying at a radically smaller size than you need. If you're going to need the tech to work in clustered mode, for instance, don't deploy it to a single server and deploy three records to it. Deploy it in a cluster mode and load it up with 10-100x times the data you think it's going to have. You can't practically test the complexity of the app you wan to write without actually writing it, but you usually can test the size. Test your most complicated case; if you've got a web app and you want a framework to help you out, don't make the simple "user prefs" page, as soon as you can start working on the most complicated page in the site, which is probably the one that's the payload. Easy things being easy isn't an interesting test; check the hard things. Find someone with a experience-hardened intuition to do this with you. Realize that any tiny issue you experience and can't get through now will become a large issue later. Realize that you generally always end up with some of those issues anyhow, so it's a question of picking which you go with. Don't underestimate the established choices. They're big for a reason, especially if they've been around for years. The new hotness will play up the old guard's flaws while minimizing their own. You can make anything look good by only considering the positives, you can make anything look bad by only considering the negatives. Always look at both for all options. Get that experienced person to help you through it. For whatever task it is you are looking to do, figure out which problems you are most likely to have, and prioritize your analysis to focus on those. Do you know you need total CP consistency? Then you can quickly eliminate entire choices by whether they even claim it, and further eliminate more by checking whether they actually maintain it in the field on their user fora. Do you have price constraints? Bam, entire choices knocked out. I've never personally been in the situation where I got to the point where I needed to start kicking tires and I had a dozen equally-good choices; there was always a clear hierarchy. And, in the end, do consider the joy-of-use of a tech... just don't make it your only consideration. An fun-to-use tech that completely fails to solve your problems rapidly becomes a nightmare-to-use tech anyhow. Ask around you about framework regret; anybody with a few years in should have at least one story of when they expected something to be awesome and it wasn't. Even putting a week into something as important as "what database will we choose" can pay off huge, easily being the difference between project success or failure. You don't necessarily need to work everything out for months.

mbrutsch 11y ago

> As someone else pointed out in this thread, a great advantage of established frameworks is that they provide a coding standard for a team. So it's useful for young, inexperienced developers. Do you kids really not have in-house coding standards anymore, or do you rely on your toolsets to provide that for you?

sbarre 11y ago
A counter-point to your argument: In-house coding standards smells a little bit of NIH syndrome. Odds are good that even if you are not a "young, inexperienced" developer, widely-adopted coding standards (that most frameworks probably use) have had more thought and reasoning put into them than you would ever be able to do on your own. So I agree with your overall point of "don't just blindly adopt something", but the case can be also made for not naively doing everything your own personal way (including at the team/company level). For example, "go fmt" exists for a reason.
- mbrutsch 11y ago
  > naively doing everything your own personal way (including at the team/company level). You, and my downvoters, all assume (naively) that any in-house standard must somehow be different than "widely-adopted coding standards (that most frameworks probably use)". Obviously, that need not be true, and in my limited 40 years of experience, it rarely is. Not sure how you even got there.
  - sbarre 11y ago
    I actually upvoted you, for the record. But you drew a distinction between "in-house standards" and "the framework's standards" (which are by definition probably taken from widely adopted standards). If you were implying that those two things might be identical then you did a bad job of conveying that (and then why even comment?)
    - mbrutsch 11y ago
      > I actually upvoted you, for the record. That's why I said "you and my downvoters", rather than "you and my other downvoters". I am apparently very bad at making simple points. > But you drew a distinction between "in-house standards" and "the framework's standards" One is used in-house for all things relevant, one applies to a framework. In that, they are distinct. > (which are by definition probably taken from widely adopted standards). Probably. > If you were implying that those two things might be identical then you did a bad job of conveying that. sigh. Two things can be true at the same time. I give up.

mattmanser 11y ago

They're not a standard though. Everything's only a year old and gets replaced next year. Where's Backbone gone? Or Knockout? Or Handlebars? Is it NPM, Bower or a mix of the two? Or etc. etc. Are you writing coffeescript still, why not typescript? Did you make an app in Durandal? Haha! Time for Aurelia! Angular 1, one of the longer lived projects, is literally just being turned into a non-standard after a whole lifetime of about that of the family hamster. So they're not standards, they're all today's hotness that won't be used on tomorrows projects. It takes a couple of years for coding standards in new languages and libraries to even evolve, no-one knows how to use it properly to begin with and everyone makes a mess in a different way as they deal with the quirks and build non-trivial projects, but eventually a consensus is born. In JS frameworks, just as that is happening, the whole thing is abandoned rapidly for the new hotness.

nilliams 11y ago
Just want to be the counterpoint here. I've been building stuff at my last 2 jobs in Backbone (plus good OOP) for the last 5 years, and am only now considering a move to React or Vue, Vue being the conservative choice I may well go with. Not everyone jumps on the new frameworks just because. The JS community is massive and very good at publicising their tools, so there are lots of (very visible) options, and it can give the impression that everyone is constantly switching tools, but that doesn't mean you actually have to.
maaaats 11y ago
That doesn't invalidate the point, though. I'd rather maintain an old Backbone app, where I can read tutorials and search SO for answer, than some home-made framework.