Apply suggestions from code review

Co-authored-by: Alessandro Pignotti <alessandro@leaningtech.com>

Author: GabrielaReyna

content/blog/CJ-3-1-roadmap.mdx

@@ -123,30 +123,30 @@ To keep things simple let’s focus on the Minecraft 1.0 release. It was compose
 
 LWJGL, on the other hand, it’s only superficially Java. Most of its value comes from JNI methods which provide direct access to each and every method exposed by OpenGL. These methods are written in C and automatically generated by the LWJGL build system from a declarative representation of the OpenGL API.
 
-As of the 3.0 release we could get Minecraft to partially work by manually implementing a small subset of the LWJGL [JNI methods](https://cheerpj.com/docs/guides/implementing-native-methods) directly in JavaScript, but this method turned out to be extremely time consuming. Moreover, Minecraft is built on legacy OpenGL techniques which do not directly map to WebGL capabilities. The end result was promising but underwhelming, with lots of manual effort required to achieve a poorly rendered and slow version of the game.
+As of the 3.0 release we could get Minecraft to partially work by manually implementing a small subset of the LWJGL [JNI methods](https://github.com/leaningtech/cheerpj-natives) directly in JavaScript, but this method turned out to be extremely time consuming. Moreover, Minecraft is built on legacy OpenGL techniques which do not directly map to WebGL capabilities. The end result was promising but underwhelming, with lots of manual effort required to achieve a poorly rendered and slow version of the game.
 
-The solution to all these problems is to simply compile more things to Wasm. CheerpJ 4.0 will support loading of WebAssembly modules at runtime. These modules can be generated from C/C++ code coming from either JNI modules or arbitrary libraries required by Java applications.
+The solution to all these problems is to simply compile even more things to Wasm. CheerpJ 4.0 will support loading of WebAssembly modules at runtime. These modules can be generated from C/C++ code coming from either JNI modules or arbitrary libraries required by Java applications.
 
-In the case of Minecraft there are several moving parts
+In the case of Minecraft there are several components:
 
 - **lwjgl2.wasm**: Is generated from the unmodified C code generated by the LWJGL build system. It exposes all the native methods of LWJGL, completely removing the need to manually write any code in JavaScript.
-- **gl4es.wasm**: Is a WebAssembly build of gl4es [LINK], a FOSS library that implements legacy GL on top of GLES
+- **gl4es.wasm**: Is a WebAssembly build of [gl4es](https://github.com/ptitSeb/gl4es/), a FOSS library that implements legacy GL on top of GLES.
 - **gles.wasm**: A WebAssembly module mapping GLES APIs to WebGL, which will be automatically provided by CheerpJ.
-- **X11.wasm**: A background process providing X11 emulation to integrate native Java windows and windows created for OpenGL rendering.
+- **X11.wasm**: A background process providing X11 emulation to integrate Java windows and windows created for OpenGL rendering.
 
 The end result of this stack is Minecraft rendering correctly in the browser via CheerpJ, with the level of performance being already quite good and with more improvements planned before CheerpJ 4.0 is released.
 
-All these WebAssembly modules can be generated without any change to the original code using Cheerp, our C/C++ to WebAssembly/JavaScript compiler. This is possible thanks to new Cheerp features that will soon support compiling any unmodified Linux C/C++ applications to WebAssembly. Stay tuned for more information and join our [Discord server](https://discord.leaningtech.com/) to be always updated on all our products.
+All these WebAssembly modules can be generated without any change to the original code using Cheerp, our C/C++ to WebAssembly/JavaScript compiler. This is possible thanks to new [Cheerp](https://cheerp.io) features that will soon support compiling any unmodified Linux C/C++ applications to WebAssembly. Stay tuned for more information and join our [Discord server](https://discord.leaningtech.com/) to be always updated on all our products.
 
 ### All of this, only for Minecraft?
 
 As it often happens with our [development tools](https://labs.leaningtech.com/), solutions might be inspired by a specific use case, but are always designed to be generic.
 
 Popular toolkits such as SWT and JavaFX, that are also not currently supported by CheerpJ, have very similar characteristics to the Minecraft/LWJGL use case:
 
-- **Shallow Java surface** with lots of C/C++ JNI logic;
-- **Dependency on large C libraries**, GTK in particular;
-- **X11 requirement**, particularly for SWT;
+- **Shallow Java surface** with lots of C/C++ JNI logic
+- **Dependency on large C libraries**, GTK in particular
+- **X11 requirement**, particularly for SWT
 - **OpenGL requirement**, particularly for JavaFX
 
 It is clear that the building blocks to successfully run Minecraft in CheerpJ are the same required to achieve SWT and JavaFX support.
@@ -192,7 +192,7 @@ For questions, discussion, and support, [join our Discord](https://discord.leani
 
 ---
 
-CheerpJ is a product built with passion and a lot of coffee by Leaning Technologies, an international team of WebAssembly hackers based in Amsterdam (NL) and Leeds (UK). We hope you’ll find it as exciting as we do.
+CheerpJ is a product built with passion and a lot of coffee by Leaning Technologies, an international team of WebAssembly hackers based in Amsterdam (NL) and Leeds (UK). We hope you’ll love it as much as we do.
 
 <LinkButton
 	href="https://github.com/leaningtech/cheerpj-meta"