In the React Starter Kit they bundle with Webpack the server-side code into a server.js which I assumed can be handy but then I started wondering why bundling up the server-side code in the first place, after all Node comes with its own dependency management and doesn't need that. Second, wouldn't that even make it more inefficient due to parsing one whole file?
React code usually got written in ES6 however the Node doesn't support the es6 code yet, it can only understand es5. so if you want to use it without bundling and all the code will get complied first on the go. which will affect the performance eventually so you can use it for the development purpose but in production it is advised to use the bundled code.
So the major reason is Performance
Related
I am running on a huge project with thousands of .js files that are written in es5, and for many reasons and benefits of TS, we've decided to start migrating to TS, after a couple of days and many pieces of research, I am going to elaborate a couple of points:
To start migrating from es5 to ts we can start either by two ways:
First way:
1- Installing ts, creating tsconfig with allowJS set to true then start changing the extension of files to .ts and everything will work by default
2- As we want to migrate gradually we don't want at once to replace the global scripts to native modules, in other words, we don't want immediately to type import and export, but instead we want to keep the old way global scripts and use /// <reference path=""> to load dependencies
3- after previous step we can gradually start turning the files into native modules esm
Second way:
1- As I've read about UMD it will work on both borwser(client) and server, which means support all type of modules AMD, CommonJS, SystemJS and Native ES modules
2- after re-writing the scripts in UMD fashion, we can gradually start moving our scripts to ESM
last but not least, and regarding the intelligence we'll start writing .d.ts files accordingly or we can rely on ts-loader to generate the files
lastly, we either go with ts-loader or babel but we are not sure if there are couple of limitations for each of which
Any idea is really appreciated on what is the best way to start migrating
Maybe this tool can help you:
https://github.com/airbnb/ts-migrate
ts-migrate is a tool for helping migrate code to TypeScript. It takes a JavaScript, or a partial TypeScript, project in and gives a compiling TypeScript project out.
ts-migrate is intended to accelerate the TypeScript migration process. The resulting code will pass the build, but a followup is required to improve type safety.
If possible, start fresh and write migration script which does copy/paste task of code. In which Project setup will be error free in term of compile/build/run/lint. So even in future there won't be any issue you just need to add modules. You can migrate module by module.
Now if you are migrating to TS means not just by extension or package type, because it won't benefit more, you will need to change in code like types, interfaces, configs etc.
So starting a fresh project and then converting code to TS and then gradually moving should be better.
I would suggest you should write new modules in typescript and slowly convert existing files and modules to typescript. But keep the output in js only. Convert each ts file into js, For e.g, if you have a module Utils create two folders inside this ts and js. Write a build script which will convert ts to js and move inside the js folder. This way you will be converting all files into ts. For import/export you can start it for the new module. I have done the same in one project.
Regards,
omi
I appreciate all the answers but for my case it is so complicated because ts modules will affect the scope, what I found useful is using what so-called shimmer modules in webpack which allows a feature called imports-loader which I can use to manipulate the scope of js, hence nothing is broken, then I can move file by file to start migrating
If I import a JavaScript package which uses PReact or other frameworks in my Svelte project, will Svelte compile it?
Will Svelte compile the PReact framework and the package using it? This should not lead to any performance issue or size issue for that matter, as PReact is small and Svelte will compile it.
But my question is still, will Svelte compile the PReact framework when I use it in my Svelte project? Because if so is it better to exclude it (not compile it) or just not care? I am wondering for best practices.
EDIT:
I'm importing FullCalendar which is a preact app
Svelte is a compiler in the sense that it takes .svelte files and turn them into .js (conceptually at least). After you've run the compiler, via bundler plugin or otherwise (e.g. directly through the compiler API), you end up with JS code that doesn't rely on a full-fledged runtime to be executed (we could call that "low level" JS from a framework perspective).
Said otherwise: Svelte's compilation is focused solely on transforming Svelte syntax (as found in .svelte files) into "raw" Javascript.
Svelte compiler has no notion of the rest of your code, outside of .svelte files -- for example, what comes from .js files in your codebase or, pertaining to your question, what comes from other libs like Preact. From the point of view of the compiler, they are just imports from the outside and, in the end, they are just variables in the Svelte code.
So the answer to your question is: no, Svelte won't compile Preact or anything that is not Svelte syntax.
Resolving external imports would be a problematic of your browser (if using raw ES imports) or, more typically, of your bundler (e.g. Rollup, Webpack...). It is the bundler that will read your import statements, try to resolve them in your node_modules, rewrite everything to play together, optionally apply some code transformations (like transforming TS, SCSS or Svelte to raw JS), optimize them, pack them together for optimal performance, etc. Svelte changes nothing in this regard.
As a more personal opinion, it doesn't seem to make a lot of sense to use Preact in Svelte. You essentially have everything you'd have in Preact already in Svelte. The reverse would seem more logical to me -- using some "framework agnostic" (once compiled) Svelte components in an existing app using another technology.
We are planning to switch new technologies like react for my CMS project which is under development for 10 years.
Until now everything was simple and plain on the front end.
First include jquery.js then if necessary include the components and third party scripts, then code and dance with the DOM.
But now while trying to jump into a higher level of technology and different approach, things can easily get very complicated for me.
After spending more than 10 hours with React documents and tutorials I have a very good understanding about what it is and how it works.
But I realized that I am very unfamiliar with some popular concepts. I never used node.js, never used npm, babel, webpack, and may other many "new" things I have seen every where. I am face to face with these tools because of React and I am convinced that these are the inevitable for modern front end development.
Now the question
Our CMS runs on PHP and depends on MooTools heavily at the front end. Instead of a complete rewrite of a 10 years old CMS I just want to try new technologies partially for some cases. Decided to starting with React.
For the case I want to integrate ag-Grid to React also.
What I did not understand is that how to bring all these tools together.
I won't be able to use the simply include js way of react because of ag-Grid.
In the examples the code written has some JSX. Which means that we write JSX and run it translated for the browser to test if it is ok.
Each time before testing do I need to translate these files?
And more over if the files are translated does debugging become very
complicated?
Can babel make it on the run time? If yes is it a good practice.
There are lots of file in the node_modules folder. Which of them
should I include for production?
All sources on the net are very theoretical and assumes a knowledge. Need some guidance for best practices.
There are lots of questions and not a single step by step guide from beginning to production.
JSX is an extension over spec-compliant JavaScript. It is syntactic sugar for React.createElement(...) and is optional in React development.
React can be written in plain ES5:
React.createElement("div", { foo: "foo" });
Instead of JSX:
<div foo="foo" />
Or with helper functions like h that achieve the same goal, e.g. react-hyperscript.
The fact that there is PHP backend application doesn't prevent from developing React frontend application with JSX. This may require to configure React project to not use built-in Express web server and build client-side application to custom location, i.e. existing app's public folder. In case create-react-app is used, this may require to eject the project).
Each time before testing do I need to translate these files?
They should be transpiled to plain JavaScript (ES5 if it targets older browsers). They can be translated on every change in source files when client-side project runs in watch mode (conventionally npm start).
And more over if the files are translated does debugging become very
complicated?
This is what source maps are for.
Can babel make it on the run time? If yes is it a good practice.
It's possible to use Babel at runtime, and this isn't a good practice, even in development environment.
There are lots of file in the node_modules folder. Which of them
should I include for production?
The contents of node_modules doesn't matter. Almost all of them are development dependencies that are needed to build client-side app. This is the task for a bundler, which is Webpack in create-react-app template. It builds project dependencies to plain JS in dist folder.
Due the fact, that ES6-modules (JavaScript-modules) are available for testing:
https://www.chromestatus.com/feature/5365692190687232
https://medium.com/dev-channel/es6-modules-in-chrome-canary-m60-ba588dfb8ab7
I wonder, how should I minify and prepare the project release-file? Earlier, I havde bundled all JavaScript-files into the single and minified file, except situations, where I have to load the JS-file dynamically via XHR or Fetch API.
As I understand, it's rather impossible to prepare a single-minified file with the ES6-modules right now or may be, I'm just misunderstanding some ways of work.
So, are the any ways to prepare my ES6-modules into single file and how I should prepare the modern JavaScript-project in 2017 year, where JavaScript-modules will be available?
I wonder, how should I minify and prepare the project release-file?
That is purpose of this action? Okay, minified files take fewer network traffic, and will be downloaded faster, but most NPM libraries provides minified dist-files already. And main question about bundling in one big file.
Why webpack do it? Of cource, due absence of support for ES-modules in browser by native, What's why webpack resolves import statements and round dependencies in synchronous manner*, and then substitute it to IIFE for scoping. And perform babel translation and polyfilling, yes.
But then native support of ES-modules is started, it's become un-useful. One of main goals when exposing your web-app to production, is minify traffic volume for your server, using CDN. Now you can do it in native way, so just import ES-modules from unpkg.org and be happy
*If not using HMR, of course, But it's not appropriate for production mode.
Live examples here: https://jakearchibald.com/2017/es-modules-in-browsers/
This blog explains how you would use the ES6 module syntax and yet still bundle your code into something that the browser will understand.
The blog explains that using SystemJs as an ES6 module polyfill and Babel along with Gulp will enable you to code you modules in ES6 yet sill be able to use it today.
https://www.barbarianmeetscoding.com/blog/2016/02/21/start-using-es6-es2015-in-your-project-with-babel-and-gulp/
Using this guide will help you write your code in ES6 while still having a normal workflow to building, minifying and bundling your code.
Keep in mind there are a lot of tools out there that will help you achieve this but I've followed this method many times and I can vouch for its validity.
I want to ask if it is possible (and generally a good idea) to use npm to handle front-end dependencies (Backbone, jQuery).
I have found that Backbone, jQuery and so on are all available through npm but I would have to set another extraction point (the default is node_modules) or symlink or something else...
Has somebody done this before?
Is it possible?
What do I have to change in package.json?
+1 for using Browserify. We use it here at diy.org and love it. The best introduction and reasoning behind Browserify can be found in the Browserify Handbook. Topics like CommonJS & AMD solutions, build pipelines and testing are covered there.
The main reason Browserify works so well is it transparently works w/ NPM. As long as a module can be required it can be Browserified (though not all modules are made to work in the browser).
Basics:
npm install jquery-browserify
main.js
var $ = require('jquery-browserify');
$("img[attr$='png']").hide();
Then run:
browserify main.js > bundle.js
Then include bundle.js in your HTML doc and the code in main.js will execute.
Short answer: sort of.
It is largely up to the module author to support this, but it isn't common. Socket.io is an example of such a supporting module, as demonstrated on their landing page. There are other solutions however. These are the two I actually know anything about:
http://ender.no.de/ - Ender JS, self-described NPM analogue for client modules. A bit too involved for my tastes.
https://github.com/substack/node-browserify - Browserify, a utility that will walk your dependencies and allow you to output a single script by emulating the node.js module pattern. You can use a jake|cake|rake|make build script to spit out your application.js, and even automate it if you want to get fancy. I used this briefly, but decided it was a bit clunky, and became annoying to debug. Also, not all dual-environment npm modules like to be run through browserify.
Personally, I am currently opting for using RequireJS ( http://requirejs.org/ ) and manually managing my modules, similar to how Mozilla does with their BrowserQuest sample application ( https://github.com/mozilla/BrowserQuest ). Note that this comes with the challenge of having to potentially shim modules like backbone or underscore which removed support for AMD style module loaders. You can find an example of what is involved in shimming here: http://tbranyen.com/post/amdrequirejs-shim-plugin-for-loading-incompatible-javascript
Really it seems like it is going to hurt no matter what, which is why native module support is such a hot topic.
Our team maintains a tool called Lineman for building front-end projects. The tool is node-based, so a project relies on a lot of npm modules that operate server-side to build your assets, but out-of-the-box it expects to find your client-side dependencies in copied and committed to vendor/js.
However, a bunch of folks (myself included) have tried integrating with browserify, and we've run into a lot of complexity and problems, ranging from (a) npm modules being maintained by a third party which are either out of date or add unwanted changes, to (b) actual libraries that start failing when loaded traditionally whenever a top-level function named require is even defined, due to AMD/Require.js baggage.
My short-term recommendation is to hold off and stick with good ol' fashioned script concatenation until the dust settles. Until you have problems big enough or complex enough to warrant it, I suspect you'll spend more time debugging and remediating your build than you otherwise would. And I think most of us agree the best use of your time is focusing on your application code, not its build tools.
You might want to take a look at http://jspm.io/ which is a browser package manager. Has nice ES6 support too.
I personally use webmake for my small projects. It is an alternative to browserify in the way it brings npm dependencies into your browser, and it's apparently lighter.
I didn't have the opportunity to compare in details browserify and webmake, but I noticed webmake doesn't work well with modules internally using global variables such as socket.io (which is full of bloat anyway IMO).
I would be cautious about RequireJS, which has been recommended above. Because it is an AMD loader, your browser will load your JS files asynchronously. It will induces more exchanges between your client and server and may degrade the UX of people browsing from mobile networks / under bad WiFi. Moreover, if you succeed to keep your JS code simple and tiny, asynchronous loading is absolutely not needed !