4 ms·

Maybe (I would instinctively agree). But amount of code is not a good metric for almost anything. What about amount of features? Time to ship? Time between rel

Maybe (I would instinctively agree). But amount of code is not a good metric for almost anything. What about amount of features? Time to ship? Time between releases? Number of bugs? User satisfaction? Development costs? ROI? Ease of hiring? Scalability? Reliability? Not particularly saying an SPA is better at the criteria above (not saying it isn't either), but these criteria are way more important than "amount of code"

collyw 8y ago
If you view code as a liability then more code is worse.
- lubonay 8y ago
  Well okay, but is it the ultimate liability? What if 2x the code gives you 10x the value?
  - collyw 8y ago
    OK, I'll expand my comment to say that "more code for the same functionality is a liability".
- polygotdomain 8y ago
  Viewing code as a liability does not make it worse, as not all code as the same level of liability associated with it. I'd much rather have double the lines of code if it yielded a code base that was more maintainable, easier to reason about, easier to debug, and had better separation of concerns.
- bunderbunder 8y ago
  This is such a thorny issue. First off, there's the reductio ad absurdum in the room: perl. Using perl, I could rip off some amazing things in amazingly little code. (Forth, too, come to think of it.) I think, though, that most of us who initially fell in love with it eventually came to learn that denser code is not necessarily better code. Nowadays I'll gladly take the same thing written in 5X as much Python code. Second, sometimes more code provides useful things, like bulkheads and seams that allow for easier modification in the future. Over in OO-land, I find that writing SOLID code often increases line counts considerably, but I still strongly prefer my code to be SOLID. Long story short, I find that code volume can be a proxy for code quality, but it's a very imperfect one.
  - williamdclt 8y ago
    > bulkheads and seams I really like those analogies, I'll reuse them!
bunderbunder 8y ago
This pokes at one of my suspicions: Personally, I agree that SPAs are way more complicated and heavyweight than you need for most sites. And they do seem to require a lot of code up-front. But it's also true that I see a lot of dissatisfaction around the long-term maintainability of doing things in basic HTML/CSS. And I'm not aware of any compelling options that give you better better modularity, but aren't some super heavy-handed SPA-centric framework like React.
- warent 8y ago
  > Personally, I agree that SPAs are way more complicated and heavyweight than you need for most sites. This hasn't been my experience at all. SPAs are so simple for me to spin up these days with all the tooling to cover the boilerplate for you, e.g. create-react-app or Vue CLI. With the advent of cloud providers, hosting is insanely simple too. You can get a working SPA out in a day complete with a frontend, backend API, and a database.
  - bunderbunder 8y ago
    The experience is definitely easy, but it's hard to believe that it's simple. Oftentimes things that are very easy on the surface have a whole lot of complexity going on under the hood. In the case of SPA frameworks, I've not spent much time with them (I'm the back end guy on my team), but the most striking things I see whenever I get involved in a project that uses them, and when I've taken the time to learn them, is that there are just so many moving parts. And a whole lot of stuff about the internal logic of whatever SPA framework you're using, and possibly how specifically you're using it, that a newcomer has to know before they can really work efficiently. They're so complicated that I sometimes see people having to do some really elaborate things to get them to play nicely with other stuff they want to do. Using D3 in the same site comes to mind there.
    - dublo7 8y ago
      I can build a whole app in only a hundred lines of code once I add a million lines of code... :)

collyw 8y ago

If you view code as a liability then more code is worse.

lubonay 8y ago
Well okay, but is it the ultimate liability? What if 2x the code gives you 10x the value?
- collyw 8y ago
  OK, I'll expand my comment to say that "more code for the same functionality is a liability".
polygotdomain 8y ago
Viewing code as a liability does not make it worse, as not all code as the same level of liability associated with it. I'd much rather have double the lines of code if it yielded a code base that was more maintainable, easier to reason about, easier to debug, and had better separation of concerns.
bunderbunder 8y ago
This is such a thorny issue. First off, there's the reductio ad absurdum in the room: perl. Using perl, I could rip off some amazing things in amazingly little code. (Forth, too, come to think of it.) I think, though, that most of us who initially fell in love with it eventually came to learn that denser code is not necessarily better code. Nowadays I'll gladly take the same thing written in 5X as much Python code. Second, sometimes more code provides useful things, like bulkheads and seams that allow for easier modification in the future. Over in OO-land, I find that writing SOLID code often increases line counts considerably, but I still strongly prefer my code to be SOLID. Long story short, I find that code volume can be a proxy for code quality, but it's a very imperfect one.
- williamdclt 8y ago
  > bulkheads and seams I really like those analogies, I'll reuse them!

bunderbunder 8y ago

This pokes at one of my suspicions: Personally, I agree that SPAs are way more complicated and heavyweight than you need for most sites. And they do seem to require a lot of code up-front. But it's also true that I see a lot of dissatisfaction around the long-term maintainability of doing things in basic HTML/CSS. And I'm not aware of any compelling options that give you better better modularity, but aren't some super heavy-handed SPA-centric framework like React.

warent 8y ago
> Personally, I agree that SPAs are way more complicated and heavyweight than you need for most sites. This hasn't been my experience at all. SPAs are so simple for me to spin up these days with all the tooling to cover the boilerplate for you, e.g. create-react-app or Vue CLI. With the advent of cloud providers, hosting is insanely simple too. You can get a working SPA out in a day complete with a frontend, backend API, and a database.
- bunderbunder 8y ago
  The experience is definitely easy, but it's hard to believe that it's simple. Oftentimes things that are very easy on the surface have a whole lot of complexity going on under the hood. In the case of SPA frameworks, I've not spent much time with them (I'm the back end guy on my team), but the most striking things I see whenever I get involved in a project that uses them, and when I've taken the time to learn them, is that there are just so many moving parts. And a whole lot of stuff about the internal logic of whatever SPA framework you're using, and possibly how specifically you're using it, that a newcomer has to know before they can really work efficiently. They're so complicated that I sometimes see people having to do some really elaborate things to get them to play nicely with other stuff they want to do. Using D3 in the same site comes to mind there.
  - dublo7 8y ago
    I can build a whole app in only a hundred lines of code once I add a million lines of code... :)