But recently I built a couple of services in typescript and the ecosystem seems to have stabilised a lot, my productivity was super high and I’m majorly impressed.
In 2016, Meteor 1.3 implemented full support for the NPM ecosystem. As a result, people switched to using NPM packages directly (where possible) instead of older Atmosphere packages.
This common misconception of outdated dependencies may be the result of non-Meteor users browsing the atmosphere website and seeing many old packages.
Using a metric like "number of new stars" just exacerbates that problem. It neither tells you about libraries are undiscovered gems, or libraries which are proven, stable and reliable.
It's simply a measure of which libraries are well into their hype curve.
Some call them brogrammers. For their hipster-like approach to programming.
Believe it or not, a lot of them are on hackernews so they'll probably get super offended by this post.
It even has enough stars to place it in the middle of the top 5 in the compiler category, despite not even being distributed/developed via github. And it gained them in just 3 months.
We don't have a specific category for runtimes in Rising Stars at this stage.
Does anyone have any opinion on whether I should spend time learning Deno and Typescript instead of digging deeper into what I already know? I find it hard to tell if Deno will start showing up in job descriptions in a few years, or if Node is so entrenched that it would only distract me from building on my current skills.
Deno is not relevant enough, I would wager 99.99% of the existing projects you might find yourself working on in the next few years will be using node somewhere in the stack. It shouldn’t be hard to pick up deno when it eventually does show up.
You can safely ignore Deno for the time being.
It also keeps me more honest because I’m not going through the trouble of typing a parameter or variable just to make it any.
1. Clément Mihailescu has a good summary done in less than fifteen minutes.
2. FreeCodeCamp.org has a long video.
Learn how to use Typescript, it's pervasive in the JS ecosystem and very easy to learn now.
When using Tailwind, don't forget that it is not only to be used as a utility-like CSS framework, but is also intended to build your own CSS systems. You can customize it and build your own classes using the `@apply` directive and other tools so that you don't copy/paste the same utility classes all over the place, but instead use CSS as we used to back in the good ol' days, with custom classes. :)
React makes it easy to avoid the need for duplicate naming such as 'btn' css class and a <Button> component.
I would also recommend twin.macro, though I'm still on the fence about using it.
At the very least, it helps with difficult things like style overwrites, ensuring utilities are spelled correctly, conditionally applying utilities and bailwind (one-off styles)
I'd also recommend looking into https://chakra-ui.com/
Also, those performance benchmarks for esbuild are highly misleading. Parcel has a much faster update speed but they're comparing startup speed. Also, why disable caching? It seems highly contrived.
This section (https://vuejs.org/v2/guide/comparison.html#With-MobX) is what got me interested:
"...the React + MobX workflow can be thought of as a more verbose Vue, so if you’re using that combination and are enjoying it, jumping into Vue is probably the next logical step"
Vue 3 is great and finally has the TS support I've been waiting for (minus Vuex which is still apparently two versions away from proper TS support) but the ecosystem seems to be fracturing, or at least resources being spread too thinly. We now have:
* A CLI with no official support for static bundling or SSR (the solution is basically "use Nuxt").
* There is a separate static site bundler... but it's opinionated: markdown-centered, theming system, etc.
* An alternative build tool (Vite) which is amazing for development but worse than the CLI for building production apps. It essentially does less, faster.
* A Vite based markdown-centered static site bundler (VitePress).
I read a comment the other day that someone had made about React that really hit home. Basically along the way the project lost sight of the people that actually just want to build actual applications. Vue is amazing, and I'm eternally grateful to the Vue team who have basically enabled me to earn a good living for a few years, but I kind of feel like Vue is heading in the wrong direction.
Rich Harris talked about "a single, officially supported way to build apps" in a talk he did recently, which is what I've been wanting someone to say for a long time. Svelte kit sounds very appealing at this point. Officially supported SSR + static bundling (or both!) without having to either choose between a third-party framework-on-a-framework, a "markdown-centered" bundler, or having to write another custom SSR implementation.
1) Surrounding ecosystem. This is one of the reason React is so popular. The community and ecosystem of React packages is extremely large.
2) Personal preference. There really isn't much difference between React/Vue/Angular in terms of getting the job done (Same with most good libraries), so either you pick a library because you need a very specific piece of functionality from it, or you pick it because you/your team/your org prefers it.
But also, just try multiple libraries out. Sometimes one library doesn’t even give you the results you want. I notice beginners in general are resistant to that and seem to think precious time is wasted if they don’t make the perfect decision upfront. I say spend an hour playing with various libs if you can’t decide otherwise.
I've got ongoing projects using redux+axios, apollo client, and roll-your-own data fetch hooks. No clear winner in my book. React Query looks neat but have yet to try it.
Meanwhile, we in the Redux team recently published an alpha library that we've dubbed "RTK Query" . It takes inspiration from data fetching libraries like React Query, SWR, Apollo, and Urql, and provides similar sophisticated data fetching and caching capabilities. But, it's built on top of Redux Toolkit, which enables integration with the rest of the Redux addon ecosystem and the Redux DevTools. Once we've finalized the design of the new APIs, we're going to merge them back into Redux Toolkit itself, so that they'll just be additional exports from Redux Toolkit. I'm really excited about how this will let Redux users simplify their code, and wrote a comment over on Reddit today about how RTK Query changes things for Redux users .
And the companion "Redux Essentials" tutorial teaches Redux Toolkit as the default way to write Redux logic while building a "real world"-style example app:
>Have curious conversation