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?
Related
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.
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 am sorry to ask this type of question.
but i am extremely confused here,i have gone through another sites to find the answer .
but not getting any proper answer .
Please explain me.
Thank you
I do find this answer from #Elisabeth Robson on CodeRanch pretty informative..
I think this is one of those questions which doesn't have a definitive answer and you're likely to get different answers from different people depending on what they think of as "lightweight".
Here's my answer: I think JavaScript can be thought of as lightweight because (at least up to ECMAScript 5) it isn't a particularly "big" language with many many constructs. It's actually a fairly simple language for the most part. Now, each new release of the language inevitably adds more "stuff" to it, which makes it less lightweight. Personally, I don't like that inevitable march towards more "stuff". I like when languages are lightweight: that makes the language easier to learn and understand.
A related way to think about whether a language is lightweight is: is the interpreter/compiler/execution environment for that language simple and fast? Which is really only possible if the language itself is simple. JavaScript engines have become a lot more complex in the past few years, but the tradeoff is that executing JavaScript code has become a LOT faster. I really have no idea how a JavaScript engine compares in complexity to, say, a Java compiler/runtime so I don't feel qualified to really comment on that end of it.
Another way to think of this is to consider the language "ecosystem": how many libraries and frameworks are built for it? While libraries and frameworks are useful, they can make a language feel less lightweight, because if using those libraries and frameworks becomes a necessary part of working with the language (your employer requires it, or your co-workers, or "everyone is using library X"), then again, it's more "stuff" to wrap your head around. In that sense, JavaScript becomes less lightweight by the day as more and more libraries and frameworks are released.
In conclusion, I'd say that I think the core JavaScript language is still fairly lightweight, but the JavaScript ecosystem is becoming a lot heavier by the day.
There are a few things this could refer to. Could be the fact javascript is fairly high level, weakly typed, or not very complex to write. Either way, it does seem to be a slightly subjective and vague term.
The fact is is high level simply means it has quite a few abstraction layers that differ it from machine code. C++, for example, is more low level, and getting something done in C++ takes more lines of code, but executes quicker.
Javascript is also weakly typed, meaning you do not need to specify data types, return types, etc. This is good and bad. It ends up making development quicker, but can cause more bugs that are not immediately recognised by the compiler. Also, it can remove reading clarity.
Finally, Javascript is arguably easier to write, and understand, then languages such as Java, C++, etc. It is has less methodologies to go about a given task.
Javascript is considered as light weight programming language .One of the reasons, is because it does not have any variable types unlike other languages. In javascript everything is considered to be as an object.
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
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 11 years ago.
Improve this question
I often see articles, posts and comments something like:
globals are bad in javascript
script tags should be at bottom of page
CSS should be in external files and at the top of page
scripts should be in external files, not plain script-tags.
etc.
I've looked up the HTML source of some big sites and have noticed that they have a lot of plain javascript and CSS inside HTML markup. JavaScript and HTML are note always obfuscated, and so on.
There are quite a few separate issues here.
What you see when you "view source" is not usually what they develop with. It's usually a compressed / optimised form generated from "source" code.
Claims about what is "best practice" are necessarily generic, and don't apply to all scenarios (especially if you're a big site and need specialised optimisation). These guidelines should be considered individually for each project.
Best practice, or even clean code, doesn't directly translate to return on investment. It may be nice to have consistent naming schemes, but is it worth the time developing and enforcing the scheme across 100s of developers?
Laziness, incompetence, or Friday nights.
Just because a site is big makes no guarantees about the quality of the code.
Have you ever viewed the source of Google's page? Is it pretty? No. Does it work? Yes!
Some possible reasons:
Some Web code simply isn't very big or complicated and it really makes no difference in maintainability whether it follows best practices or not, and it works fine the way it is.
Code is often written by inexperienced programmers, even on big, popular sites, and is never improved because it works fine the way it is.
Best practices change from time to time and it's seen as wasteful to spend time redoing your code just to adhere to the latest, when it works fine the way it is.
Adding new features is deemed more important than cleaning up old code, especially when, again, the old code works fine the way it is.
You may sense a recurring theme here. Rarely do programmers feel the need to fix what isn't broken.
Edit: If I were writing this now, more than two years later, I'd reword that final sentence to say "Rarely does management feel the need to fix what isn't broken." Most programmers love to revamp inelegant things, to the extent that they must sometimes be restrained by management in order to ship a product. I'd also throw in a mention of the concept of technical debt.
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