Browserify great and all, and makes it really sweet (even compared to require.js), but the idea of bundling everything into one minified file although sounds great for final version of the app, feels like something I would like to avoid during development. Wouldn't it make difficult to debug stuff?
Is it possible to use browserify and still keep all javascript files and make it more transparent for the browser during development? And when you ready to ship it run browserify bundler and minify everything into one file?
Or maybe there's better approach - like keeping all scripts listed in a partial that gets included to the main page for development or something like that?
Upd: I just found that there's an option:
--debug -d Enable source maps that allow you to debug your files separately.
Is that helpful? I guess it is. But I suppose it still makes it difficult if want to use coffeescript source maps
Indeed you shouldn't use minified/concatenated Javascript in development. Luckly there are a myriad of ways of solving this particular issue, I recommend taking a look into an automated build process like Grunt.
Related
I started using react as my ui framework of choice. Upon my adventure through the documentation I noticed that when using the create-react-app script to spin up a new react boilerplate, they used .js file extension on scripts that where returning jsx code. When I asked my buddy he told me that you should use the .jsx extension on scripts that are returning this kind of code.
Im a bit lost here as if both works, wouldn't it just be better to go with the .js extension as at the end of the day its javascript we writing.
Please help me with what is considered best practise. (I kinda have a feeling it would be to use the .jsx extensions on these types of scripts, but I'd love to hear the community's view on this)
Thanks in advance :)
It's really up to personal preference.
My personal opinion is JavaScript is JavaScript, and I just use .js. Others will prefer to use .jsx in files that are JSX and .js in for things like utilities, in order to differentiate. The only important thing is to be consistent in whatever you choose (at least within one project).
In general, it doesn't matter.
The only time it might actually matter is based on your build pipeline. Some build pipelines may be configured to compile .js and .jsx with slightly different rules, but that would be based on your application (things like create-react-app don't care).
At the end of the day, you could use a .cookiemonster extension and it'd work just fine (as long as your build pipeline is configured to handle it).
Actually it doesn't matter, is up to you to decide I prefer to use .jsx when I return the mix between HTML and JS and use .js only when I'm using plain JS or ES6.
I recommend you to read about this on this issue on github.
What's the best way of including a node module on my webpage?
Should I use absolute paths like <script src="../../node_modules/bootstrap/dist/js/bootstrap.min.js"></script> or is there an easier and better way of doing it?
Thank you.
Add this in your app.js-file
app.use('/placeholder', express.static(__dirname + '/node_modules/'));
This allows you to write:
<script src="/placeholder/bootstrap/dist/js/bootstrap.min.js"></script>
And Node will redirect that path to the node_modules folder.
You can change placeholder to whatever you want, mine is named scripts
Node modules are designed for server-side execution in the NodeJS environment, not for use in a browser. So the best way to include them in a web page is not to.
I will note that Bootstrap is a client-side framework, so it makes no sense as a NodeJS module in the first place.
If you're looking for an npm-like tool for client-side packages, the flavor of the week is Bower.
My answer to this question would be a bit different and a little advance.
Maybe it won't be helpful to you right now, but definitely, in future, it will. Also, it would help out others.
Yes, the first answer is absolutely correct, you can add a placeholder and then add links relative to it in your index file.
Now, are you using a task runner like gulp or grunt? If not I would recommend you to start using it, because you can cut out a lot of manual work use these tools and eventually save a heck load of time.
You might be thinking why am I talking about gulp or grunt over here. I will answer this questing shortly.
Since you are using node.js, you already know how modules are loaded in Node.
eg : require('express');
What if we could use this approach for our client applications? You would only have to include one js file in your html and that js file would require all the other js libraries for you.
Great, suddenly you can reduce the number of script tags in your html page from approx around 20-30 to 1.
This is where module loaders come into picture.
But browsers do not understand the require statement.
To deal with this we use a tool called a browserify, we can use gulp(which I talked about earlier) to configure a task to browserify our files.
When you use this, you will have to require all your js libraries and your own js files into a single file (say: app.js). But as we said browsers do not understand require. This is where browserify will take this app.js file pre process it and spit out a single file that should be included into your html.
You can follow this article to get a clear picture on how to achieve this.
Scalable app using Gulp and browserify.
Pretty neat right! :)
Some of the other module loaders are System.js and webpack
I'm creating a little SPA framework (might be a full-feature framework).
Frontend is based on native javascript (including ES6 features and web-components).
Backend is written in Go.
Here is a list of my needs, that I'd like to do automatically:
Minify my javascript files
Transpile ES6 code to ES5 (with something like babel.js)
Polyfill my web-components
Is there a way to achieve this without using node.js? Are there already go packages that can make those 3 things happen, with a "simple" grunt/gulp-like way?
I would like to avoid installing node.js, npm, bower... etc.
In my (not very classified) oppinion, using those node.js tools makes my application a mess adding a lot of unnecessery overhead to my application folder and makes my framework dependant on a lot of stuff (that application programmer has to learn, understand and know how to use).
Thanks for any tips/oppinions.
If you're doing a SPA you should just stick with gulp and others. You'll probably end up using npm stuff like browserify, autoprefix, etc, and you'll basically end up reinventing the wheel with your own asset pipeline.
With that said I've seen a couple, but none of them looked very mature last time I looked:
https://github.com/jbowens/assets
https://github.com/shaoshing/train
and you're going to need npm installed to use them regardless.
I have a web project I'm working on and it is using LESS to combine all the files into one CSS for me. However I obviously don't want the client side javascript to have to run in production as that is going to slow things down.
Is there a way with the client-side less.js that it can export the .less files you give it to a single CSS file, which I could then call in my live environment?
You have a couple of options for this that I know of:
Use the LESS command line tool
If you're on a Mac, use LESS.app
Running a watch command isn't that big of a deal, it becomes second nature quite quickly :)
Since you want a non-command line option, I'd recommend LESS.app if you're running OS X. If not, try Simpless (cross-platform) or Crunch (Adobe Air-based).
PS. They're all free!
How can I (and what tools do I need to) create a makefile that:
Combine all JavaScripts '/js/*.js' (in a manual order - possibly with cat)
Verify that combined script works against unit tests (which using qUnit)
Minify JavaScripts
Verify that minified script works against same unit tests
I would like makefile to work on Mac OS command line.
I will be uploading the Makefile to a GitHub repository, so I would like something that other developers will be able to use easily.
Here is one complex script you could look for inspiration:
https://github.com/mobilizejs/mobilize.js/blob/master/release.py
(check also README)
Generally there are always project specific use cases and one solution does not fit every project, thus everyone is doing ad hoc scripts. Also, makefile is pretty limited in the end - I recommed to pick a real scripting tool.
Thanks for all the suggestions, here is the solution that I have decided to go with:
Makefiles - just as a shortcut really
Google V8 - to execute JavaScript from command-line
I can easily perform minification and unit testing using JavaScript.
I have made a few minor changes (added ability to write files) to the sample shell application that comes with V8 and compiled on OS X. I plan to somehow cross-compile for OS X and Windows in both 32bit and 64-bit. I will include binaries for V8 and custom application source in the GitHub repository. I will include instructions to obtain and compile V8 for those who want to customise or recompile.
V8 will be doing all of the work (essentially). Whilst I have yet to bring all of these things together, I believe that this should work.
The only downside is that DOM based unit testing cannot be automated. It might be possible to get the DOM stuff from the Chromium project, but this is probably going to be too time consuming. I'll leave that to an enthusiastic contributor (should anybody want to).