To me it seems like the winners of 2019 are:
- GraphQL
- Jest
State of JavaScript 2019
311–320 of 372 posts
Re: State of JavaScript 2019
#312Earlier quoted context omitted.
Generally have to agree there, but I do feel like there is a reason. ES6 modules (or typescript modules) and the simple fact that the variability is finally dropping: It seems like there was one specific winner of all of the UI frameworks. React. There is now pretty much one specific winner to package managers. Yarn. There is one specific winner for language front-end: Typescript. There are basically two front-end bu…
Disagree on yarn - npm is still trying to keep up and the latest releases are doing well Seems like within React, Redux/Apollo/plain is splitting the data layer again too But the yarn/npm is a tiny difference and data layer is much more application specific
Redux is quickly being relegated to pile of don't use. I suspect 2020's survey result will show hooks to have completely destroyed redux.
Re: State of JavaScript 2019
#313Earlier quoted context omitted.
Probably because a lot of people have been working with it for a long time (like you). I think I started 20 years ago - but I just learned like 40% of css grid this past weekend. (I've been a happy flexbox user for a few years) But I know what you're saying. I also noticed a few percentage points of people saying they have 20+ years or React experience at this point.
The `20+ years` demographic refers to 20+ years of JavaScript experience, AFAICT.
ahh thanks for that, I misread the survey notes on that.
Re: State of JavaScript 2019
#314Earlier quoted context omitted.
A git repository is best thought of as a sort of tree, where the nodes can potentially have multiple parents. This technically makes them a graph ("directed acyclic" to show I do know the technical terms), but our human intuition will mostly work thinking of them as a tree. To understand multiple parents use your intuition about human beings, since we all have multiple parents. A "branch" doesn't really have any spec…
>> makes sure to walk the trainees through the confusing states you can get into, >> then we explain what happened, why, and how to correctly get out of them Is this something you could share?
- detached HEAD: "git checkout existing_branch" or "git checkout -b new_branch"
- you don't where somewhere and you moved and you can't go back: "git reflog"
- local repo and remote with a different history (e.g: you rebased on a published branch): the whole team to sync with remote except you, then hold. Export your remaining changes as a patch. Reclone. Apply patch.
- remote has a different history than the rest of the team (e.g: you forced push a different history): Delete remote, recreate, repush from one of the team mate, then apply previous solution.
- your messed up your merge and wish to never have done that: "git reset --merge"
- the last commit is not published and you messed it up: "git commit --amend"
- the last commit is published and you messed it up: "git revert HEAD"
But rather than solve problems, better not get them in the first place. Always "git status" before anything, always get a clean working copy before checkout/pull, create a fat gitignore, etc.
Re: State of JavaScript 2019
#315Earlier quoted context omitted.
> I could go on and on about the horror that is typescript In his talk Predicting the future of the web at the last ReactiveConf, Richard Feldman (not himself a typescript guy, but an Elm user) quoted an interesting statistic that most of developers who try typescript never go back to writing plain javascript. I do not remember where that statistic was from, but can attest that with me it is the case. So much for the…
> most of developers who try typescript never go back to writing plain javascript yes, most developers adhere to RDD. That is, resume driven development. You ever see developers going back to Ruby from Node? Or from any shiny new thing to the slightly older but perfectly fine thing? I predict people will move on from TypeScript within 5 years. Purely because everyone will know TS so the differentiating value of TS wi…
Even if that is true, there is typically a reason things become popular. Right now only Flow / Elm / Purescript could possibly compete in that specific space. Do you specifically see people migrating en-mass to those technologies or do you think something better is coming... soon?
(Or are you literally saying people will go back to JS? - I don't know too many people excited about the prospect of losing all the contextual help and caught compiler errors - and I don't see that happening because of RDD anyway!)
Re: State of JavaScript 2019
#316Earlier quoted context omitted.
> most git users picture a branch like a diverging chain of commits and not a moving label Ok, I'll bite: can you explain that little more please?
Of course. Someone explained it to me, after all. In git, a branch is NOT like a wooden branch on the trunk of a tree, although it ends up being at the top of one, which makes the analogy ok. A git branch is the same thing as a git tag, except it moves automatically when you commit from it. You can see it as a lightweight label attached to a commit. If your HEAD is itself attached to a branch (HEAD is also a lightwei…
> In git, a branch is NOT like a wooden branch on the trunk of a tree, although it ends up being at the top of one, which makes the analogy ok.
So, there's an isomorphism between (1) a commit node; and (2) the chain(s) of commits ending in that node.
Why then is it important to think of "branch" as referring to one rather than the other? As evidenced by the isomorphism, they're the same thing.
Re: State of JavaScript 2019
#317Earlier quoted context omitted.
> I could go on and on about the horror that is typescript In his talk Predicting the future of the web at the last ReactiveConf, Richard Feldman (not himself a typescript guy, but an Elm user) quoted an interesting statistic that most of developers who try typescript never go back to writing plain javascript. I do not remember where that statistic was from, but can attest that with me it is the case. So much for the…
> most of developers who try typescript never go back to writing plain javascript yes, most developers adhere to RDD. That is, resume driven development. You ever see developers going back to Ruby from Node? Or from any shiny new thing to the slightly older but perfectly fine thing? I predict people will move on from TypeScript within 5 years. Purely because everyone will know TS so the differentiating value of TS wi…
I'm not above going along with tech I think's misguided or bad rather than fighting it, because I know it's trending up and will look good on my résumé, but ask for me to solo-write a Javascript project and tell me delivery must be in Javascript, explicitly not in Typescript, and I'm writing that fucker in Typescript and delivering you the Javascript that tsc outputs, and I don't care if no-one ever knows I did that. It's for my own sanity.
Re: State of JavaScript 2019
#318Earlier quoted context omitted.
Svelte seems promising. I think it's a natural evolution from what I think is an over focus on FP and purity in React, to a more natural and intuitive DX without significant drawbacks. Svelte does have an irritating wart IMO, citing their tutorial: Because Svelte's reactivity is triggered by assignments, using array methods like push and splice won't automatically cause updates. So for reference types that are mutate…
To be fair, React has the same "wart". React is not guaranteed to work properly if you do: numbers = this.state.numbers; numbers.push(numbers.length + 1); this.setState({ numbers: numbers }); React docs here: https://reactjs.org/tutorial/tutorial.html#why-immutability-... Similar docs for redux: https://redux.js.org/recipes/structuring-reducers/immutable-... There's no good way around it without doing deep equality c…
Since Svelte is a compiler I was thinking they could wrap the exported variables in an observable of some sort and make any method call on the reference variable trigger a value update behind the scenes. I have now idea how costly/complex that would be though.
Also, maybe it's a conscious choice and they want to make any data update explicit with reassignment.
Re: State of JavaScript 2019
#319Earlier quoted context omitted.
Yeah Svelte is the next thing. Backbone and Angular were great, but then came Vue and React. Vue and React were great, but then came Svelte. It's: - Simpler. You change values with `=` not some method call. - Faster, as the svelte compiler dynamically creates bindings at build time, vs a virtual DOM that has to dynamically track binding at run time - Smaller, since Svelte's output doesn't include Svelte.
https://stefankrause.net/js-frameworks-benchmark8/table.html Preact diffs against the real dom and is faster than Svelte in benchmarks while the library is only around 3.5kb (the minified code fits easily on a single screen). I'd note that authors from most of the frameworks represented have submitted their own optimizations, so performance isn't strictly based on the author's familiarity. InfernoJS is massively fast…
> https://stefankrause.net/js-frameworks-benchmark8/table.html
The version of Svelte used there is roughly 100 releases and a year and a half old. These days Svelte's performance appears to be much closer to Inferno's than Preact's.
https://krausest.github.io/js-framework-benchmark/current.ht...
Re: State of JavaScript 2019
#320Earlier quoted context omitted.
Generally have to agree there, but I do feel like there is a reason. ES6 modules (or typescript modules) and the simple fact that the variability is finally dropping: It seems like there was one specific winner of all of the UI frameworks. React. There is now pretty much one specific winner to package managers. Yarn. There is one specific winner for language front-end: Typescript. There are basically two front-end bu…
Disagree on yarn - npm is still trying to keep up and the latest releases are doing well Seems like within React, Redux/Apollo/plain is splitting the data layer again too But the yarn/npm is a tiny difference and data layer is much more application specific
A look through the yarn issue tracker tells me it's not time to try it again yet, since the last time it burned me. Maybe some day.