Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I have some questions about Javascript.
Most of my website's pages use js. For better performance, what should i do ? :
Write all of my js code in one file and link it with my pages ? Or one js file per page ?
Is it a bad manner that i never mix js into my html ? I like to have separate things (html, css, js)
Thank you.
For maintainability
Keep separate pages while developing the app, so that any one can make out which feature has been coded where.
For performance
Before deploying it for production, minify your js and css files so that there are less network calls to download those files.
Is it a bad manner that i never mix js into my html ?
No, having non-intrusive js is both good for readability and it is good for performance too since it gives you a chance to minify the js files. You can't minify inline js.
My experience is writing a relatively big website in ASP.MVC .
I did not write all the javascript code in one file because that would have been difficult to manage. I made a folder that included multiple javascript files, each having its own purpose.
If the javascript is more than say 10 lines of code, and you can put it outside the html file, i would advise so, because it is faster to look at .
It is easier to just have one .js file for all pages, but it is better for readability if you have multiple files.
Mixing javascript into HTML can be useful but it depends on your needs.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
I am writing html for a web portal for my boss and using css (of course) for overall formatting.
First, he told me NOT to use css but to use html includes. My understanding is that html includes are used for html repeated across multiple pages, not for formatting. Also, in my understanding, html includes ALWAYS require js to insert them. Am I wrong? I would be happy to be wrong. I have a day of coding and markup ahead of me, I would like to start it making sense.
There is no such thing as an "HTML include".
There was a proposal for HTML imports but it is dead in the water.
You've tagged this ssi which is a server-side include (which is a standard include mechanism that some HTTP servers support; Apache HTTPD documents it).
Other mechanisms for including HTML include preprocessors like static site generators, templates and include mechanisms provided via server-side programming, and client-side mechanisms involving JavaScript.
The closest HTML itself has to an include is the iframe which lets you embed entire HTML document in a scrolling box in the page. (You can achieve similar effects with object and embed but I'm yet to hear a good reason to prefer them to iframe).
CSS is the correct tool for presentation, but sometimes you need some common HTML scaffolding to apply the CSS to, and sometimes you want to have a single place to include all your presentation meta data (e.g. <link> elements) that gets shared between pages.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm writing a web tool using C#, HTML and JavaScript code based on the MVC pattern and I was wondering if it is smart (page load time, traffic, etc.) to load all needed scripts in the _Layout.cshtml.
Is there a difference in bundling all scripts together and load them in the head section of the _Layout.cshtml or load them in the actual views when needed?
Is there a best practice for this matter?
The best strategy is to "load what you really need". You should bundle all shared scripts and styles on one side and load that on the layout, and then create separate bundles for each view to load only what will be used on that particular page.
The difference would be that you will require more bundling configuration (as you would have one bundle per view), but IMHO, you will gain a lot more in a better code organization and avoid downloading unnecessary files.
Of course this all depends of what kind of application you are developing. But if you have all in one bundle and the project gets larger, it will be very difficult to later change the strategy as you will need to review all the dependencies on each view.
In terms of page load/traffic, it is clear that this strategy is better as the client will download only the files which are needed.
you can load script bundles in a view like this
#section scripts {
#Scripts.Render("~/bundles/movie")
}
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I'm looking for simple bullet point answers please. I've tried looking all over, Googling, other questions here but I can never find both advantages and disadvantages for each method.
This is the answer I got from W3Schools pertaining to external javascript files
Pros
It allows separation of concerns - which is not a big deal in simple pages but as the script grows larger you can have a monolithic html page. Big files in general are not ideal for maintainability
It allows caching - when the browser loads a script externally (whether it's be from your site or a cdn) it caches the file for future use. That's why cdn's are preferred for commonly used scripts. Makes the browser use a cached script instead of building a new one every time the page loads which makes the page load faster
More readable code - this ties into the first bullet point but nevertheless it is important. The smaller the files we humans are working with the better. It is easier to catch mistakes and much easier to pass of the torch to the next developer working on the project or learning from it.
Cons
The browser has to make an http request to get the code
There may be other browser specific reasons as well, but I believe the main reason is the separation of code into different components.
Probably the best advantage of using external javascript files is browser caching - which gives you a good performance boost.
Imagine you have a site that uses MyJsFile.js (a random 50kb javascript file that adds functionality to your websire).
You can:
embed it in every page, and add the 50kb to every page request (not ideal)
link it in every page (<script src="MyJsFile.js"></script>)
The second option is usually prefered because most modern browsers will only get the file once, and serve it from the browser cache instead of downloading it at every request.
Check out similar questions:
Why not embed styles/scripts in HTML instead of linking?
When should I use Inline vs. External Javascript?
Is it better to put the JS code on the html file or in an external file?
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm starting on Javascript and learning best practices, but I haven't found anywhere saying which is better:
1) Separate scripts:
<script>
// script A here
</script>
<script>
// script B here
</script>
2) Putting scripts together
<script>
// script A here
// script B here
</script>
Neither. Since scripts are usually shared between pages, it's better to keep them separate from your HTML:
<script type="text/javascript" src="urlOfScriptA.js"></script>
<script type="text/javascript" src="urlOfScriptB.js"></script>
If you cancombine them, you save a request, so it's even better:
<script type="text/javascript" src="urlOfCombinedScript.js"></script>
But for development it can be handy to have separate files. You can use tools to combine and minify your scripts. That way, not only are they combined into one script (resulting in less requests), but also they are compressed as much as possible, saving bandwidth and loading time.
For now, I wouldn't worry about that yet. Keep the files separate if you think that is easier to work with. And then, later, you can find a tool that can combine and minify them for you. Since this is a slow process, you shouldn't do that on the fly, and it's inconvenient to do it in a development environment, so only combine and minify them when you publish the site.
Organisation.
Do the scripts do stuff directly related to each other?
If yes: Merge.
If no: Keep separate.
(Although ideally they should be in external .js files according to the same rules of separation, then merged by a compiler/minifier before being served)
It's best practice to put your Javascript on the server as a single file (to prevent files loading in the wrong order).
You can still work in individual files, but use some concatination / minimization software to compile it.
There are lots of different ways to achieve this, but it generally depends on your working environment.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Has anyone here used KSS?
KSS is an AJAX framework.
KSS has both a client-side Javascript library and server-side support.
The client-side Javascript library needs to be included in your page. It fetches Kinetic style sheets from the server, parses them and binds a set of action to browser events and/or page elements. It is clean Javascript code that can peacefully coexist with other clean Javascript librarys(sic) like JQuery or ExtJS. It is about 100k in production mode. You can integrate your own Javascript code by using its extension mechanism through plugins.
I'm currently working on a project that uses it. Are there any drawbacks and gotchas to be aware of?
What's its cross browser support like?
At first as was really put off by the fact that you don't write the JS by hand, and actually translates a CSS-like file to JS behavior, but seeing in action, I've got to say that it really works quite well. But I haven't done any cross browser tests yet.
Some things that I've found:
it sends HTML from the server, instead of XML and/or JSON and replacing them clientside, meaning higher messages (understandable)
it has problems with scripts that add iframes dynamically on a KSS widget that you reload
some things are hard to debug, while others are made easy thanks to KSS' integration with Firebug