When is namespacing appropriate in JavaScript? [closed] - javascript

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
For a new page I'm working on, I want to make sure I do everything “right” to the best of my ability. I was wondering what the best practices were re. one JS file per page or one file containing everything. I found this question which helped some, but raised more questions.
I pretty much only use JS for three things:
transitioning things on button clicks (showing/hiding panels, etc.),
pre-validating forms, and
AJAX calls.
When I compare my use cases to the namespacing approach, it seems like overkill; I don't really understand why I would need to set up such a complex framework to work with JavaScript. This leaves me with two questions:
For what I'm doing, should I use one JS file per page, or use Irish's namespace technique and a single script import?
What the hell are people using JS for that requires so much structure?

If your pages don't have anything in common, you might use a script file for each page. If you've got a lot of logic common between your pages, you'd probably want to put those common bits into a file of its own and include it wherever you need it.
As for why so much structure is necessary, people are making more and more complex things with JavaScript. Consider Gmail, for example. I'd imagine there's quite a bit of code in there, and without much structure, it would become difficult to maintain quickly.

OK, That page is from 2009 - The way Javascript is used on the web has changed a lot since then.
Now that most web pages contain multiple third-party Javascript files from different sources (and different developers). It makes a lot of sense to encapsulate your code in a custom namespace to prevent your code being overridden by other code using the same variable names, and it isn't any harder than:
Mynamespace= {};
Mynamespace.foo = "bar";
Mynamespace.foobar = function(){
//function body
};
Writing structured Javascript isn't about adding complexity. Writing structured Javascript allows you to encapsulate behaviours and responsibilities into re-useable portions of code that are much easier to test, maintain, re-use and extend.
You don't even need to make the single-file/multiple files judgement. You can use a framework like require.js that compiles all of your separate code files into one single file for deployment.
JavaScript is now officially a first-class language in Visual Studio Its being used to write web-servers, templating systems and even 3d engines.
Welcome to 2013 ;-)
_Pez

Related

Execution time for Core JavaScript vs jQuery [closed]

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 5 years ago.
Improve this question
If my purpose is served by core JavaScript only, should I use jQuery?
I mean if I use those libraries, will the application become slower or remain same?
If anyone have any reference, can you please share with me?
Yes, Sure
Actually AngularJS is also use jQuery Dom selection code for angular.element.
Its called jqlite.
Also for most of CSS framework like bootstrap, foundation jQuery is also required because most of utility is still built with jQuery.
AngularJS is also very powerful but sometimes its dependent on jQuery.
So you can use both of it on a single page no worries.
TL;DR: It really depends on what you are planning to do.
For example: A simple static webpage may not need angular or even jQuery for that matter.
A web application on the other hand can really benefit from using libraries/frameworks such as Angular and React.
A good rule of thumb is to use only what you need, not bloat up your project with libraries and dependencies just because.
You can achieve really good page speeds with or without frameworks, a good start is googling around and see what you want to use.
Yes using jquery or angular means additional code that needs to be executed, and that means a measurable difference in execution time, although usually not a noticeable time difference.
But that's the wrong question to ask
I don't know what application you have in mind, and how experienced you are, so ...
both jquery and angular provide a lot of stuff which may speed up your development time tremendously.
can you write code that contains fewer bugs, memory leaks, attack-vectors, etc. than these frameworks, which have already been used/tested thousands of times in production?
Are you sure you can write code that is more performant than these libs? Especially from jquery I know, that there are some pretty ugly corners, but can you do it better? I don't know your skill level.
browser compatibility: how skilled are you on that topic?
and at last, why reinvent the wheel?
Oh, and about performance in web-pages. A few years ago there was a statistic going around about performance, with the general summary:
js usually uses only about 15% of the performance/runtime.
something around 60-80% of the runtime is used to render the page
if you want to "improve the performance" of your JS, don't micro-optimize stuff, but check where you trigger render-cycles that can be avoided.

