5 ms·

So after graphql, micro services, nosql and serverless, the SPA + "libs not framework" crowd join the "woooops!" club. Ignoring the noise is really becoming a

So after graphql, micro services, nosql and serverless, the SPA + "libs not framework" crowd join the "woooops!" club. Ignoring the noise is really becoming a key skill to survive as a programmer.

alex_sf 4y ago
Honestly, the signal is just to avoid whatever full-time JS developers are getting into.
- MartijnHols 4y ago
  The signal is to avoid new technologies with marketing engines behind them for at least a few years. And anyone who is gullible enough to believe them, which are more likely the new people learning to code and yelling about the new shiny libraries they found than full time developers that are actually productive rather than bored.
- datavirtue 4y ago
  Winner!
- mock-possum 4y ago
  Get ready to have a lot of trouble finding work as a js dev if you’re not into whatever full time js devs are getting into.
  - alex_sf 4y ago
    I'm totally fine with that.
  - deleted 4y ago
    [deleted]
dmix 4y ago
SPAs, microservices, nosql (Redis), and serverless are all still alive and well, they just aren’t a hammer for all problems like (some) people treated them originally. Nerds getting overexcited about new tech is an old story and it will continue to happen indefinitely as much as we like to smug post about it. IDK about GraphQL since I’ve not used it but I’ve read lots of stuff recently about frameworks/ORMs working to better support this type of thing more directly/natively.
- BiteCode_dev 4y ago
  That's exactly my point.
  - dmix 4y ago
    Your comment sounds a bit dismissive though. They all provide plenty value individually. A lot of this stuff needs to be used IRL for the community to understand the limits and there will always be junior devs and cowboys willing to risk it. Plus not all of it is merely overexcitement/immaturity either, small companies and small dev teams often try to keep their toolsets small and eventually end up pigeonholing stuff into tech that doesn’t fit, until they get time/resources to do it properly. Some things are more obvious in retrospect. The vast majority of the software world is still pretty conservative when you look beyond HN and Twitter.
  - simplotek 4y ago
    > That's exactly my point. In your own, exactly what point did you tried to make? Complaining that x and y technology users joined the "whoops" crowd when those technologies are in fact well established and proved to be effective if not nearly optimal in some applications, what do you perceive as "whoops"? Frankly, it didn't seemed you had a point to make other than parroting cliches.
- roflyear 4y ago
  Graphql is only awful once you introduce abstractions. By itself it's really a great idea and works well.
jameshart 4y ago
Being too eager to dismiss a technology and move on is just as much of a bandwagon-jump as being too eager to adopt it in the first place. The Gartner Hype Cycle[1] has both a 'peak of inflated expectations' and a 'trough of disillusionment'. The thing a lot of tech cynics fail to spot is that both of them are wrong about the long term value of the technology. The 'plateau of productivity' awaits, where graphql, nosql, serverless, and SPAs will join every other technology, finding productive use in their appropriate niche. [1] https://en.wikipedia.org/wiki/Gartner_hype_cycle https://en.wikipedia.org/wiki/Gartner_hype_cycle
- 6510 4y ago
  > The 'plateau of productivity' awaits, where graphql, nosql, serverless, and SPAs will join every other technology, finding productive use in their appropriate niche. I keep thinking of the tower of babel. > God was concerned that humans had blasphemed by building the tower to avoid a second flood so God brought into existence multiple languages. Thus, humans were divided into linguistic groups, unable to understand one another. see? Now you can be wrong with the rest of us :)
- datavirtue 4y ago
  I have to agree. I ignored tailwindcss for far too long. Pry it from my cold dead fingers.
eurasiantiger 4y ago
What are you on about? GraphQL is absolutely essential in enterprise systems.
- roflyear 4y ago
  In my experience it's the poorly implemented abstractions on top of your ORM of choice that make graphql a bad time. It itself is really a great way to do things imo
  - eurasiantiger 4y ago
    Yes, exactly. The typical issue is devs not grokking the mental model of GraphQL and instead just creating more and more extra queries, essentially resolving data piece by piece in the frontend instead of leveraging GraphQL types and adding types, fields and field resolvers as needed so that the frontend can do one query to get all the data it needs. No wonder it feels like a clunky extra glue layer if it’s being used as one.
    - claytongulick 4y ago
      Some of us learned these lessons in the SOAP/WSDL/XML-RPC days, and learned to embrace the principles of REST to a avoid exactly those issues. I looked at graphql and saw a return to the horror of DoSomethingBecauseItsMondayAndDueTomorrow() type API methods. Hundreds or thousands of them that accumulate like cruft over time, and no one can delete anything because you have no idea what it'll break. I stick with well designed and well planned REST APIs. It's not a panacea, but it helps.
      - pjmlp 4y ago
        Did we? Hello gRPC, Web sockets and language specific SDKs for REST APIs, as no one actually uses REST as designed.
      - roflyear 4y ago
        > and no one can delete anything because you have no idea what it'll break. This is a problem with GraphQL, but you can monitor if anyone is requesting that data. Major benefit with GraphQL is you can ask for the data you need and just the data you need. So you don't have 30 different API endpoints that really return the same data, just smaller chucks. Or maybe you just need the IDs... etc. GraphQL is also efficient here, not executing the code for the data you don't need - which is really useful. It depends if you're in that situation or not, or what parts of your domain are in those situations. I don't think "GraphQL everywhere" is sane.
