4 ms·

I don't want to say "anti-pattern" because that's not what I mean... But new tech should be the last resort. If nothing stable, decades old, and well document

by bgroat 6y ago

I don't want to say "anti-pattern" because that's not what I mean... But new tech should be the last resort. If nothing stable, decades old, and well documented can solve the problem then reach for hot new-ness

Retric 6y ago
That’s a little far, old doesn’t mean good. The bleeding edge often gets abandoned, but tech has generally been improving over time. IMO, the sweet spot starts when something was a fad ~5 years ago and is still reasonably popular.
- DaiPlusPlus 6y ago
  > IMO, the sweet spot starts when something was a fad ~5 years ago and is still reasonably popular. That would mean it's okay to use Angular today, but dev trends (and Google's support "policy") would advise against that.
  - yen223 6y ago
    A good reason to wait a few years is precisely so that we have a clearer picture of what strengths and deficiencies a piece of tech brings to the table, especially out in the real world. We have a good picture of how Angular and React works in production now. We cannot say the same for something like Svelte.
    - fpoling 6y ago
      React is far from being stable. It deprecated a lot older API, added entirely new concept of hooks. If one wants stability, then PHP has a way better track record.
      - scrollaway 6y ago
        Nonsense. React is extremely stable. It indeed added hooks, deprecating exactly nothing in doing so. React deprecations are very few and far between.
        DaiPlusPlus 6y ago
        > deprecating exactly nothing in doing so De jure deprecation, correct - but reading between the lines in Facebook's own blog article that introduced Hooks ( https://reactjs.org/docs/hooks-intro.html https://reactjs.org/docs/hooks-intro.html ), which put a bit too much emphasis on "There are no plans to remove classes from React.", which to me means they're definitely going to be deprecating class-based controls in the future.
        notriddle 6y ago
        I can see three possible universes here, all of which end on everyone assuming that classes are going to be removed from React. > There are no plans to remove classes from React. They're totally going to remove classes from React. > We are going to remove classes from React. They're obviously going to remove classes from React. > No comment. They're totally going to remove classes from React.
nicoburns 6y ago
> If nothing stable, decades old, and well documented can solve the problem then reach for hot new-ness I think it's a little more nuanced than that. Usually the older technology is more stable and better documented. But not always. Sometimes the new hotness is the new hotness precisely because it's better in these kind of categories.
- bgroat 6y ago
  You and Retric are right. I'm imagining a checklist of: - Stable - Well Documented - Age In descending order of importance. When choosing between any technology choose the one that is most stable. If multiple options are on a stable release, choose the one that is best documented. If multiple stable releases have excellent documentation, choose whichever is oldest. I don't think this framework is always (or even often) right. But it works for me
  - makapuf 6y ago
    My checklist would be (I'm eager to know other people correct me) suitable (does it some my needs) , stable, available (including documentation, live q&a resources like stackoverflow, blog posts explaining how- not new ones but existing and up to date regarding the version available), and simple.
    - josephg 6y ago
      I try to adapt my checklist to the problem at hand. Sometimes I'm making something as a hobby project, or to solve a problem right now. Sometimes I want to write code that will outlive me, and sometimes I'll just throw some code at the wall and call it done. Each situation necessarily results in different priorities and tools. I wouldn't TDD a gamejam project, and I wouldn't start a multi-year project in zig - at least, not yet. For infrastructure projects I want well written deps which are simple, easy to use and have good documentation. When I'm evaluating something I often read bits of its source code (eg to figure out how to do something not listed in the examples). You get a sense of where to put things that way - actix (the actor library, not the web library) is very carefully designed, but seems to go a bit overboard inventing new concepts (+ associated traits). Tide feels pragmatic - its a bit sloppy with allocations, but it doesn't seem to really care. It wants to be fast enough and good enough while being simple to use. For hobby projects I like to follow my nose and pick whatever seems shiny. Over the last few years I've learned svelte, typescript, snowpack, rust (and some rust libraries), zig, wasm and other stuff. I like to make some risky bets and then just play the hand out and see what happens. And I use that as fuel for when I make longer term projects. I'm making a little database at the moment and I'm using rust - which is much slower for me to write (compared to nodejs) but it matches the values of the project I'm working on to a tee.
mattmanser 6y ago
The MVC and ORM revolutions are the counter-argument to this. Rails/Django, then ASP.Net MVC/Laravel/whatever Java was was a massive step forward. If you didn't use it, you were hamstringing yourself. People switched to Rails in droves. As were using ORMs. You'll still get people quibble about this, but never having to go through the tedium of updating 101+ SQL statements when you add a column in a pain you young'uns will never know... JQuery was actually another example. Cross browser Ajax statements were annoying, plus just manually adding individual HTML nodes in HTML was laborious.
- valenterry 6y ago
  ORMs are not the only way to avoid/solve the problem of having to update many SQL statements. People complain rightfully about them.
- pjmlp 6y ago
  I have not seen people switching to rails in droves over here, it was a fashion wave that came and went. Apparently they are all now learning Elixir after a short migration wave over to Clojure. C++, Java and ASP.NET over here for the last 20 years.

by bgroat 6y ago

Retric 6y ago

That’s a little far, old doesn’t mean good. The bleeding edge often gets abandoned, but tech has generally been improving over time. IMO, the sweet spot starts when something was a fad ~5 years ago and is still reasonably popular.

DaiPlusPlus 6y ago
> IMO, the sweet spot starts when something was a fad ~5 years ago and is still reasonably popular. That would mean it's okay to use Angular today, but dev trends (and Google's support "policy") would advise against that.
- yen223 6y ago
  A good reason to wait a few years is precisely so that we have a clearer picture of what strengths and deficiencies a piece of tech brings to the table, especially out in the real world. We have a good picture of how Angular and React works in production now. We cannot say the same for something like Svelte.
  - fpoling 6y ago
    React is far from being stable. It deprecated a lot older API, added entirely new concept of hooks. If one wants stability, then PHP has a way better track record.
    - scrollaway 6y ago
      Nonsense. React is extremely stable. It indeed added hooks, deprecating exactly nothing in doing so. React deprecations are very few and far between.
      - DaiPlusPlus 6y ago
        > deprecating exactly nothing in doing so De jure deprecation, correct - but reading between the lines in Facebook's own blog article that introduced Hooks ( https://reactjs.org/docs/hooks-intro.html https://reactjs.org/docs/hooks-intro.html ), which put a bit too much emphasis on "There are no plans to remove classes from React.", which to me means they're definitely going to be deprecating class-based controls in the future.
        notriddle 6y ago
        I can see three possible universes here, all of which end on everyone assuming that classes are going to be removed from React. > There are no plans to remove classes from React. They're totally going to remove classes from React. > We are going to remove classes from React. They're obviously going to remove classes from React. > No comment. They're totally going to remove classes from React.