Best practice to combine JS files [closed]

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 8 years ago.
Improve this question
I always have this questions in mind come to JS optimise, nowadays most people combine all their CSSs into single file by using Less, Sass or others methods. but come to JS i am a bit hesitate on the approach, cause there are plug-in, frameworks and your own code. Just wondering is there a rule or best practice to approach.
so should i combine all my JSs into single JS include plug-in, frameworks, libary and my own code into one or keep them modularized accordingly.
I know it may depend on the size of the project, but what's the measurement and when I should combine all into one or modularize. Is there any rules I should be followed.
Any suggestion are appreciated.
It's generally a good idea to combine and minify your own development JavaScript. Having multiple HTTP requests can slow down load times if there are too many requests (especially if there are multiple small files). Google PageSpeed Insights gives some guidelines on how to do it here.
As #veroxii says, most people end up using a "build" since minifying and combining everything manually would be a huge waste of time. For small sites that I work on that don't really have a built in minification system, I like to use gulpjs along with gulp-uglify and gulp-concat to minify and combine javascript resources.
You have to be careful when combining though because often times, scripts will depend on other scripts. Say you have two scripts that you combined where scriptB depends on scriptA. If the browser loads and runs scriptB before scriptA because it came first in the combined file, then bad things will happen. Either be careful with your script combination or use something like requirejs.
You can't really do much in terms of minification or combination when using a third party script loaded in from a CDN (like jQuery) except use the production script.min.js resource that they provide. You could potentially download their script and throw it into your minification process, but most users are more likely to already have the CDN version cached by their browser.
The biggest thing when it comes to JavaScript is making sure the loading of the scripts don't block the rendering of the page. Most JavaScript is useless without content, so why not let the content load first and then load in the script? Users will see the content first and then interact so it's probably a good idea to load those resources in that order. More on that here. Either put your script tags at the bottom of the page, use the asyncattribute, or use an asynchronous javascript loader like loadJS or requirejs.
Which framework are you using on the server side? Most of the frameworks out there come with an "asset pipeline" already built in or as a plugin.
For instance django has https://django-pipeline.readthedocs.org/en/latest/ and grails has http://grails.org/plugin/asset-pipeline
This does everything you asked about and more. I'm sure there's something similar for whatever you're using on the serving back-end.
Edit: to clarify - I don't think this is something people do manually. They have a tool which does it on the fly or at build/deploy time.

Determining when to create a new JavaScript file (organizing source code) [closed]

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 9 years ago.
Improve this question
I'm about to set out on a large map application project that is going to be around 5,000 lines of JavaScript in total.
My normal way of going about a project like this would be to create a single file called 'main.js' and then include everything all in that one file. I think it's about time I broke out of this habbit and started to store the JavaScript files more sensibly by splitting up components into more JavaScript files. Is this a good idea? I want the project to be more organized.
My question is, what's the best practice for doing this? When should I say "Hmm, this should probably go in its own file". Is there a general rule of thumb I should stick to when deciding to put code in a new file?
Yes, you should break your code up into separate files. There are lots and lots of different ways to decide what should go in a given file - it all depends upon what your code is and how you think it can be best organized. Here are some of the possible ways you can organize things:
Code in reusable objects where similar objects are combined into a module and a small module is contained in one file. Then each file is a module.
Group a set of objects and functions related to one particular type of functionality in one file. For example if you have a set of functions that help you do animation, then you might group all those together in one file.
If you have a set of utility functions that are reusable across a number of different applications, group those together in one or more files so they can be more easily used in multiple projects without reorganizing them.
When considering reusability, put the smallest chunks that you may want to reuse into their own files so you can include only what is desired in your future projects. Also make sure any dependent functions, utilities, etc... are also separately includeable in their own files. The idea is that in a future project you should just be able to include existing files without reorganizing the code and without having to include a bunch of stuff that you don't need.
Put code that is specific to this particular application and/or this specific user interface into it's own files so it is separate from other parts that you may be more likely to want to reuse in other applications.
Also keep in mind that the most efficient deployment strategy is to recombine most of your separate files into a single, larger file that is minimized as this is more efficient for a browser to download and cache and improves the performance of your web site. This recombination of files should be an automatated build step that concatenates files together before minimizing the combined result. It isn't something you do with your editor as you should keep your files separate in your source control system.
Yes, do separate your project into files. I'd use the same guidelines you've probably used with other programming languages. Good programming techniques are more or less universal. It doesn't matter what language you're using.
Try to break your project up into reusable objects. Keep each object focused on a defined task. That way you'll have a library of objects you can use in future projects.
Pick up a copy of "JavaScript: The Good Parts" by Douglas Crockford

