I was just wondering about this. Can webpack work in the browser without doing any builds, like JSPM? Or is it the same as browserify?
I looked at the official docs and found no mention of this.
It's a module bundler. So closer to Browserify. You can, however, set it up in a watch mode easily. That way it deals with the builds on the background while you develop and examine the result in the browser.
Related
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
I made a Javascript file. Let's say the contents of it are this:
let myCoolAlert = (str) => {
alert(str)
}
// in a different js file (SO doesn't allow you to cross-file as far as I know
myCoolAlert('Hello World!')
I already hosted the JS file on a CDN. Now, I want it to be automatically hosted locally by whoever installed it if you install it via NPM. Is there a way to do this?
Also, I noticed that to do the same using Socket.io, you have to pass Socket.io to the HTTP/HTTPS server you created. Will I have to do this also? (I would prefer not).
Thanks!
Edit:
I am trying to make a better alert system (like sweetalert). I coded it in Javascript and works when using it through the CDN. However, I also want users to be able to install this via NPM (kind of like SweetAlert? I am not sure about that last statement however because I do not use it). When they install it with NPM, it's obviously going to be useless because it is for the browser. However, I want them to either:
Automatically have the source code needed available at a URL like localhost:3000(or server name)/betterAlert.js and be able to use that URL as a script in the HTML files
OR, have the user pass the HTTP or HTTPS server they created to the module (like socket.io does) and have it automatically host it from there.
Please note:
The code I am trying to bundle is native to the web. Will it still work with a bundler like webpack?
Is this possible? Thanks again.
To bundle client-side code and publish it through NPM you'll need to do a couple things: learn how to package and publish modules, and write some code that can be consumed. This means using module.exports or export to expose your library, depending on whether you want to use CJS or ESM. The consumer of your library can usually be assumed to be using Webpack, Fuse, Rollup, or some other bundler which knows how to deal with modules.
You can also use a tool like Rollup yourself to build and bundle up your library for different targets and apply various transformations to it (example from my own library boilerplate). Using a bundler like this makes more and more sense as your library inevitably grows larger.
Using modules like this rather than distributing through a CDN or in some other way that puts your library code on the global/window object is generally better for consumption in complex apps, large apps, and/or apps already being built with tools like Webpack (so, anything written in React, Angular, Vue, etc.). But having a CDN distribution is still a good idea for something like your library, since it may well be used by people building sites with jQuery and vanilla JS.
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
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.
I am writing desktop app with Electron from Github, and I am using React with it. One thing I notice is that because Electron uses io.js, I no longer need webpack to build my code like when I dev for client-side web app. However, I still need something that can load JSX. I am using Babel request hook, but it seems a little slow. I don't really need the ES6 features in Babel since they are supported in io.js.
Is there another way I can use JSX with Electron?
Thanks
Webpack is actually designed with Electron development in mind. What I need to do is to to specify in the webpack.config.js file is config target: 'atom'. Webpack will know that it is packaging an Atom (now known as Electron) app, and will not attempt to bundle packages such as fs, or any modules in node_modules. With webpack, I can configure babel to my heart desire, and I also get minification.
Update
As #eduludi has mentioned, the value for target is now electron.