Can i migrate my Node based project to Deno? - javascript

Hello I am a frontEnd developer.
First, I don't know much about the runtime environment.
Is it possible to convert my project into Deno with Node?
Even if I change all of my code,
I'm not sure if the libraries I've received can run in a Deno environment.
(too many libs...) (React, Apollo, many many many)
And since the current webpack settings are very complex and difficult to understand, (And I understand very little about the build system.)
I am not sure if this can work in a Deno environment.
In my opinion, it seems impossible, I will only use Deno when working on a new project, Or wait for someone to create a migration guide.
What do you think about this?
Add
Obviously, it would be impossible if the libraries I used were not registered in the Deno repository.
And second, there seems to be a node compatibility issue.
Now i am sure that i can't covert it to deno.
Thanks

There is Denoify.
This tool takes as input a TypeScript codebase that was meant to target node and/or the web and spits out a modified version of the source files that are ready to be deployed as a Deno module.
It also helps to deploy on both NPM and deno.land/x
However, it is still under active development, not all node builtins are supported yet and you will probably have to make some changes here and there on your codebase to comply with the requirement Denoify sets.
Also, I am the author.

You're using many npm packages in your node project.Deno doesn't work with them.So either you'll wait to deno to be mature enough or you're gonna keep building your projects with node until that time.So i think if you want to take full advantage of deno, you should wait for deno to mature

Any code you write in pure JavaScript or TypeScript will work both in Node.js and Deno.
However, it's more than likely you have used Node.js-specific features in your current project. requires, calls to native Node.js APIs like http, util, and many others will not work in the Deno runtime.
Also, these kinds of Node.js-specific APIs are used in most Node.js libraries, so you'll have to do a complete rewrite to Deno.

I am not sure enough but as you have a Node.js project you should be using npm packages so until and unless those npm packages you use have alternative Deno packages it isn't possible if not then as #IsaToltar said to wait for it to be mature enough.
but if you can tell us what third-party npm packages you use then we might be able to find an alternative Deno package for that.
I hope it helps.

Deno now supports node-based projecs + NPM, it is considered to be stable, although still a work in progress.
To learn more, take a look at:
https://deno.land/manual#v1.29.2/node https://deno.land/manual#v1.29.2/node/how_to_with_npm https://deno.land/manual#v1.29.2/node/std_node

Related

Why JavaScript frontend framework is needed for Node.js to run?

When we talk about JavaScript vanilla it's frontend programming language; It needs a webserver like IIS, Apache or nginx etc to deliver the content to a client when requested. After that, JavaScript runs on client browser, but every video or article I found said we need to install node.js to make this work. What I know about node.js is its a runtime environment to make JavaScript work outside the browser; like for a backend api or regular desktop application.
Here is my question:
Why do we need to use Node.js if our target is to deploy a frontend webapp that's gonna run on the client browser?
You don't have to install and use Node to make frontend applications, but it can help a lot, especially in large projects. The main reason it's used is so that script-writers can easily install, use, and update external packages via NPM. For a few examples:
Webpack, to consolidate multiple script files into a single one for production (and to minify, if desired)
Babel, to automatically transpile scripts written in modern syntax down to ES6 or ES5
A linter like ESLint to avoid accidental bugs and enforce a consistent code style
A CSS preprocessor for Sass that can turn (concise) Sass into standard (more verbose) CSS consumable by browsers
And so on. Organizing an environment for these sorts of things would be very difficult without NPM (which depends on Node).
None if it is necessary, but many find that it can make the development process much easier.
In the process of creating files for the client to consume, if you want to do anything more elaborate than write plain raw .js, .html, .css files, you'll need something extra - which is most often done via NPM.
It's only for extra support during development, and ease of installing libraries. almost like an extra IDE / helpful editor
for example you might want to see changes you make on your HTML and frontend javascript code, without having to refresh the preview browser. node will provide a package that does that...
it also helps install and use libraries easier. for example, if you want to add a library like bootstrap to your frontend, rather than searching around and downloading the files... but if you use node project, you can simply use npm install bootstrap that will automatically download the lastest version from the right source.
that's all

