1673116440
A guide to the basic differences between Web3.js and Ethers.js, the two most popular libraries for interacting with the Ethereum blockchain. And two example frontend apps using React + Hooks!
Inside the smart-contracts
folder, you will find a simple Truffle project with the following Solidity contract:
pragma solidity ^0.5.0;
contract Counter {
uint count = 0;
function increment() public {
count = count + 1;
}
function getCount() public view returns (uint) {
return count;
}
}
Before you run any of the frontend UIs, make sure to start the development console with truffle develop
, and then run the migrate
command to compile and deploy the contract onto the development chain.
There are two folders (app-ethers
and app-web3js
) each containing a simple React frontend for the above contract. The only substantial difference between these two UIs is located in the useCounterContract.js
files.
Here are the direct links for your convenience:
In each of these apps, you can serve the frontends with the following commands:
npm install
npm start
This will serve the frontend on http://localhost:1234
which you can view in your browser.
There are three major portions in this code: the setup, reading (calling a constant method), and writing (calling a non-constant mutating method).
With Web3.js, we need the following to instantiate a connected contract instance that can make read/write calls:
from
address (for send
transactions)Note that the networkId
is required for us to fetch the deployed address from our contract artifact.
// Web3.js
const web3 = new Web3("http://127.0.0.1:8545");
const accounts = await web3.eth.getAccounts();
const networkId = await web3.eth.net.getId();
const contractAddress = artifact.networks[networkId].address;
contractInstance = new web3.eth.Contract(artifact.abi, contractAddress, {
from: accounts[0],
});
With Ethers.js, we need the following for our contract instance:
Signer
object (similar to Provider
, but with a specified Signer
)// Ethers.js
const provider = new ethers.providers.JsonRpcProvider();
const network = await provider.getNetwork();
const contractAddress = artifact.networks[network.chainId].address;
contractInstance = new ethers.Contract(
contractAddress,
artifact.abi,
provider.getSigner(),
);
// Web3.js
const count = await contractInstance.methods.getCount().call();
console.log(count); // returns a String
// Ethers.js
const count = await contractInstance.getCount();
console.log(count); // returns a BigNumber instance
These two are very similar, but in our example Ethers.js returns a BigNumber instance by default whereas Web3.js will return the number as a String.
// Web3.js
await contract.current.methods.increment().send();
// tx has been mined
// Ethers.js
const tx = await contract.current.increment();
await tx.wait(); // wait for mining
Note that Web3.js will return a PromiEvent which allows you to subscribe to confirmations, errors, and the transaction hash.
Ethers.js will return a transaction object where a bunch of information relating to the transaction is kept. You can grab the hash via tx.hash
, but you must await
on tx.wait()
if you want to make sure it has been mined.
Author: adrianmcli
Source code: https://github.com/adrianmcli/web3-vs-ethers
1632537859
Not babashka. Node.js babashka!?
Ad-hoc CLJS scripting on Node.js.
Experimental. Please report issues here.
Nbb's main goal is to make it easy to get started with ad hoc CLJS scripting on Node.js.
Additional goals and features are:
Nbb requires Node.js v12 or newer.
CLJS code is evaluated through SCI, the same interpreter that powers babashka. Because SCI works with advanced compilation, the bundle size, especially when combined with other dependencies, is smaller than what you get with self-hosted CLJS. That makes startup faster. The trade-off is that execution is less performant and that only a subset of CLJS is available (e.g. no deftype, yet).
Install nbb
from NPM:
$ npm install nbb -g
Omit -g
for a local install.
Try out an expression:
$ nbb -e '(+ 1 2 3)'
6
And then install some other NPM libraries to use in the script. E.g.:
$ npm install csv-parse shelljs zx
Create a script which uses the NPM libraries:
(ns script
(:require ["csv-parse/lib/sync$default" :as csv-parse]
["fs" :as fs]
["path" :as path]
["shelljs$default" :as sh]
["term-size$default" :as term-size]
["zx$default" :as zx]
["zx$fs" :as zxfs]
[nbb.core :refer [*file*]]))
(prn (path/resolve "."))
(prn (term-size))
(println (count (str (fs/readFileSync *file*))))
(prn (sh/ls "."))
(prn (csv-parse "foo,bar"))
(prn (zxfs/existsSync *file*))
(zx/$ #js ["ls"])
Call the script:
$ nbb script.cljs
"/private/tmp/test-script"
#js {:columns 216, :rows 47}
510
#js ["node_modules" "package-lock.json" "package.json" "script.cljs"]
#js [#js ["foo" "bar"]]
true
$ ls
node_modules
package-lock.json
package.json
script.cljs
Nbb has first class support for macros: you can define them right inside your .cljs
file, like you are used to from JVM Clojure. Consider the plet
macro to make working with promises more palatable:
(defmacro plet
[bindings & body]
(let [binding-pairs (reverse (partition 2 bindings))
body (cons 'do body)]
(reduce (fn [body [sym expr]]
(let [expr (list '.resolve 'js/Promise expr)]
(list '.then expr (list 'clojure.core/fn (vector sym)
body))))
body
binding-pairs)))
Using this macro we can look async code more like sync code. Consider this puppeteer example:
(-> (.launch puppeteer)
(.then (fn [browser]
(-> (.newPage browser)
(.then (fn [page]
(-> (.goto page "https://clojure.org")
(.then #(.screenshot page #js{:path "screenshot.png"}))
(.catch #(js/console.log %))
(.then #(.close browser)))))))))
Using plet
this becomes:
(plet [browser (.launch puppeteer)
page (.newPage browser)
_ (.goto page "https://clojure.org")
_ (-> (.screenshot page #js{:path "screenshot.png"})
(.catch #(js/console.log %)))]
(.close browser))
See the puppeteer example for the full code.
Since v0.0.36, nbb includes promesa which is a library to deal with promises. The above plet
macro is similar to promesa.core/let
.
$ time nbb -e '(+ 1 2 3)'
6
nbb -e '(+ 1 2 3)' 0.17s user 0.02s system 109% cpu 0.168 total
The baseline startup time for a script is about 170ms seconds on my laptop. When invoked via npx
this adds another 300ms or so, so for faster startup, either use a globally installed nbb
or use $(npm bin)/nbb script.cljs
to bypass npx
.
Nbb does not depend on any NPM dependencies. All NPM libraries loaded by a script are resolved relative to that script. When using the Reagent module, React is resolved in the same way as any other NPM library.
To load .cljs
files from local paths or dependencies, you can use the --classpath
argument. The current dir is added to the classpath automatically. So if there is a file foo/bar.cljs
relative to your current dir, then you can load it via (:require [foo.bar :as fb])
. Note that nbb
uses the same naming conventions for namespaces and directories as other Clojure tools: foo-bar
in the namespace name becomes foo_bar
in the directory name.
To load dependencies from the Clojure ecosystem, you can use the Clojure CLI or babashka to download them and produce a classpath:
$ classpath="$(clojure -A:nbb -Spath -Sdeps '{:aliases {:nbb {:replace-deps {com.github.seancorfield/honeysql {:git/tag "v2.0.0-rc5" :git/sha "01c3a55"}}}}}')"
and then feed it to the --classpath
argument:
$ nbb --classpath "$classpath" -e "(require '[honey.sql :as sql]) (sql/format {:select :foo :from :bar :where [:= :baz 2]})"
["SELECT foo FROM bar WHERE baz = ?" 2]
Currently nbb
only reads from directories, not jar files, so you are encouraged to use git libs. Support for .jar
files will be added later.
The name of the file that is currently being executed is available via nbb.core/*file*
or on the metadata of vars:
(ns foo
(:require [nbb.core :refer [*file*]]))
(prn *file*) ;; "/private/tmp/foo.cljs"
(defn f [])
(prn (:file (meta #'f))) ;; "/private/tmp/foo.cljs"
Nbb includes reagent.core
which will be lazily loaded when required. You can use this together with ink to create a TUI application:
$ npm install ink
ink-demo.cljs
:
(ns ink-demo
(:require ["ink" :refer [render Text]]
[reagent.core :as r]))
(defonce state (r/atom 0))
(doseq [n (range 1 11)]
(js/setTimeout #(swap! state inc) (* n 500)))
(defn hello []
[:> Text {:color "green"} "Hello, world! " @state])
(render (r/as-element [hello]))
Working with callbacks and promises can become tedious. Since nbb v0.0.36 the promesa.core
namespace is included with the let
and do!
macros. An example:
(ns prom
(:require [promesa.core :as p]))
(defn sleep [ms]
(js/Promise.
(fn [resolve _]
(js/setTimeout resolve ms))))
(defn do-stuff
[]
(p/do!
(println "Doing stuff which takes a while")
(sleep 1000)
1))
(p/let [a (do-stuff)
b (inc a)
c (do-stuff)
d (+ b c)]
(prn d))
$ nbb prom.cljs
Doing stuff which takes a while
Doing stuff which takes a while
3
Also see API docs.
Since nbb v0.0.75 applied-science/js-interop is available:
(ns example
(:require [applied-science.js-interop :as j]))
(def o (j/lit {:a 1 :b 2 :c {:d 1}}))
(prn (j/select-keys o [:a :b])) ;; #js {:a 1, :b 2}
(prn (j/get-in o [:c :d])) ;; 1
Most of this library is supported in nbb, except the following:
:syms
.-x
notation. In nbb, you must use keywords.See the example of what is currently supported.
See the examples directory for small examples.
Also check out these projects built with nbb:
See API documentation.
See this gist on how to convert an nbb script or project to shadow-cljs.
Prequisites:
To build:
bb release
Run bb tasks
for more project-related tasks.
Download Details:
Author: borkdude
Download Link: Download The Source Code
Official Website: https://github.com/borkdude/nbb
License: EPL-1.0
#node #javascript
1673116440
A guide to the basic differences between Web3.js and Ethers.js, the two most popular libraries for interacting with the Ethereum blockchain. And two example frontend apps using React + Hooks!
Inside the smart-contracts
folder, you will find a simple Truffle project with the following Solidity contract:
pragma solidity ^0.5.0;
contract Counter {
uint count = 0;
function increment() public {
count = count + 1;
}
function getCount() public view returns (uint) {
return count;
}
}
Before you run any of the frontend UIs, make sure to start the development console with truffle develop
, and then run the migrate
command to compile and deploy the contract onto the development chain.
There are two folders (app-ethers
and app-web3js
) each containing a simple React frontend for the above contract. The only substantial difference between these two UIs is located in the useCounterContract.js
files.
Here are the direct links for your convenience:
In each of these apps, you can serve the frontends with the following commands:
npm install
npm start
This will serve the frontend on http://localhost:1234
which you can view in your browser.
There are three major portions in this code: the setup, reading (calling a constant method), and writing (calling a non-constant mutating method).
With Web3.js, we need the following to instantiate a connected contract instance that can make read/write calls:
from
address (for send
transactions)Note that the networkId
is required for us to fetch the deployed address from our contract artifact.
// Web3.js
const web3 = new Web3("http://127.0.0.1:8545");
const accounts = await web3.eth.getAccounts();
const networkId = await web3.eth.net.getId();
const contractAddress = artifact.networks[networkId].address;
contractInstance = new web3.eth.Contract(artifact.abi, contractAddress, {
from: accounts[0],
});
With Ethers.js, we need the following for our contract instance:
Signer
object (similar to Provider
, but with a specified Signer
)// Ethers.js
const provider = new ethers.providers.JsonRpcProvider();
const network = await provider.getNetwork();
const contractAddress = artifact.networks[network.chainId].address;
contractInstance = new ethers.Contract(
contractAddress,
artifact.abi,
provider.getSigner(),
);
// Web3.js
const count = await contractInstance.methods.getCount().call();
console.log(count); // returns a String
// Ethers.js
const count = await contractInstance.getCount();
console.log(count); // returns a BigNumber instance
These two are very similar, but in our example Ethers.js returns a BigNumber instance by default whereas Web3.js will return the number as a String.
// Web3.js
await contract.current.methods.increment().send();
// tx has been mined
// Ethers.js
const tx = await contract.current.increment();
await tx.wait(); // wait for mining
Note that Web3.js will return a PromiEvent which allows you to subscribe to confirmations, errors, and the transaction hash.
Ethers.js will return a transaction object where a bunch of information relating to the transaction is kept. You can grab the hash via tx.hash
, but you must await
on tx.wait()
if you want to make sure it has been mined.
Author: adrianmcli
Source code: https://github.com/adrianmcli/web3-vs-ethers
1671818520
In this article, we will explore Web3.js Vs Ethers.js: Comparison of Web3 Libraries. In Ethereum development, there are two JavaScript libraries that are quite popular among developers, Web3.js and ethers.js. But which one is better? By comparing the two in an action-packed Web3.js vs ethers.js battle, we’ll see if there’s a reason why the blockchain industry has slowly migrated towards ethers.js and if this library deserves the top spot on the leaderboard compared to Web3.js. However, although both are popular libraries, many experienced developers have found another alternative that has proven to be more beneficial – the Moralis Streams API. Will this API ultimately bring an end to the Web3.js vs ethers.js debate? Let’s find out!
As we dive deeper into the upcoming sections, you’ll learn what ethers.js is. Before explaining what Web3.js is, you’ll also explore “ethers.js 2.0”. Once you know the basics of each of the two Ethereum JS libraries, we will do a thorough Web3.js vs ethers.js comparison. This will help you decide which ETH JavaScript library to utilize during your development endeavors. However, judging by the positive feedback from many dapp (decentralized application) developers who already use Moralis’ Streams API, we believe you’ll be eager to ditch Web3.js and ethers.js yourself. After all, this “ethers.js 2.0” provider is at your disposal with a free Moralis account.
So, what is ethers.js? Ethers.js is a JavaScript (JS) library that aims to be a complete and compact solution for Ethereum development. Since many other popular blockchains follow Ethereum’s lead and use the same virtual machine (Ethereum Virtual Machine [EVM]), this JS library also supports development on other EVM-compatible programmable blockchains. As such, it’s not surprising why some Ethereum devs listen to the blockchain with ethers.js.
In addition to JavaScript support, ethers.js also covers utility functions in TypeScript (TS). Furthermore, this library offers many neat features. For example, it comes with extensive documentation, includes a huge collection of maintained test cases, keeps your private keys in your client safe and sound, and lets you create JavaScript objects from any contract ABI, including ABIv2 and ethers Human-Readable ABI with meta classes. To help you form an even clearer picture of what ethers.js is and some of its other features than the ones stated earlier, let’s look at the following list:
At this point, we are one step closer to the Web3.js vs ethers.js section. However, by learning about “ethers.js 2.0”, you might lose interest in that comparison and decide to start building with that excellent tool right away instead. After all, many developers are now using the Moralis Streams API as an “ethers.js 2.0” alternative instead of ethers.js. Further, most devs will probably follow that path in the future. Moreover, it’s easy to see why when comparing ethers.js vs Web3 streams. The gist of this comparison can be summarized in the following image:
While both ethers.js and the Web3 Streams API support real-time events and multiple chains, ethers.js 2.0 (a.k.a. Streams API) takes things to the next level. Starting with reliability, with ethers.js, you cannot reach the highest levels since you have to depend on node providers. Further, you always need to ensure that the provider supports the chains you want to focus on and that the nodes stay live. On the other hand, Moralis’ Streams API takes that aspect out of the equation and offers 100% reliability.
With ethers.js 2.0, you also get to filter on-chain events. Accordingly, you can focus on the data that really interest you. Furthermore, the Streams API even offers you to cover multiple addresses. So, instead of creating separate listeners for all contracts, you simply pool them together under a single stream. With this advanced listening tool for on-chain events, you can even focus on wallet addresses. As such, you get to use any changes to any wallet address that interest you as a trigger. This enables you to take your dapps and customer service to the next level. Last but not least, unlike ethers.js, the Moralis Streams API provides you with parsed data. In turn, you do not need to worry about processing the data. Instead, you can focus on utilizing the responses right away.
It would be wrong to say that the ethers.js library is not a decent open-source solution for listening to the blockchain. After all, it gets the job done. However, as presented above, even this young ETH JavaScript library comes with several limitations, which will hold you back when creating dapps.
With that in mind, you must admit that there are many instances where having an alternative that covers all those additional options would be a real asset. After all, it would make listening to blockchain events a lot more user-friendly. Moreover, after looking at all the advantages listed in the picture above, it’s no surprise that devs are leaving ethers.js. However, before you determine if the Streams API is the right tool for you, make sure to learn more about it.
Explore the Moralis Web3 Streams API
Furthermore, when you create your free Moralis account, which is your key to the Streams API, you automatically gain access to other powerful tools. These include the industry-leading Web3 Auth API, the ultimate NFT API, and the best Token API. As such, you can create all sorts of killer dapps the easy way.
It’s worth pointing out that in the last two years or so, ethers.js became the go-to ETH JS library. However, to get the most out of the upcoming Web3.js vs ethers.js comparison, you need to know the basics of Web3.js as well.
Just like ethers.js, Web3.js is also an open-source JS library. However, it was on the scene one year before ethers.js and was created by the Ethereum Foundation. This library’s main purpose is to facilitate seamless interactions with the Ethereum chain. Furthermore, Web3.js establishes communication with Ethereum nodes through the “JavaScript Object Notation – remote procedure call” (JSON-RPC) protocol. A lot like ethers.js, this JS library also features modules. In fact, you can learn about its five modules below:
Ultimately, it’s safe to say that the two ETH JavaScript libraries are quite similar. They serve the same or very similar purposes. However, there are some distinct differences between the two that we’ll point out in the upcoming “Web3.js vs ethers.js” section!
To make this Web3.js vs ethers.js comparison as concise and convenient as possible, we’ll break it down into several categories. As such, we will look at the teams behind them, their popularity, downloads, updates, testing, web performance, documentation, and licenses.
Aspects | Web3.js | Ethers.js |
Teams | – The Ethereum Foundation – An extensive organization with many developers offering support – Lack of clarity of who is responsible for support | – Richard “RicMoo” Moore – Smaller team – Pretty clear who’s responsible for what |
Popularity | – First-mover advantage – More stars and repositories on GitHub | – Faster speed of growth and adoption |
Downloads | – 2018: 91,936 – 2019: 113,272 (+23%) – 2020: 161,257 (+42%) – 2021: 247,999 (+54%) – 2022: 587,567 (+137%) | – 2018: 53,863 – 2019: 66,959 (+24%) – 2020: 163,799 (+145%) – 2021: 304,273 (+86%) – 2022: 948,981 (+212%) |
Updates | – Relatively regular updates | – Relatively regular updates |
Testing | – No pre-written tests | – Pre-written tests and clear documentation of its tests |
Web Performance | – Larger in size – Loads slightly slower | – Smaller in size – Loads slightly faster |
Documentation | – Room for improvement – Provides all you need to get started – Link to the Web3.js documentation: https://web3js.readthedocs.io/en/v3.0.0-rc.5/ | – Room for improvement – Provides all you need to get started – Link to the ethers.js documentation: https://docs.ethers.io/v5/ |
License | – LGLv3 license | – MIT license |
The Ethereum Foundation created the Web3.js library and continues to back it. Since this is a large organization, there are many developers offering support. However, when many devs are involved, it also means that there is no clear distinction as to who is responsible for what. On the other hand, Richard “RicMoo” Moore developed ethers.js in 2016 and continues to maintain it. Hence, this also makes things clear about who’s responsible for what.
For a long time, Web3.js was overall a more popular option, mainly because it had the first-mover advantage. Further, according to the stats on GitHub, Web3.js is still in the lead – it has more stars and repositories. However, ethers.js’ speed of growth and adoption puts it in the leading spot. Moreover, looking at the downloads of these two ETH JS libraries, we must be careful not to focus on the overall number of downloads. After all, due to Web3.js’ one-year advantage, that wouldn’t paint a clear picture. Instead, you need to focus on daily downloads per specific year. According to Alchemy’s report from October 2022, ethers.js had nearly twice as many daily downloads as Web3.js in the first three quarters of 2022.
Nonetheless, as a developer, you know that updates are critical. Hence, you probably prefer a library that is always up-to-date and in the best possible shape. After all, it is via updates that support teams remove all known bugs and add new features. That said, both libraries do an equally good job in that aspect.
Ethers.js has pre-written tests and clear documentation, which puts it ahead of Web3.js in this perspective. However, it’s important to remember that every new version levels the field.
Out of the two ETH JavaScript libraries, ethers.js is noticeably smaller in size. The latter may be the main reason why it loads slightly faster than Web3.js. This may offer better performance, especially for smaller dapps. However, since one or the other library is used for various projects, there’s basically no data for the exact same dapps using Web3.js and ethers.js. Thus, the web performance aspect of the Wweb3.js vs ethers.js comparison remains non-conclusive.
None of the two ETH JS libraries maintains flawless documentation. However, both docs provide all you need to start working with them. Moreover, personal preferences play a key in that aspect. After all, what may be perfect documentation for one dev may feel poorly structured for another. As such, make sure to explore both docs and decide for yourself.
Note: Always check the version of the library and make sure to use the matching version of the documentation.
As you can see in the table outlined earlier, Web3.js has an LGLv3 license, while ethers.js has an MIT license. So, if your project has specific requirements regarding the license, you need to keep that aspect of the “Web3.js vs ethers.js” debate in mind. That said, in some cases, it is best to hire a license expert.
Bonus: For all of you who enjoy watching videos, here’s also a neat comparison of Moralis’ Streams API and ethers.js:
We covered a lot of ground in today’s article. Aside from quite a detailed Web3.js vs ethers.js comparison, we also provided you with summaries of each of the two libraries. As such, even if you’ve never used any of them previously, you now have a solid idea of what they are all about. Ultimately, you learned that in the last two years, ethers.js took the lead and became the ETH JavaScript library that most devs focus on. However, we also explained that there is a new tool many developers have decided to utilize instead – Moralis’ Web3 Streams API. Last but not least, you even had an opportunity to watch a video that neatly outlines the benefits of this future-proof tool.
Whether you decide to use Web3.js, ethers.js, or the Streams API, know that this industry is shaping the future of the digital world. As such, learning how to create killer dapps is a path that offers countless opportunities. With that in mind, make sure to expand your blockchain development horizons by visiting the Moralis docs, our Web3 YouTube channel, and our crypto blog. These outlets provide you with countless tutorials and topics that can help you become a dapp developer for free. For instance, some of our latest articles explain what web3.storage is, how Web3 storage works, what Palm NFT Studio is, and much more.
Of course, you may also take a more professional approach to your crypto education. In that case, enroll in Moralis Academy. There you can partake in countless courses to help you become blockchain certified. However, we recommend you start with blockchain and Bitcoin fundamentals to build a strong foundation.
Original article sourced at: https://moralis.io
1619588820
The Js at the end of both Node and React refer to the language of JavaScript. Node and React are both the frameworks of JavaScript. However, the ensuing language that both the frameworks have been the same, the use cases for both of these frameworks. However, they are totally different.
Some people might even argue that to find the difference between node js and react js is just like comparing a train to an airplane. Both of them work on an entirely different domain. The main reason why Node and React’s comparison is unfair is that Node.js is a framework to handle back-end, meaning it is developed to handle the server-side computations.
Meanwhile, React.js was developed to handle the User Interface and User Experience (UI/UX). Although glaringly present, the differences do not take anything away from the sheer power and the versatility that each of these frameworks brings into their respective domain. Another way to string together the main difference would be that neither Node.js or React.js are interchangeable at any stage of your web development project.
With that being said, there are individual minute differences that any developer should consider when working on their projects, such as the performance, the learning curve, the community of both the frameworks and microservices’ support. Listed below, you will find a comprehensive weighted comparison of node js vs. react js on the aforementioned grounds. But before we begin our comparison, we must first understand both Node.js and React.js intricately and discuss the various use cases of these technologies.
Read: Difference between NodeJS and Django
The need for a robust means to handle the backend, server-side development yielded the framework we know as Node.js. Node.js was developed by Google and is based out of their V8 engine present in their web browser, i.e., Google Chrome. Node.js is a lightweight framework mainly because of its event-driven nature and the fact that it does not block the I/O. Node.js really shines the brightest when used to host API’s, access the database for the website, and serve the HyperText Transfer Protocol.
Node.js enjoys a very diverse clientele, with major players like Netflix, Uber, and Trello, all making use of Node.js in their backend. The reason why each of these companies uses this framework is different. Netflix, the leading online content streaming service, has to conduct A/B testing; only then would they serve the 93 million active users of their streaming service. The lightweight nature of Node.js has allowed them to serve the content swiftly. They have both reduced their startup time by over 70% and improved their scalability by shifting to Node.js.
#node js #node js vs react js #react js
1643182957
Web3.js and Ethers.js are two popular JavaScript libraries for Web3 development. In this article we compare Web3.js vs Ethers.js!
These days, crypto developers can choose among multiple programmable blockchains to build on. And, while you can hear the term “Ethereum killers” being thrown around quite often, the first mover remains the king. As such, the majority of blockchain developers still focus on Ethereum. Moreover, since other programmable chains tend to follow Ethereum’s lead, most of them are EVM-compatible. Thus, the same JavaScript libraries can be used to deploy dApps (decentralized applications) across multiple chains. With that in mind, you ought to take a closer look at Web3.js vs Ethers.js comparison.
Herein, you will get a chance to learn what Web3.js and Ethers.js are. You’ll also learn about JavaScript modules. Moreover, we’ll take a quick overview of the modules of each of the two JavaScript ETH libraries. However, the core of this article is the Web3.js vs Ethers.js comparison. It will help you establish a clear picture of the benefits and disadvantages of each library. Moreover, it should also make things clearer why the majority of the crypto industry is moving towards the younger of the two libraries. With that said, you can also expect the ultimate Web3 development platform Moralis (a.k.a. Firebase for crypto) to soon start natively running Ethers.js.
#blockchain #web3 #moralis #ethers #javascript