robertoandred 4y ago
I don’t think you understand what any of those terms mean.

So after graphql, micro services, nosql and serverless, the SPA + "libs not framework" crowd join the "woooops!" club. Ignoring the noise is really becoming a key skill to survive as a programmer.

alex_sf 4y ago

Honestly, the signal is just to avoid whatever full-time JS developers are getting into.

MartijnHols 4y ago
The signal is to avoid new technologies with marketing engines behind them for at least a few years. And anyone who is gullible enough to believe them, which are more likely the new people learning to code and yelling about the new shiny libraries they found than full time developers that are actually productive rather than bored.
datavirtue 4y ago
Winner!
mock-possum 4y ago
Get ready to have a lot of trouble finding work as a js dev if you’re not into whatever full time js devs are getting into.
- alex_sf 4y ago
  I'm totally fine with that.
- deleted 4y ago
  [deleted]

dmix 4y ago

SPAs, microservices, nosql (Redis), and serverless are all still alive and well, they just aren’t a hammer for all problems like (some) people treated them originally. Nerds getting overexcited about new tech is an old story and it will continue to happen indefinitely as much as we like to smug post about it. IDK about GraphQL since I’ve not used it but I’ve read lots of stuff recently about frameworks/ORMs working to better support this type of thing more directly/natively.

BiteCode_dev 4y ago
That's exactly my point.
- dmix 4y ago
  Your comment sounds a bit dismissive though. They all provide plenty value individually. A lot of this stuff needs to be used IRL for the community to understand the limits and there will always be junior devs and cowboys willing to risk it. Plus not all of it is merely overexcitement/immaturity either, small companies and small dev teams often try to keep their toolsets small and eventually end up pigeonholing stuff into tech that doesn’t fit, until they get time/resources to do it properly. Some things are more obvious in retrospect. The vast majority of the software world is still pretty conservative when you look beyond HN and Twitter.
- simplotek 4y ago
  > That's exactly my point. In your own, exactly what point did you tried to make? Complaining that x and y technology users joined the "whoops" crowd when those technologies are in fact well established and proved to be effective if not nearly optimal in some applications, what do you perceive as "whoops"? Frankly, it didn't seemed you had a point to make other than parroting cliches.
roflyear 4y ago
Graphql is only awful once you introduce abstractions. By itself it's really a great idea and works well.

jameshart 4y ago

Being too eager to dismiss a technology and move on is just as much of a bandwagon-jump as being too eager to adopt it in the first place. The Gartner Hype Cycle[1] has both a 'peak of inflated expectations' and a 'trough of disillusionment'. The thing a lot of tech cynics fail to spot is that both of them are wrong about the long term value of the technology. The 'plateau of productivity' awaits, where graphql, nosql, serverless, and SPAs will join every other technology, finding productive use in their appropriate niche. [1] https://en.wikipedia.org/wiki/Gartner_hype_cycle https://en.wikipedia.org/wiki/Gartner_hype_cycle

6510 4y ago
> The 'plateau of productivity' awaits, where graphql, nosql, serverless, and SPAs will join every other technology, finding productive use in their appropriate niche. I keep thinking of the tower of babel. > God was concerned that humans had blasphemed by building the tower to avoid a second flood so God brought into existence multiple languages. Thus, humans were divided into linguistic groups, unable to understand one another. see? Now you can be wrong with the rest of us :)
datavirtue 4y ago
I have to agree. I ignored tailwindcss for far too long. Pry it from my cold dead fingers.

eurasiantiger 4y ago

What are you on about? GraphQL is absolutely essential in enterprise systems.

roflyear 4y ago
In my experience it's the poorly implemented abstractions on top of your ORM of choice that make graphql a bad time. It itself is really a great way to do things imo
- eurasiantiger 4y ago
  Yes, exactly. The typical issue is devs not grokking the mental model of GraphQL and instead just creating more and more extra queries, essentially resolving data piece by piece in the frontend instead of leveraging GraphQL types and adding types, fields and field resolvers as needed so that the frontend can do one query to get all the data it needs. No wonder it feels like a clunky extra glue layer if it’s being used as one.
  - claytongulick 4y ago
    Some of us learned these lessons in the SOAP/WSDL/XML-RPC days, and learned to embrace the principles of REST to a avoid exactly those issues. I looked at graphql and saw a return to the horror of DoSomethingBecauseItsMondayAndDueTomorrow() type API methods. Hundreds or thousands of them that accumulate like cruft over time, and no one can delete anything because you have no idea what it'll break. I stick with well designed and well planned REST APIs. It's not a panacea, but it helps.
    - pjmlp 4y ago
      Did we? Hello gRPC, Web sockets and language specific SDKs for REST APIs, as no one actually uses REST as designed.
    - roflyear 4y ago
      > and no one can delete anything because you have no idea what it'll break. This is a problem with GraphQL, but you can monitor if anyone is requesting that data. Major benefit with GraphQL is you can ask for the data you need and just the data you need. So you don't have 30 different API endpoints that really return the same data, just smaller chucks. Or maybe you just need the IDs... etc. GraphQL is also efficient here, not executing the code for the data you don't need - which is really useful. It depends if you're in that situation or not, or what parts of your domain are in those situations. I don't think "GraphQL everywhere" is sane.

robertoandred 4y ago

I don’t think you understand what any of those terms mean.