nicoburns 6y ago

> If nothing stable, decades old, and well documented can solve the problem then reach for hot new-ness I think it's a little more nuanced than that. Usually the older technology is more stable and better documented. But not always. Sometimes the new hotness is the new hotness precisely because it's better in these kind of categories.

bgroat 6y ago
You and Retric are right. I'm imagining a checklist of: - Stable - Well Documented - Age In descending order of importance. When choosing between any technology choose the one that is most stable. If multiple options are on a stable release, choose the one that is best documented. If multiple stable releases have excellent documentation, choose whichever is oldest. I don't think this framework is always (or even often) right. But it works for me
- makapuf 6y ago
  My checklist would be (I'm eager to know other people correct me) suitable (does it some my needs) , stable, available (including documentation, live q&a resources like stackoverflow, blog posts explaining how- not new ones but existing and up to date regarding the version available), and simple.
  - josephg 6y ago
    I try to adapt my checklist to the problem at hand. Sometimes I'm making something as a hobby project, or to solve a problem right now. Sometimes I want to write code that will outlive me, and sometimes I'll just throw some code at the wall and call it done. Each situation necessarily results in different priorities and tools. I wouldn't TDD a gamejam project, and I wouldn't start a multi-year project in zig - at least, not yet. For infrastructure projects I want well written deps which are simple, easy to use and have good documentation. When I'm evaluating something I often read bits of its source code (eg to figure out how to do something not listed in the examples). You get a sense of where to put things that way - actix (the actor library, not the web library) is very carefully designed, but seems to go a bit overboard inventing new concepts (+ associated traits). Tide feels pragmatic - its a bit sloppy with allocations, but it doesn't seem to really care. It wants to be fast enough and good enough while being simple to use. For hobby projects I like to follow my nose and pick whatever seems shiny. Over the last few years I've learned svelte, typescript, snowpack, rust (and some rust libraries), zig, wasm and other stuff. I like to make some risky bets and then just play the hand out and see what happens. And I use that as fuel for when I make longer term projects. I'm making a little database at the moment and I'm using rust - which is much slower for me to write (compared to nodejs) but it matches the values of the project I'm working on to a tee.

mattmanser 6y ago

The MVC and ORM revolutions are the counter-argument to this. Rails/Django, then ASP.Net MVC/Laravel/whatever Java was was a massive step forward. If you didn't use it, you were hamstringing yourself. People switched to Rails in droves. As were using ORMs. You'll still get people quibble about this, but never having to go through the tedium of updating 101+ SQL statements when you add a column in a pain you young'uns will never know... JQuery was actually another example. Cross browser Ajax statements were annoying, plus just manually adding individual HTML nodes in HTML was laborious.

valenterry 6y ago
ORMs are not the only way to avoid/solve the problem of having to update many SQL statements. People complain rightfully about them.
pjmlp 6y ago
I have not seen people switching to rails in droves over here, it was a fashion wave that came and went. Apparently they are all now learning Elixir after a short migration wave over to Clojure. C++, Java and ASP.NET over here for the last 20 years.