Is it ok to refer to node_modules directly?

The project I'm currently working on (Java/JSP) currently uses no package manager to manage its JavaScript dependencies.
The used libraries are just committed under version control, and referred as such from the JSP pages...
I would like to evolve to a workflow were we would use a package manager (e.g. yarn), and later on eventually also webpack to further optimise the build.
I would like to do this in a phased approach. As I have little to none experience with such a frontend workflow, I have some questions:
Would it be weird to just start with defining the used libraries in a package.json file, and use yarn to manage to package?
yarn will then fetch the modules and store them in the node_modules folder.
Is it bad practice to refer to the scripts in that node_modules folder directly from within the JSP files?
Example
package.json:
"dependencies": {
"jquery": "^3.4.1"
}
app.jsp:
<script src="node_modules/jquery/dist/jquery.min.js"></script>
Yes, that's completely ok. It's the way we normally initialize frontend projects (probably sometimes, some higher-level script does it for us but still). Just run npm init.
Oh yes, that's quite bad. Most probably, it simply will not work. If you want to load something directly on a page, you need a cdn version.
To be honest, having a package.json is not that useful without a building tool like webpack, gulp or grunt.
UPD:
Regarding why loading things directly from node_modules might hurt:
A lot of modern JS packages (like, for instance, React) use modules that are not implemented yet in any browser or ES5+ syntax which is supported only by some browsers.
This way, you may load React directly but it will crash in any browser with something like import is not defined.
Basically, a lot of modern packages expect you to either have a building tool or use cdn version.
Honestly, I don't know how many packages let you seamlessly load things directly from node_modules.
So, in your particular situation, I'd say that if particular packages you use let you do so & are shipped with browser-compatible version, you can just go ahead & do it this way.
Nevertheless, I see it highly possible that sooner or later you will face a package that will not let you to include it this way (or worse: it will, but will crash some browsers that don't support latest JS features/introduce other nasty bugs in your app).
Hopefully, at this stage, you will already have the building tool configured.
Bonus:
Relatively recently some browsers started to support modules!
There are even tools like snowpack that do something particularly similar to what you are looking for.
Even though, you still need to be very careful with this. Direct inclusion of lodash.js, for instance, will generate 640 GETs (check out this article -> "Libraries" section).
NPM packages are meant to be run with Node, not in a browser. You would need to serve a browser-friendly version, using something like webpack or browserify.

Why angular 2 need node.js

I don't have experience in front-end but I want to create a simple app using Angular 2.
Why do I need to install Node.js as a prerequisite step? Why does Angular use Node.js?
There are a couple of things that Angular uses Node.js for:
Installing and managing packages. From the Quickstart tutorial:
Angular application developers rely on the npm package manager to install the libraries and packages their apps require. The Angular team recommends the starter-set of packages specified in the dependencies and devDependencies sections.
Compiling the TypeScript used into JavaScript that the browser understands - browsers can't process TypeScript natively and the SystemJS imports used in your code aren't supported in browsers yet:
We strongly recommend transpiling (AKA compiling) to JavaScript during a build phase before running the application for several reasons including:
We see compiler warnings and errors that are hidden from us in the browser.
Precompilation simplifies the module loading process and it's much easier to diagnose problems when this is a separate, external step.
Precompilation means a faster user experience because the browser doesn't waste time compiling.
We iterate development faster because we only recompile changed files. We notice the difference as soon as the app grows beyond a handful of files.
Precompilation fits into a continuous integration process of build, test, deploy.
node.js is required in order to install the library using the node package manager (npm).
It is not required to run an app using angular2, only to build it.
For any modern JS based application, as the complexity grows, the app becomes difficult to manage.
In order to make developing and managing complex applications simpler, there are frameworks such as Angular, React etc. and they provide number of tools for the same.
These tools are linting, scaffolding, running unit test cases, starting web server for local development, minify and creating build for the production use etc.
These tools are based on NodeJS as it is JavaScript only and therefore can be customize as per developers needs.
And that's the reason you need Node.js for Angular2 development.

How to set up an automated testing environment for AngularJS

I have spent hours trying to set up an automated testing environment for my AngularJS applications that I can run from Maven (capturing results in Bamboo)
A Google search reveals frameworks galore, based on Jasmine, Karma and generic JavaScript frameworks.
But for some reason the installation of these never goes as described.
Can anyone just point me to a set of downloads that I can install manually to proper directories, that will just execute my unit tests?
I asked a similar question previously and got down checked and requests to close. If you need to check me down, please leave a reason, as I am besides myself with frustration trying to solve this, and I am sure there many other developers experiencing the same issue
Testing javascript is not a totally mature thing, so there isn't a great diversity of good tools for doing so. Jasmine and Karma are the current best ways of doing that.
Those tools are best managed using bower, which is a nodejs package. So you'll have to install, in this order:
nodejs
npm (node package manager)
bower (using npm)
jasmine and karma using bower
phantomjs, and whatever other dependencies your javascript needs (presumably angular)
Then you can run the tests.
I found this package for maven with some brief googling, but god knows how to set it up:
http://searls.github.io/jasmine-maven-plugin/
There are many tutorials on going through this process. You have to accept that these are currently the best tools for doing this and give it your best shot. If you post more specific issues regarding the 'installation that never goes as described' of jasmine and karma you will get assistance.
you can use for example yeoman or angular-seed. both will require nodejs and optionally ruby. both will set you with phantomjs, jasmine, karma, bower and many more. however i would avoid combining that build with maven. imho it's far from perfect. java tools will never be as good as native js tools for building js project. if you really want to combine the builds then use java only to call nodejs and nothing more

How do Bower and NPM couple together?

So to preface my question, I'm coming from a Java back-end developer perspective, where we use Maven to build. I have worked on testing on a server-side Node project we recently developed, but now I'm moving on to setting up testing on our front-end JavaScript client. I'm not very well-versed in front-end development and this is really my first foray into that.
All that being said, I'm thinking I'm going to use the following technology stack for our front-end testing: Eclipse IDE, Maven build process, Mocha testing framework, Chai assertion framework, Nock HTTP mocking framework, Sinon mocking/spying/stubbing framework, Rewire dependency injection framework. That all should be fine, and since that's the stack we use for our Node project, I would like to keep the front-end setup as similar as possible.
So, this is where my knowledge breaks down, though. I cannot seem to understand the difference in dependency management between our Node project and our front-end JavaScript project. I cannot see why I would not continue to use NPM, integrated into our Maven build, to handle dependency management and installation.
I see many people advocating Bower, but after looking at its page and docs, I still am not seeing what niche it fills that NPM would not. I am seeing a lot of adamant rejection of NPM insofar as browser dependency management goes; the main reasoning being that NPM is designed for server-side Node projects, and not for the front-end space. But who cares? Regardless of its initial design's intentions, if it does what I need it to do, where is the downside?
Please approach this "question" as if I am a complete newbie. I have realized as I've gone through this process and research, that I have very large dearths of knowledge in regards to the front-end side of things. With that being said, be as specific and thorough as possible in your answers, please. I would be happy to share project configuration and such, as needed, in order to help paint a picture of the space I'm in. Thanks for any feedback!
Bower and NPM do work differently.
NPM is very powerful and great at what it does. However, you won't find many client-side packages in there; most of them are there because they work in Node too. (For example, Underscore.JS and the JADE template engine.)
That's why you have Bower, which has the majority of the client-side packages. It has many jQuery plugins, templating engines, CSS frameworks, etc. Don't expect to find such packages in NPM.
You can work fine with both. I do so. :)
Traditionally, many web development projects combined npm and Bower. npm was used to manage back-end dependencies, while Bower was used for front-end dependencies. In fact, you needed to use npm in order to install Bower in the first place.
Although Bower’s advantages were compelling, they are now provided by other tools, namely npm, Yarn and webpack. While the open source project is still maintained, its creators decided to deprecate it, and advise how to migrate to other solutions—namely Yarn and webpack.
more explanation

Categories

Resources