JavaScript Rising Stars 2020(risingstars.js.org)
risingstars.js.org
JavaScript Rising Stars 2020
https://risingstars.js.org
69 comments
Meteor is alive and well! Since 2015, I have been relying on it to implement a number of SaaS solutions involving real-time location tracking.
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.
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.
Rails is still great for a project between the sizes of small and large, the former and latter of which will benefit from tools with a lighter touch (like Go), in my opinion.
It’s almost a reflection of framework trends, which is not interesting.
what was your ts stack ? vue ? react ?
The JavaScript community has a huge problem with hype and churning libraries unnecessarily.
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.
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.
This is what tech and programming is to some people. It's about knowing the latest and greatest tech trends. And they'll often brag about the ones they know to others who don't know them.
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.
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.
Worth noting that this is just measuring the amount of stars a project has, not if you absolutely, must learn this today to stay current. Libraries and frameworks comes and goes, it's your base knowledge you need to improve upon, not specific APIs offered by easy-to-consume libraries and frameworks. Learn them, adopt their best ideas, throw away the rest, pick the right tool for the job, probably the best tool is not the tool you're currently most familiar with, if you rank your choices based on GitHub stars anyway. People use stars for all kinds of purposes, don't extract "It's valuable" because of that.
No QuickJS? That surely has to be a one of the more interesting new/rising projects in the compiler category last year.
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.
https://github.com/bellard/quickjs
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.
https://github.com/bellard/quickjs
That's because this "Rising Stars" compilation is literally what the title says, a scraping of the number of GitHub stars each projects has received, and filtered by JavaScript, it seems at least. QuickJS is on GitHub, but it's mostly written in C, not JavaScript. And the authors, having the grand idea of scraping GitHub stars, didn't think of to look outside their echochambers of "dev influencers" nor just search for "javascript" on GitHub to do some manual good old research.
They have a JS compiler written in rust in the list. :)
Not sure which one you're referring to, but esbuild (Golang) and rome (TypeScript) are also mentioned, probably because either dev-influencers on social media have been raving about them, or they have sufficient enough JavaScript code in their project to show up for the authors search.
QuickJs is under a "Runtime" category, not compilers, so that's why you don't see it. You can see the category here https://bestofjs.org/projects?tags=runtime
We don't have a specific category for runtimes in Rising Stars at this stage.
We don't have a specific category for runtimes in Rising Stars at this stage.
QuickJS is crazy embeddable too, being written in C89 and only a few source/header files. You might need to work around a few situations if your platform doesn't have all of libc but otherwise it's incredibly accommodating.
Definitely watching esbuild (basically babel but implemented in Go) and SWC (the same, but in Rust). Compile times cut from 47s to less than 1 second speak for themselves!
I’m using it on my current project. Loving it.
I’m currently organizing a roadmap for improving my full-stack skills. I work in JS with Node and React.
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.
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.
Master typescript and you will be rewarded greatly! It is a fantastic tool with a very high level of adoption already. It makes React significantly easier to write and refactor. You won’t ever go back to plain .js!
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.
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.
Now is possible to use many NPM packages in Deno, find out on the Web
If you only ever worked in JS (browser and/or server), branch out. Try different things instead, it'll make you a better JS developer (and better developer in general) if you try to learn things that are far out from your current skill set. If you're into types, go for Haskell or Erlang. If you're into dynamic runtimes, go for Clojure or Smalltalk.
Great advice, but I think going for a more mainstream alternative would be a bit more suitable career-wise.
Typescript will completely change your productivity and is a massive game changer for JS. You don’t even have to learn much for it to add massive value.
I’m a huge fan, but I also think that merely leveraging type checking with jsdoc is powerful.
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.
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.
Any good resource recommendations.
Youtube videos:
1. Clément Mihailescu has a good summary done in less than fifteen minutes.
2. FreeCodeCamp.org has a long video.
1. Clément Mihailescu has a good summary done in less than fifteen minutes.
2. FreeCodeCamp.org has a long video.
I'm not sure there's much to learn with Deno. It's typescript with a different import syntax, package management, and a different standard library.
Learn how to use Typescript, it's pervasive in the JS ecosystem and very easy to learn now.
Learn how to use Typescript, it's pervasive in the JS ecosystem and very easy to learn now.
Definitely learn Typescript type annotations/compilation pipeline.
These developer roadmaps might be helpful :) https://roadmap.sh/
Deno is still incompatible with JS ecosystem
Now is possible to use many NPM packages in Deno, find out on the Web
Interesting, I didn't know that. What's the catch?
The catch is that it works in a case by case basis. The most used libraries are there and work wonders, but things like the Vue compiler won't work with NPM transformations and are better off with a native port, like VNO
I honestly thought when they said "rising stars" they meant new, awesome projects. Instead it's the same old stuff everyone knows ranked on a metric that is tenuous at best.
Yeah, I wouldn't really consider many of these to be "rising stars". There were definitely some interesting libraries on here that I'd only heard mention of or not at all, but in what world are Angular or Node.js or even React "rising stars"?
As a somewhat fad averse engineer who has more or less settled into his own preferred toolchain for FE and BE JavaScript, I plan to invest some time in next.js, tailwind and emotion soon ish. Great to see the state of the art still being pushed. Might see how feasible porting my existing nodejs projects to deno is too.
I quite enjoy Tailwind, and have used it in several production projects.
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. :)
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. :)
I personally would recommend against making a lot of custom classes via @apply, especially when pairing with a component based framework like React.
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)
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 tried a deno port, but lack of crypto support was a showstopper. I think I could’ve done it if not for that. It’s quite a lot nicer than node, though, and I definitely will give it another go when it’s further along.
We use tailwind in production at the company I work for and it works well enough.
I'd also recommend looking into https://chakra-ui.com/
I'd also recommend looking into https://chakra-ui.com/
Shame that parcel is below the fold for build tools. It's a really great build tool.
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.
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.
Glad to see that hitching my ride to the Vue.js bandwagon seems to be paying off
I've used Backbone, Angular, React, Stimulus, etc. and I've finally hit on Vue. I've been using Vue 3 for the past couple of months and it really hits the sweet spot for me.
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"
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"
I've been using Vue since pre v1 days and donate to the project, I've probably built 50+ apps with it of varying complexity, but I'm seriously considering jumping ship to something like Svelte at some point in the near future.
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.
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.
Anyone tried these build tools? What do you guys think? I only have used Webpack so far (used it since Webpack 1, and I still hate it today)
If you can get away with using the less feature-rich esbuild, you'll see 10x faster in compilations at least.
I come from a JVM/Python background, so not familiar with JS ecosystem at all. How do people decide what to use when there are 5 most popular libraries/frameworks in each category. Not saying the diversity is a bad thing. Just wondering how people make these choices when starting a new project.
My 2c:
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.
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.
Most niches don’t have multiple popular contenders except for some core concerns. Most of the time you can default to the popular one if you don’t know how to evaluate it any further, but the README and API tend to make the decision trivial. The project with the best docs is an easy deal breaker as it’s a good signal that the engineers have put some hammock time into the project and they have attention to detail.
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.
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.
If all else is equal, I opt for the smallest contender (in terms of minified size). I also check the dependency graph and nope out if it’s unreasonably large.
I wish nest.js could get more love. I love Angular and it is a great feeling using nest.js.
Anyone using React Query in production?
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.
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.
React Query is pretty cool. I haven't used it in my own projects, but based on all the discussion I've seen, it looks like a solid choice.
Meanwhile, we in the Redux team recently published an alpha library that we've dubbed "RTK Query" [0]. 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 [1].
[0] https://rtk-query-docs.netlify.app
[1] https://www.reddit.com/r/reactjs/comments/kw9cr3/recently_pi...
Meanwhile, we in the Redux team recently published an alpha library that we've dubbed "RTK Query" [0]. 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 [1].
[0] https://rtk-query-docs.netlify.app
[1] https://www.reddit.com/r/reactjs/comments/kw9cr3/recently_pi...
Nice, gonna check out RTK now. Thanks.
Sure. For RTK specifically, I recommend reading the "Modern Redux with Redux Toolkit" section of the recently rewritten "Redux Fundamentals" core docs tutorial, which shows how RTK simplifies common Redux usage patterns:
https://redux.js.org/tutorials/fundamentals/part-8-modern-re...
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:
https://redux.js.org/tutorials/essentials/part-1-overview-co...
https://redux.js.org/tutorials/fundamentals/part-8-modern-re...
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:
https://redux.js.org/tutorials/essentials/part-1-overview-co...
Thanks for all this great stuff. I use redux-toolkit already on a large application at a big sales automation company, and it works great, so looking forward to implementing some things with RTK.
https://2020.stateofjs.com/en-US/ is a bit more useful.
As someone who hasn't touched JavaScript much since the 90's I found the original article linked quite useful as straight away I was able to see the relevant tech stack cf. the 2020 link.
Surprising not to see EmberJS listed in the front end frameworks. Did it not make top 20 or was it an oversight?
I'm glad it's not there. Having been using Ember for the last years, it's the worst JS Framework I've used since touching Backbone years ago.
Does not deserve downvote. Guidelines:
>Have curious conversation
https://news.ycombinator.com/newsguidelines.html
>Have curious conversation
https://news.ycombinator.com/newsguidelines.html
[deleted]
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.