4 ms·

IMHO the way to achieve this is to pay the upfront cost of building out a small framework for your application, which has lightweight abstractions for common pa

IMHO the way to achieve this is to pay the upfront cost of building out a small framework for your application, which has lightweight abstractions for common patterns. With some design, a small internal API can be as nice to work with as the kitchen sink abstractions. (Much nicer, too, when it comes to maintenance and debugging.)

KronisLV 2y ago
> IMHO the way to achieve this is to pay the upfront cost of building out a small framework for your application And then 5 years down the line it has grown into a worse version of the popular alternatives, the original developers are gone and the ones who currently maintain the mess have to pay the price. In corporate or professional contexts, you probably just should pick whatever is popular. Though that anecdote about risk management should also have this link alongside it: https://www.robinsloan.com/notes/home-cooked-app/ https://www.robinsloan.com/notes/home-cooked-app/ When you’re working on something others won’t have to maintain years down the line, thankfully your hands aren’t tied then and you can have a bit more fun. For everything else? Svelte, HTMX, jQuery, Vue, React, Angular or whatever else makes sense. That said, sometimes I wonder what a world would look like, where the browser would have the most popular options pre-packaged in a way where you wouldn’t need to download hundreds of KB in each site you visit, but you’d get the packages with browser updates. It’d probably save petabytes of data. Except seems like we went in the opposite direction, with even CDNs being less efficient in some ways: https://httptoolkit.com/blog/public-cdn-risks/ https://httptoolkit.com/blog/public-cdn-risks/
- skydhash 2y ago
  The thing is that while your application is working well, the library authors would have moved on and it's up to you to upgrade your application and fix breaking changes. At least with an in-house framework, it's always morphing into something that the company needs. Not saying that there aren't nicer framework, but it's always someone agenda that has aligned with yours at the time of selection.
  - KronisLV 2y ago
    > The thing is that while your application is working well, the library authors would have moved on and it's up to you to upgrade your application and fix breaking changes. AngularJS is actually a pretty good argument to support your point, I had to migrate an app off of it (we picked Vue as the successor) and it was quite the pain, because a lot of the code was already a bit messy and the concepts don't carry over all that nicely, especially if you want something quite close to the old implementation, functionality wise. On the other hand, jQuery just seems to be trucking along throughout the years. There are cases like Vue 2 to Vue 3 migrations which can also have growing pains, but I think that the likes of Vue, React and Angular are generally unlikely to be abandoned, even with growing pains along the way. In that regard, your job as a developer is probably to pick whatever might have the least amount of surprises, the most longevity and the lowest chance of you having to maintain it yourself and instead being able to coast off of the work of others (and maybe contributing, if you have the time), with the project having hundreds if not thousands of contributors, which will often be better than what a few people within any given org could achieve. Sometimes that might even be reaching for something like SSR instead of making SPAs, depending on what you can get away with. One can probably talk about Boring Technology or Lindy effect here.
    - lelanthran 2y ago
      I think, in view of my previous comment which was made prior to reading this refinement of yours, that it all very much depends on whether you are choosing something that is designed to be replaced vs something that is not. Sorta along the lines of the mantra "Don't design your code for extendability, design it for replaceability" (not sure where I read that). > with the project having hundreds if not thousands of contributors, which will often be better than what a few people within any given org could achieve. The upside of "what a few people within the org could achieve" is that a couple of devs spending a few weeks on a project are never going to make something that cannot also be replaced by a different couple of developers of a similar timeframe. IOW, small efforts are two-way doors; large efforts (thousands of contributors over 5 years) are effectively one-way doors.
      - 2y ago
- lelanthran 2y ago
  > And then 5 years down the line it has grown into a worse version of the popular alternatives, the original developers are gone and the ones who currently maintain the mess have to pay the price. Isn't that true for using the popular alternative too? At some point the original devs have moved on from $FRAMEWORK v1 to $FRAMEWORK v2 and now you're going to have to do a migration project and hope it doesn't break. > When you’re working on something others won’t have to maintain years down the line, thankfully your hands aren’t tied then and you can have a bit more fun. I think the implication is, with the in-house library, that the in-house library would be a lot easier to replace or update than a deprecated external alternative. IMO, it's all very contextual.
  - sensanaty 2y ago
    No one's forcing you to upgrade when the framework does. We still have a Vue 2.7 codebase chugging along just fine and won't upgrade it unless truly necessary.
    - 1dom 2y ago
      > No one's forcing you to upgrade when the framework does. Many large companies have entire departments dedicated to forcing you to keep your code up to date.
      - Capricorn2481 2y ago
        If you're working for that kind of company then you certainly aren't getting a choice whether to use JQuery or React.
        lelanthran 2y ago
        > If you're working for that kind of company then you certainly aren't getting a choice whether to use JQuery or React. Not necessarily. There is probably a tickbox for satisfying some regulation that says "Don't use versions that aren't getting security fixes anymore". In which case, yes, you get the choice to choose between JQuery and $SOMETHING_ELSE but not the choice to remain on unsupported versions of anything.

