I am starting to build a website from scratch using python, django, and bootstrap. I have noticed that many times js, css, img. and fonts are stored in a folder vendor, such as:
/static/js/vendor/bootstrap/bootstrap.min.js
/static/css/vendor/bootstrap/bootstrap.min.css
or something similar.
What is the benefit of this folder structure over something like:
/static/bootstrap/js/bootstrap.min.js
/static/bootstrap/css/bootstrap.min.css
In the first example, when using the vendor folder as I have often seen, I would have to download bootstrap and unpack the downloaded folder into the js and css vendor sub-directories. In the second example, I can download bootstrap and drop the downloaded folder into /static without having to unpack anything.
It clearly marks which files are third-party libraries that should not be edited directly.
The vendor folder is where you usually (I'm using the word 'usually' because it's not exactly a rule but more of a preference in the coding community with the purpose of having a semantic directory structure) keep third-party resources(icons, images, codes, you name it) as opposed to a lib (library) folder where you or the author of the site/application to be specific keep your original codes in.
So if I were to download and use the site/application in the hypothetical scenario above, I can then create relevant folders for each data type (src/images for images, style/css for css, script/js for js, etc) and move required assets from the lib folder to the new folders without having to edit the third-party codes (or other assets) thus making it easier to rollback on any changes made that cause errors and such.
Related
I want to know if installing jquery/bootstrap/font-awesome can be done automatically, instead of installing it via npm and then manually dragging the code to my css/js/fonts folder?
Is there no program that can update and automatically drag them to the correct folder?
I know people are saying that you can just manually drag the javascript file to the correct location, but bootstrap for example consists of more than a single javascript file. It includes font and css files.
If I were to include them in this manner:
\web
-\css
--\app
---\main.css
--\font-awesome
---\font-awesome.min.css
-\fonts
etc.
Then it wouldn't work, because font-awesome expects it's fonts to be one folder aside.
JQuery, Bootstrap and Fontawesome are not softwares or applications that you install in a webpage. They are just CSS and Javascript files. So these are like any other javascript or CSS file you may have written from scratch for your webpage. Except that they are well maintained, highly optimized and made for a particular application. (Like Bootstrap primary purpose is to provide a framework for making webpages responsive.)
To include them to a webpage all you have to do is tell the HTML file to use those files. And this is done by linking them to the HTML using the <script> tag and its src* attribute. (*W3schools link. Hehe).
Now in src attribute you may provide a URL to a location on the web containing the file or you may provide a relative local path to a location in your server or local machine containing the file. Yes, you can manually drag the files into your css/js folder and just include the files using that path. No Im not aware of any softwares to automate the process. But you need only place the file in one location for an entire webpage and its sub pages to access it. So its not a very intensive process.
As for why CDN's host such files for public access, an insight is given here : How cloudfare provides free service. And security, well, they are pretty darn secure, it is literally their job to provide secure access to the files they host. And why people use CDN in the first place is because this (in short performance).
Update:
As for how to include files in your HTML, it goes like this (Bootstrap example) :
<link rel="stylesheet" href="static/bootstrap/css/bootstrap.min.css">
<script type="text/javascript" src="static/bootstrap/js/bootstrap.min.js"></script>
You need to provide the path to the required CSS and JS files. In the case of Bootstrap these two are the only ones you need to include to get full functionality of the library.
I think it is not a good idea to use local files instead of CDNs until you are not working offline.
Here you can read about CDNs vs Local Files:
https://halfelf.org/2015/cdn-vs-local/
Multiple files on CDN vs. one file locally
https://www.sitepoint.com/7-reasons-to-use-a-cdn/
Although there is one another link that is just opposite:
7 Reasons NOT to use a Content Delivery Network
Nevertheless if you want to use the files locally you can follow the instructions below:
Move at the cdn link in your project
Copy the link from src or href and open it in your browser.
Save the file locally and give the reference of the file in your project.
I have made a CMS with rails, users can upload js and css freely to customize the pages made by the CMS, I just generate a simple link to the assets according to what they are, and they have worked without any problems, how ever after updating the service to Rails5, there have been some troubles with the files uploaded in the public directory.
Mainly when people directly edit the css file in the public directory since they prefer to do that when running the CMS locally with there preferred editors when doing initial mocking.
The things known are,
The css or js does not update when locally edited (so changing body background to #000 or something doesn't show up)
directly accessing them in the browser seems to update them for subsequent accesses
assets are mostly generated by compass or webpack-dev-server since js is jsx and css is sass, but the problem reproduces even when directly editing css or js.
I know its a vague problem to ask, but I feel the asset pipeline may be interfering with files directly placed in the public directory somehow, its even more bizarre since it happens on some computers, and not on all of them.
In IIS and therefore VS, there are virtual directories which allow simplified, virtual, relative referencing in script tags. They are handy. In WebStorm you can get the same effect with Project Directories and then marking your project root as a Resource Root. If you do this, you also get coding assistance in the text editor.
WebStorm also has External Libraries, what is the point of these?
Is this for when you have a link to a CDN in your script tag and you want to get coding assistance? If you already have Project Directories, what is the point of External Libraries?
I've seen this answer and I kind of get the different modes of referencing/inclusion, but I don't get the big picture. What is the core reason for the External Libraries vs the Project Directories?
Is this for when you have a link to a CDN in your script tag and you want to get coding assistance?
Yes, this is the most common case - WebStorm can't use online resources for code assistance, it needs to have the corresponding javascript files available locally. So, if you don't like to pollute your project folder with all these library files, you can have them stored outside of your project and set up as libraries.
What is the core reason for the External Libraries vs the Project Directories?
See above - external libraries allow storing library files in an arbitrary location outside your project folder and still get code completion/highlighting/etc. Please also see the answer you refer to:
Note also that libraries are 'light-weight' as compared to .js files in your project - they are treated read-only, have the inspections turned off. Plus, you can assign documentation URLs to them, enabling external documentation for library code. So, even if you have your library files in your project, it might make sense to add them as libraries
see also this blog post
I've started using SailsJS for a small web app and so far it's great.
However I'm struggling with the assets and layout.
Basically I would like to be able to use different type of assets (groups of css files) depending on the page.
For this, I wrote 2 different layouts, each should includes the correct css files.
However, when I add those files in the config/assets.js files there all bundled together.
Is there a way to specifiy in my layout which assets i want to use ?
I know you can specify assets.js or assets.styles but I would like to be able to create my own group .
I also tried to put those assets in a different directory (public for example) and load them manually in my layout. It's still not working because the server doesn't want to 'serve' them.
Any idea ?
Glad you're liking Sails :)
For now, you can (a) bring in all styles all the time and make only the relevant ones apply (b) use another tool (like Grunt) to bundle assets like you would in a vanilla node.js project or (c) link the stylesheets manually (put them in your public folder).
As for the roadmap-- the community is working on more options for serving templates/styles/client-side logic. There's an open spec here:
https://github.com/balderdashy/sails/issues/240
Hope that helps!
I know this is old, but in case anyone else comes across this; in recent versions of sails the asset pipeline is built around grunt by default (I haven't used sails before 0.10.x).
You can add your own exports in tasks/pipeline.js and link those to the appropriate location in tasks/config/sails-linker.js. E.g. you could have a views/public folder and tell sails-linker to inject publicCSS vars there. Then adjust your layout.ejs so that it imports the styles/javascript from whichever folder.
Nowadays, we have tons of Javascript libraries per page in addition to the Javascript files we write ourselves. How do you manage them all? How do you minify them in an organized way?
Organization
All of my scripts are maintained in a directory structure that I follow whenever I work on a site. The directory structure normally goes something like this:
+--root
|--javascript
|--lib
|--prototype.js
|--scriptaculous
|--scriptaculous.js
|--effects.js
|--..
|--myOwnScript.js
|--myOwnScript2.js
If, on the off chance, that I'm working on a team uses an inordinate amount of scripts, then I'll normally create a custom directory in which we'll organize scripts by relationship. This doesn't happen terribly often, though.
Compression
Though there are a lot of different compressors and obfuscators out there, I always come back to YUI Compressor.
Inclusion
Unless a site is using some form of a master page, CMS, or something that dictates what can be included on a page beyond my control, I only included the scripts necessarily for the given page just for the small performance sake. If a page doesn't require any script, there will be no script inclusions on that page.
First of all, YUI Compressor.
Keeping them organized is up to you, but most groups that I've seen have just come up with a convention that makes sense for their application.
It's generally optimal to package up your files in such a way that you have a small handful of packages which can be included on any given page for optimal caching.
You also might consider dividing your javascript up into segments that are easy to share across the team.
Cal Henderson (of Flickr fame) wrote Serving JavaScript Fast a while back. It covers asset delivery, not organization, but it might answer some of your questions.
Here are the bullet points:
Yes, you ought to concatenate JavaScript files in production to minimize the number of HTTP requests.
BUT you might not want to concatenate into one giant file; you might want to break it into logical pieces and spread the transfer cost over several pages.
gzip compression is good, but you shouldn't serve gzipped assets to IE <= 6, so you might also want to minify/compress your JavaScript.
I'll add a few bullet points of my own:
You ought to come up with a solution that works for both development and production. In development mode, it should pull in extra JavaScript files on demand; in production it should bundle everything ahead of time. Switching from one behavior to the other should be as easy as setting a flag.
Rails 2.0 handles all this through an asset cache; other web app frameworks might offer similar solutions.
As another answer suggests, placing third-party libraries in a lib directory is a good start. You can also divide your own JS files into sub-directories if it makes sense. Ideally, you'll be able to arrange them in such a way that the files in a given sub-directory can be concatenated into one file.
I will have a folder for all javascript, and a sub folder of that for 3rd party/shared libraries, and sub folders for each component of the site to keep everything organized.
For example:
/
+--/javascript/
+-- lib/
+-- admin/
+-- compnent1/
+-- compnent2/
Then run everything through a minifier/obfuscator during the build process.
I'v been using this lately:
http://code.google.com/apis/ajaxlibs/
And then have a "jscripts" folder where I keep my custom code.
In my last project, we had three kinds of JS files, all of them inside a JS folder.
Library code. A bunch of functions used on most all of the pages, so they were put together in one or a few files.
Classes. These had their own files, organized in folders as needed, but not necessarily so.
Ad hoc JS. Code that was specific to that page. These were saved in files that had the same name as the JSP pages they were supposed to run in.
The biggest effort was in having most of the code on the first two kinds, having custom code only know what to call, and when.
This might be a different approach than what you're looking for, but I've been playing around with the idea of JavaScript templates in our blog engine. In a nutshell, you assign a Javascript template to a page id using the database and it will dynamically include and minify all the JavaScript files associated with that template and create a file in a server-side cache with the template id as a file name. When a page is loaded, it calls the template file which first checks if the file exists in the cache and loads it if it does. If it doesn't exist, it creates it on the fly and includes it. I also use the template file to gzip the conglomerate JavaScript file.
The template idea would work well for site-wide JavaScript (like a JavaScript library), but it doesn't cover page-specific JavaScript. However, you can still use the same approach for page specific JavaScript by including a second file that does the same as above.