Hi Gophers!
This GopherJS release is one of the biggest in a long while, and we would like to give you a bit more details about it and the changes to come:
Go 1.18 supportFirst and foremost, this release brings compatibility with Go 1.18, with only one caveat generics are not supported yet. We know many of you are excited and want to be able to use them in your projects, so implementing generics is at the top of our todo list 📃
We debated whether to release GopherJS 1.18 now, or delay until generics are ready, and ultimately decided that for many of our users generics are not as important as being able to use a supported Go release. At the same time, we can't say that Go 1.18 is complete without generics, so we decided to mark this release as GopherJS 1.18.0-beta1, and we will publish a stable 1.18.0 release as soon as generics are ready for use.
We are also aware that Go 1.19 was recently released, and we will begin working on supporting it soon, stay tuned.
Changes toGOOS/GOARCH used by GopherJS.
Historically, GopherJS used GOARCH=js and GOOS=<your host system> (for example, linux) when building Go code. This led to numerous difficulties in maintenance (trying to make OS-specific code in the standard library compatible with the browser environment) and for the users (build errors on Mac OS and Windows machines).
Starting from 1.18, GopherJS will use GOOS=js and GOARCH=ecmascript when building code outside of the standard library and GOOS=js GOARCH=wasm when building the standard library itself. With this change come the following benefits:
In addition, now GopherJS always sets the gopherjs build tag, which you can also use to target GopherJS compiler specifically (not just any compiler that may compile Go to ECMAScript).
To make the transition easier, the build toolchain will accept different GOOS/GOARCH combinations when provided explicitly: GOOS=linux GOARCH=js gopherjs build ./.... This will be honored when building the code outside of the standard library, but the standard library itself will still be built with GOOS=js GOARCH=wasm. We plan to remove this override support on GopherJS 1.19 or 1.20.
node-syscall extension is now deprecated.
In the past NodeJS users needed to build a custom node-syscall extension to be able to access file system in GopherJS programs. Starting with GopherJS 1.18 this module is no longer necessary, we implemented file system access (and a few other OS interfaces) using Node's own fs and process APIs. It is also now possible to use file system in a browser environment using a shim like BrowserFS, which implements several different ways of emulating Node's fs APIs in the browser.
If your code relies on being able to make raw syscalls, you can use gopherjs build --tags legacy_syscall ... to re-enable it, see details in the documentation. We plan to remove node-syscall support completely in GopherJS 1.19 or 1.20.
GopherJS now targets ECMAScript 2015 compatibility for its generated code. Even though the generated code was syntactically compatible with ECMAScript 5, we've been already relying on some of the ES2015 APIs (such as typed arrays), and starting with GopherJS 1.18 we begin using ES2015 syntax in the generated JavaScript code.
Using more modern versions of ECMAScript unlocks new features and performance improvements. For example #1137 reduces the size of compiled code by 3% after minification and gzip compression.
As the time passes, we may begin targeting newer versions of ECMAScript in order to improve GopherJS's performance and features. ECMAScript version policy in our wiki defines our strategy for this.
What's ChangedFull Changelog: v1.17.2+go1.17.9...v1.18.0-beta1+go1.18.5
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4