KronisLV 2y ago

> IMHO the way to achieve this is to pay the upfront cost of building out a small framework for your application And then 5 years down the line it has grown into a worse version of the popular alternatives, the original developers are gone and the ones who currently maintain the mess have to pay the price. In corporate or professional contexts, you probably just should pick whatever is popular. Though that anecdote about risk management should also have this link alongside it: https://www.robinsloan.com/notes/home-cooked-app/ https://www.robinsloan.com/notes/home-cooked-app/ When you’re working on something others won’t have to maintain years down the line, thankfully your hands aren’t tied then and you can have a bit more fun. For everything else? Svelte, HTMX, jQuery, Vue, React, Angular or whatever else makes sense. That said, sometimes I wonder what a world would look like, where the browser would have the most popular options pre-packaged in a way where you wouldn’t need to download hundreds of KB in each site you visit, but you’d get the packages with browser updates. It’d probably save petabytes of data. Except seems like we went in the opposite direction, with even CDNs being less efficient in some ways: https://httptoolkit.com/blog/public-cdn-risks/ https://httptoolkit.com/blog/public-cdn-risks/

skydhash 2y ago
The thing is that while your application is working well, the library authors would have moved on and it's up to you to upgrade your application and fix breaking changes. At least with an in-house framework, it's always morphing into something that the company needs. Not saying that there aren't nicer framework, but it's always someone agenda that has aligned with yours at the time of selection.
- KronisLV 2y ago
  > The thing is that while your application is working well, the library authors would have moved on and it's up to you to upgrade your application and fix breaking changes. AngularJS is actually a pretty good argument to support your point, I had to migrate an app off of it (we picked Vue as the successor) and it was quite the pain, because a lot of the code was already a bit messy and the concepts don't carry over all that nicely, especially if you want something quite close to the old implementation, functionality wise. On the other hand, jQuery just seems to be trucking along throughout the years. There are cases like Vue 2 to Vue 3 migrations which can also have growing pains, but I think that the likes of Vue, React and Angular are generally unlikely to be abandoned, even with growing pains along the way. In that regard, your job as a developer is probably to pick whatever might have the least amount of surprises, the most longevity and the lowest chance of you having to maintain it yourself and instead being able to coast off of the work of others (and maybe contributing, if you have the time), with the project having hundreds if not thousands of contributors, which will often be better than what a few people within any given org could achieve. Sometimes that might even be reaching for something like SSR instead of making SPAs, depending on what you can get away with. One can probably talk about Boring Technology or Lindy effect here.
  - lelanthran 2y ago
    I think, in view of my previous comment which was made prior to reading this refinement of yours, that it all very much depends on whether you are choosing something that is designed to be replaced vs something that is not. Sorta along the lines of the mantra "Don't design your code for extendability, design it for replaceability" (not sure where I read that). > with the project having hundreds if not thousands of contributors, which will often be better than what a few people within any given org could achieve. The upside of "what a few people within the org could achieve" is that a couple of devs spending a few weeks on a project are never going to make something that cannot also be replaced by a different couple of developers of a similar timeframe. IOW, small efforts are two-way doors; large efforts (thousands of contributors over 5 years) are effectively one-way doors.
    - 2y ago
lelanthran 2y ago
> And then 5 years down the line it has grown into a worse version of the popular alternatives, the original developers are gone and the ones who currently maintain the mess have to pay the price. Isn't that true for using the popular alternative too? At some point the original devs have moved on from $FRAMEWORK v1 to $FRAMEWORK v2 and now you're going to have to do a migration project and hope it doesn't break. > When you’re working on something others won’t have to maintain years down the line, thankfully your hands aren’t tied then and you can have a bit more fun. I think the implication is, with the in-house library, that the in-house library would be a lot easier to replace or update than a deprecated external alternative. IMO, it's all very contextual.
- sensanaty 2y ago
  No one's forcing you to upgrade when the framework does. We still have a Vue 2.7 codebase chugging along just fine and won't upgrade it unless truly necessary.
  - 1dom 2y ago
    > No one's forcing you to upgrade when the framework does. Many large companies have entire departments dedicated to forcing you to keep your code up to date.
    - Capricorn2481 2y ago
      If you're working for that kind of company then you certainly aren't getting a choice whether to use JQuery or React.
      - lelanthran 2y ago
        > If you're working for that kind of company then you certainly aren't getting a choice whether to use JQuery or React. Not necessarily. There is probably a tickbox for satisfying some regulation that says "Don't use versions that aren't getting security fixes anymore". In which case, yes, you get the choice to choose between JQuery and $SOMETHING_ELSE but not the choice to remain on unsupported versions of anything.