Programming deeply inspired me before it became my day job. Before Facebook conquered the front-end and API code space. Before Electron apps. Before D. Trump became president. Each of those dealt a hit to either my passion for dev or motivation to create software for others

Is it starting to snow. I hope it doesn't stick.

Facebook's API sucks

I didn't know Donald Trump was a software engineer.

@Hazarth don't think he is, let's say he just contributed to my loss of hope for mankind.

@Hazarth
Please, the dude knows EVERYTHING about EVERYTHING. Just ask him.

I agree with you about Electron but what’s bad about React and GraphQL?

@DEVil666 I only notice your question now... React, GQL, yarn are not "bad" per se, but they are Facebook products and they do what FB does best: capitalize on great existing foundations (vdom, webcomponents, npm), throw corporate financial & marketing power at it, then claim it as their own and layer an opinionated style over it (JSX, hooks, strict schema's) doing away with established standards.

GQL basically throws away all HTTP verbs except POST/GET and discards browser caching advantages. JSX is based on the idea that throwing the DOM API together with XML results in a better default DX. And instead of starting Yarn they could have contributed to a better NPM

@webketje Thanks for your in-depth answer, the critic which you move to React is the same which I move towards TypeScript which breaks a well established standard to replace it with a corporate problem, I agree even with what you say about Yarn but I believe which NPM is not the best counter example since it established the proprietary and corporate NPM service as the de-facto standard for package managers, a better counter-example would have been Go or Deno package management (to stay in JS space) which are based on plain and simple HTTP encouraging developers to pick their favourite hosting for their packages (GitHub, GitLab, a simple nginx instance...) instead of putting them on an infrastructure controlled by a single corporation.

Talking about GraphQL being a REST perfectionist I understand the annoyance of not seeing verbs properly used but I believe which this was done by design because GraphQL wasn't intended to be used only trough HTTP but even with other transport layers...

@webketje (continuing from the previous comment) ...so having it tightly coupled to HTTP would be a deviation from the original idea of GraphQL

@DEVil666 Yeah I take all your points. I'm not a REST perfectionist, but since the verbs are there and they convey practical advantage (understood by server, established, browser caching) GQL should be totally HTTP-agnostic and allow all to be used. So I guess I'm venting more against the implementation (Apollo) than the spec.

I'm not sure I'm as enthusiastic about Deno's module loading. I think a centralized repo has a lot of advantages, although it would indeed be better like Arch Linux's AUR than corporate-controlled.