5 ms·

I'll offer up another reason, which I feel is a little more accurate: * Your web app requires heavily interactive bits, such as smart forms, smart tables, prev

I'll offer up another reason, which I feel is a little more accurate: * Your web app requires heavily interactive bits, such as smart forms, smart tables, previews, content editing, etc. To deliver such functionality in a maintainable way, you use a framework. (As a side note, yes it is possible to deliver this functionality in vanilla JS, but to make it maintainable one must essentially build an ad hoc framework.) Because most frameworks push users towards a SPA, you end up following the path of least resistance and developing a SPA.

austincheney 6y ago
I would argue most websites never require any of those. When any of those are required they don’t need a giant framework to achieve maintainability. All that’s needed to achieve maintainability is a competent developer who values both simplicity and written documentation.
- nepeckman 6y ago
  This sentiment frustrates me. The majority of web developers today are application developers. I've spent the past 5 years delivering business applications via the web as a platform. The web has a lot of advantage as a platform: no install, cross platform, networked by default. But the web was not designed as an application platform, so making it into one is complex. Business applications have inherent complexity as well, and managing all that complexity is a non trivial task. Posts like this frustrate me because you seem to be suggesting complexity in the web domain is largely incidental.
  - hootbootscoot 6y ago
    I would qualify this: The web is simple when one uses it as intended. (hyperlinked documents that may or may not have interactivity beyond the hyperlinking and embedded media or animations etc.) The web is complex when one attempts to do "GUI by RPC". If one is OK with page reloads, this asynch remote folder browser hypercard thingy is fine. If one seeks to replicate the event-loop desktop "window"-based application one will have the use-case for large frameworks as one will literally be re-inventing all the wheels, which they tend to do, as this is not the default behavior of the application we call a web browser.
  - austincheney 6y ago
    Complexity in web products is largely the result of developers who don’t care because they need to ship a product only if that product is written in an extremely familiar way. That’s a product of people who don’t know what they are doing opposed to inherent technological impediments. I form this opinion as a professional web developer with 20 years experience.
    - nepeckman 6y ago
      I respect your experience, but that does not match up with what I've seen, and what I've seen by proxy networking with other developers in my area. I do personally think simplicity is a virtue. I always try to collaborate with our business team to deliver only what is needed, in the most straightforward way. But if the customer needs a 20 field form, with logical dependencies and validation between fields, as well as an interface for searching/filtering/editing entries, there is only so much that can be simplified. And yes I know all of that can be done with vanilla JS, but I've done it both ways and I prefer the framework.
      - kingdomcome50 6y ago
        Just to chime in here. To be clear, I think dropping a vdom implementation into a page is a good middle ground between full blown “framework” and “roll your own js”. I’m not familiar with vue, but I’ve used React (a library!) to great effect on pages that require that extra bump of behavior. It’s such a shame that many of these tools are pushed as large SPA solutions when they can just as easily be included ad-hoc over a CDN when necessary. * And I agree that it’s just madness to wire up your own components once the use case becomes anything more than the most trivial behaviors.
      - austincheney 6y ago
        I doubt your customer specified dependencies as a business requirement.
        nepeckman 6y ago
        I always enjoy a good faith discussion, but if you aren't going to respond to what I actually wrote there's no need to continue this. I _know_ the functionality I mentioned can be shipped without a framework. I _have_ shipped web apps without a framework. I've personally found the overhead of designing and enforcing an ad hoc framework to be not worth the effort.
hootbootscoot 6y ago
...almost... i'll accept "an SPA on one server-side route for that one complicated page that's full of bells and whistles." and then I'm still going to say "yeah, i'm roughly equally verbose and spaghetti-like in even the best most prescient framework from the gods themselves" and merely wish for the means of modularization: breaking my server- rendered page that my javascript "unfolds from" into further little bits that can each have their own smaller less-spaghetti like world without having to try to dynamically load and include javascript on the client. Break it up. Divide et impera...

austincheney 6y ago

I would argue most websites never require any of those. When any of those are required they don’t need a giant framework to achieve maintainability. All that’s needed to achieve maintainability is a competent developer who values both simplicity and written documentation.

nepeckman 6y ago
This sentiment frustrates me. The majority of web developers today are application developers. I've spent the past 5 years delivering business applications via the web as a platform. The web has a lot of advantage as a platform: no install, cross platform, networked by default. But the web was not designed as an application platform, so making it into one is complex. Business applications have inherent complexity as well, and managing all that complexity is a non trivial task. Posts like this frustrate me because you seem to be suggesting complexity in the web domain is largely incidental.
- hootbootscoot 6y ago
  I would qualify this: The web is simple when one uses it as intended. (hyperlinked documents that may or may not have interactivity beyond the hyperlinking and embedded media or animations etc.) The web is complex when one attempts to do "GUI by RPC". If one is OK with page reloads, this asynch remote folder browser hypercard thingy is fine. If one seeks to replicate the event-loop desktop "window"-based application one will have the use-case for large frameworks as one will literally be re-inventing all the wheels, which they tend to do, as this is not the default behavior of the application we call a web browser.
- austincheney 6y ago
  Complexity in web products is largely the result of developers who don’t care because they need to ship a product only if that product is written in an extremely familiar way. That’s a product of people who don’t know what they are doing opposed to inherent technological impediments. I form this opinion as a professional web developer with 20 years experience.
  - nepeckman 6y ago
    I respect your experience, but that does not match up with what I've seen, and what I've seen by proxy networking with other developers in my area. I do personally think simplicity is a virtue. I always try to collaborate with our business team to deliver only what is needed, in the most straightforward way. But if the customer needs a 20 field form, with logical dependencies and validation between fields, as well as an interface for searching/filtering/editing entries, there is only so much that can be simplified. And yes I know all of that can be done with vanilla JS, but I've done it both ways and I prefer the framework.
    - kingdomcome50 6y ago
      Just to chime in here. To be clear, I think dropping a vdom implementation into a page is a good middle ground between full blown “framework” and “roll your own js”. I’m not familiar with vue, but I’ve used React (a library!) to great effect on pages that require that extra bump of behavior. It’s such a shame that many of these tools are pushed as large SPA solutions when they can just as easily be included ad-hoc over a CDN when necessary. * And I agree that it’s just madness to wire up your own components once the use case becomes anything more than the most trivial behaviors.
    - austincheney 6y ago
      I doubt your customer specified dependencies as a business requirement.
      - nepeckman 6y ago
        I always enjoy a good faith discussion, but if you aren't going to respond to what I actually wrote there's no need to continue this. I _know_ the functionality I mentioned can be shipped without a framework. I _have_ shipped web apps without a framework. I've personally found the overhead of designing and enforcing an ad hoc framework to be not worth the effort.

hootbootscoot 6y ago

...almost... i'll accept "an SPA on one server-side route for that one complicated page that's full of bells and whistles." and then I'm still going to say "yeah, i'm roughly equally verbose and spaghetti-like in even the best most prescient framework from the gods themselves" and merely wish for the means of modularization: breaking my server- rendered page that my javascript "unfolds from" into further little bits that can each have their own smaller less-spaghetti like world without having to try to dynamically load and include javascript on the client. Break it up. Divide et impera...