[HN Gopher] JavaScript Rising Stars 2020
___________________________________________________________________
JavaScript Rising Stars 2020
Author : michaelrambeau
Score : 49 points
Date : 2021-01-13 21:35 UTC (1 hours ago)
(HTM) web link (risingstars.js.org)
(TXT) w3m dump (risingstars.js.org)
| root-z wrote:
| 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.
| ZephyrBlu wrote:
| 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.
| christophilus wrote:
| 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.
| nefitty wrote:
| 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.
| albertgoeswoof wrote:
| 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.
| mywittyname wrote:
| Any good resource recommendations.
| albertgoeswoof wrote:
| https://github.com/bitjson/typescript-starter
| pdevr wrote:
| Youtube videos:
|
| 1. Clement Mihailescu has a good summary done in less than
| fifteen minutes.
|
| 2. FreeCodeCamp.org has a long video.
| franklyt wrote:
| 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.
| qudat wrote:
| 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.
| throw_m239339 wrote:
| Definitely learn Typescript type annotations/compilation
| pipeline.
| brendanmc6 wrote:
| 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.
| gutino wrote:
| Now is possible to use many NPM packages in Deno, find out on
| the Web
| nicoburns wrote:
| Yes, this. Use TypeScript with Node and/or React.
| bavell wrote:
| Agreed, TS is a big productivity boost and is here to stay,
| definitely worth investing time into if you want to get
| further into JS ecosystem.
|
| You can safely ignore Deno for the time being.
| christiansakai wrote:
| Deno is still incompatible with JS ecosystem
| gutino wrote:
| Now is possible to use many NPM packages in Deno, find out on
| the Web
| capableweb wrote:
| 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.
| shruubi wrote:
| 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.
| _nothing wrote:
| 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"?
| ibejoeb wrote:
| 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.
| acemarke wrote:
| 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...
| sillycon-valley wrote:
| Also checkout SWR https://swr.vercel.app/
| albertgoeswoof wrote:
| I shunned the JS world for a while after jumping on the Meteor
| bandwagon a few years ago and seeing it just fizzle out to a boat
| load of outdated and unsupported dependencies. Rails was just so
| much more productive and easy for solo work.
|
| 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.
| austincheney wrote:
| It's almost a reflection of framework trends, which is not
| interesting.
| agumonkey wrote:
| what was your ts stack ? vue ? react ?
| coding123 wrote:
| https://2020.stateofjs.com/en-US/ is a bit more useful.
| bori5 wrote:
| 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.
| rayrag wrote:
| Similar summaries:
|
| https://2020.stateofjs.com/en-US/
|
| https://2020.stateofcss.com/en-US/
|
| https://uxtools.co/survey-2020/
| davedx wrote:
| 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.
| qudat wrote:
| 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/
| christophilus wrote:
| 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.
| ljoshua wrote:
| 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. :)
| [deleted]
| stocktech wrote:
| Surprising not to see EmberJS listed in the front end frameworks.
| Did it not make top 20 or was it an oversight?
| phaedryx wrote:
| While EmberJS is a solid framework, I don't think it is a
| "rising star"
| stocktech wrote:
| Sure, but by that logic React and Angular shouldn't be there
| either.
| everybodyknows wrote:
| Does not deserve downvote. Guidelines:
|
| >Have curious conversation
|
| https://news.ycombinator.com/newsguidelines.html
| underwater wrote:
| 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.
| tamrix wrote:
| 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.
| dstick wrote:
| Glad to see that hitching my ride to the Vue.js bandwagon seems
| to be paying off
| phaedryx wrote:
| 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"
| capableweb wrote:
| 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.
| nicoburns wrote:
| 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!
| christophilus wrote:
| I'm using it on my current project. Loving it.
| preommr wrote:
| 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.
| megous wrote:
| 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
| danbolt wrote:
| 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.
___________________________________________________________________
(page generated 2021-01-13 23:01 UTC)