I was learning babel and webpack and then it turns out I need to install node.js to run them both and I asked myself WHY? Then according to my research, we need node.js for webpack and babel since both of them were written in JS and to run that JS code which transpiles( for babel) and bundles up the code(for webpack). Also, another reason is that since both babel and webpack handles our JS code outside of the browser, this is the reason to use Node.js. Are these reasons true?
According to the Node.js website -
Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine.
Webpack and babel (along with many other tools you might use for frontend development) are written in javascript and since they are command line tools, they need a way to run outside of the browser (directly on your machine).
They could have used some other language to write the tools but since they chose to write them in javascript, Node.js is the only feasible options right now.
In case you are interested, the original creator of nodejs
Ryan Dahl has built another secure runtime environment for Javascript/Typescript called Deno
Yes, at the moment the node.js project is non-portable by full open source disclosure nor extension to port node.js commonjs without a just in time transpiler with a service worker on a server.
Definitions: FHC = "from half court"
Babel and webpack
(1) transpile/move (write&read, not ln -s sym...bolic link) & (2) compost/pile onto a JIT target,
like v8 or other browser-javascript-interpreters. v8 on a service worker can compile on the edge just in time for interpretation in a browser v8 environment but still on the cloudflare edge server.
Declare (FHC) Allegedly, rust provides webassembly modules with the lipid [llvm-]wrappings
that nucleic acid exocytosis needs to be a full-blown virus, err I mean
Initiation Routine needs to be a targetable JIT extension!
A compiler/transpiler still requires it's target-scope receivable. Declare (FHC) Emit is to execute as compile is to interpret, even AST.
Related
I recently started building a small project with TypeScript. It is a small application that runs some workflows based on received Webhook calls. This means that it exposes an Express app to handle these requests.
Currently I have an npm script that builds this project and transpiles it into JavaScript which can be then interpreted by Node.js. (The script runs: tsc --build --clean)
My question is, since this is not meant to be a library/package that will be published on NPM, is there any reason to transpile the project at all since I can just run it with ts-node?
I've been looking around for some information regarding this but couldn't find anything.
Are there any security, performance or any other implications when running the project directly with ts-node in a production environment instead of building it and running it with node?
It depends on the size of your project. Most people transpile because it improves performance, consumes less system resources and provides more stability.
But in a small project this won't make much difference, so using ts-node may be sufficient.
Recently I was create react app using vite , it is lightweight , less config and fast then compare with webpack . now my question is , is it required bable configuration in Vite project
No, vite does automatic syntax transforms but it only targets browsers that support es modules (firefox & chrome started supporting it around 2018). If you want to support new js features in older browsers you need to add polyfills though. You can read about the exact behavior and how to support even older browsers here.
I think that question need more information about that topic.
Vite.js uses the built-in JavaScript support of the browser, so you don't need to explicitly configure the JavaScript version in Vite.js itself.
When I said Vite.js uses the built-in JavaScript support of the browser, I meant that Vite.js relies on the JavaScript engine of the browser to interpret and run the JavaScript code in your application. The JavaScript engine is the component of the browser that executes JavaScript code. When you visit a web page that contains JavaScript, the browser runs the JavaScript code using its built-in JavaScript engine. This means that the version of JavaScript that is supported by your application is determined by the version of the JavaScript engine that is built into the browser. In the case of Vite.js, the JavaScript code in your application is not transpiled or otherwise modified before being run by the browser. However, if your application uses modern JavaScript syntax that is not supported by the target browsers, you will need to transpile the code to an older version of the language that is supported. In that case, you can use Babel.
No, it is already setup on the background. However if you'd like to adjust Babel's config you can do it. Read the docs here: https://github.com/vitejs/vite-plugin-react/blob/main/packages/plugin-react/README.md
When I first studied TypeScript, I found that node.js doesn't execute TypeScript, so you need to install a TypeScript compiler that converts your TypeScript code into JavaScript.
I searched until I found ts-node (TypeScript execution and REPL for node.js), but when I read the documentation I found that they do the same (here). Even deno (A modern runtime for JavaScript and TypeScript), is doing the same (here).
So my question is: are there any engines to execute TypeScript code without converting it to JavaScript?
No, TypeScript is not a "standalone" language in that sense. It is and always will be a superset of JavaScript. This is why the TypeScript Compiler is often referred to as a transpiler: it doesn't compile to a lower-level language. After tsc has run its checks it transforms existing source to JavaScript by simply stripping out all the TypeScript constructs.
From the intro of the official TypeScript Handbook:
The goal of TypeScript is to be a static typechecker for JavaScript programs - in other words, a tool that runs before your code runs (static) and ensures that the types of the program are correct (typechecked).
So in order to execute TypeScript, you will always need a JavaScript engine. You could adapt an existing JavaScript engine (or build your own) to understand TypeScript as well, but still it would always first have to be an engine conforming to the ECMAScript specification.
Deno is no different. It has a built-in TypeScript Compiler, which is a copy of the official one. From the TypeScript chapter of the Deno manual.
At a high level, Deno converts TypeScript (as well as TSX and JSX) into JavaScript. It does this via a combination of the TypeScript compiler, which we build into Deno, and a Rust library called swc. When the code has been type checked and transformed, it is stored in a cache, ready for the next run without the need to convert it from its source to JavaScript again.
After transpilation, Deno runs the output JavaScript on Google's V8 Engine, the same engine used in NodeJS and Chrome.
As of now there are no typescript aware V8-like runtime egnines.
It's unlikely we would see one. Sometime in the future TC39 will decide on official JS-With-Types proposal. And then typing and correspond
optimizations would be gradually added to V8 itself.
Though, it unlikely would be compatible with typescript directly, but easily transpilable back and forth.
At the moment there are several R&D AOT compilation (directly to static native binaries) projects for the typescript, or at least for the viable subset of it.
https://github.com/ASDAlexander77/TypeScriptCompiler
I have been using webpack to build a server side app using express. This code is harder to debug since I don't have the immediate comfort of a web browser and if I use something like VS Code to debug, it won't accept breakpoints inside request handlers when using source maps. Besides it takes no time to compile if I just stick to Node compatible JS and skip all transpiling and whatnot. Further, if I use treeshaking, I can reduce the size, but what is the point of that when it is running on the server (no client will ever download it).
My point is that I don't see why one would want to create a bundle of server side code if the server don't have any issues with memory or other limiting factors. It's easier to read, takes no time to compile and is easier to debug.
So a question. Is it ok to have the server app as an npm package and deploy that? Is that what is common or what do people do?
The project my team works on is a TypeScript monorepo that includes a web application and server-side daemon processes. We use webpack for producing build artefacts for all targets.
I've read some posts saying there's no point using webpack server-side because it was designed for web (obv), and I can understand that point of view.
However, even if our code was JavaScript and didn't require any transpiling, we'd still use webpack for the server-side. I want a single, minimal set of files and no node modules to deploy to the servers.
Size itself doesn't matter that much for server side (though every bit helps), but running 'yarn install' on servers is out of the question IMO.
In web project server side/backend is packed and bundled by webpack in node mode (https://webpack.js.org/configuration/node/) to achieve one independent bundled distributed file, like for client/frontend side.
But there is one problem: that project is dependent on Socket.io library, and server-side part of socket.io contains following line: https://github.com/socketio/socket.io/blob/master/lib/index.js#L110 , which implies load some library part at runtime.
Such behavior causes problems in bundling server side by webpack, because socket.io-client library is not required directly by require operation, and that's why does not compile into bundle.
Of course, it's potentially possible to develop own Webpack plugin, which will search and operate over require.resolve invocations, for example, by resolving target files and place them in memory file system or pack into bundle as resources. But it not simple manual work, and most probably well-known solution is exists.
For example, maybe is there already bundled version of library for webpack usage?