Rewriting a plain javascript code into a code that uses jQuery [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have a plain javascript code that does not rely on external library. But given the popularity of jQuery and the fact that jQuery has become a de facto standard, I am wondering if it makes sense to rewrite the whole code for the sake of maintenance and extension in the future. Does it make sense to do so even if there is no particular problem with my plain javascript code at the moment?
Depends on the size of the codebase. If it's a very large job then 'if it ain't broke, don't fix it' applies. If it's quite small then it may help keep things more consistent.
There's no harm in itself however in mixing jquery and standard javascript, so anything new can be just written using jquery.
I would do it only if i can take advantage of jQuery to make my code smaller and easier to maintain.
jQuery is simply functions written in vanilla JavaScript so we don't have to write them ourselves.
I don't think there is an easy answer for this one.
My thoughts: It depends. Jquery may help you develop new functionality more rapidly so maybe it would be good to use for future functions. If your application is big it may cause instability if you rewrite large parts of it at one time. Maybe you find some parts that would especially benefit from being written in jquery and refactor these pieces one by one over time? Since javascript is the foundation of Jquery javascript will be there even if Jquery goes out of fashion so it can't be that bad to keep. Your main focus should be with the users; To keep them interested in you application and deliver new features that will keep them using your application. Very few users will care or even notice if you introduce a new library or not, but if your application breaks they will know. (It may however be very satisfying to introduce a library into your application that makes the code look good and easier to maintain).
Sidenote: These days I wonder if anyone knows what language / library they will be useing next year?

Is it possible to use muliple AJAX libraries on one page? [closed]

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 7 years ago.
Improve this question
I am just curious. There are many ready-to-use AJAX libraries out there like Mootools, Scriptaculuos, Prototype, YUI etc
My question is, is it possible to combine them? If I download all the code and put them on the same page, will it cause errors?
Which open source AJAX library would you recommend for a beginner?
If you're using Java on the back end, the ZK framework claims to provide full AJAX capabilities, i.e. no need to mix and match a bunch of different libraries. From the testing I've done so far, they seem to be right.
Of course, but like anytime you combine frameworks, you'll find you sometimes have to write your own glue code. For a beginner, it may be simpler to use just one.
It depends on the choice of frameworks you use. If they try to define the same variables then one is going to overwrite parts of the other. jQuery avoids this by defining the aliasing the core function so it has two names and YUI avoids it by not having a blasted dollar function in the first place.
Libraries tend to be relatively large, so you should probably avoid using multiple ones on grounds of bloat rather then anything else.
It is rare that using two different libraries is useful - the main reason for it is wanting to use multiple third party modules that depend on different libraries. In that circumstance, I would try to find alternatives that use the chosen library.
What opensource ajax code you using?
YUI usually. It is robust, well tested, well documented and powerful - although the initial part of learning curve is a little steeper then some of the others.
It does it a disservice to call it "ajax code" though - Ajax is a very small part of any of these libraries.
What would you recommend to ajax
beginner?
YUI.
What ajax features that can impress people?
That depends on who the people are. A lot of people will be impressed by being able to quickly produce slidey, fading, spinning animation effects ... but they aren't all that useful. A good event handling system doesn't do anything that will impress a lay person, but it will make like a lot easier for the programmer.
I recommend you to use the jQuery framework, because in my opinion has one of the best and easiest to understand implementation of AJAX.
An example:
jQuery.post('thescript.php', parametersInJson, function(response){
alert('The server response: '+response);
});
yes you can but you might run into some trouble (you might need to override the $ function...)
and i do recommend jQuery

Categories

Resources