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.
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 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
we are currently evaluating the use of AngularJS in a Enterprise Application (e-Banking) as a Single Page Application.
Many of the devs#work are already convinced that there no other way to go. It is the trend, it is future proof (html, css and js) it is easy to do, less burden on the server etc etc.
Despite the interesting part of this framework, i am not convinced that there are factors that must be considered before going this road. These can be:
Maintainability of code
Testability of code, not only the ui part
Continuous integration (like TeamCity or TFS)
Developer friendliness like debugging, navigating through code
Security (if there is a risk)
Has anyone any experience on enterprise apps build like that? I would rather go with Asp.Net MVC4. Please no hypothetical answers, i don't want to start a war. Real life experience is really appreciated.
Regards
I had thought about this when incorporating Angular into our enterprise application. First, some optional background information. I really needed to keep all my page state on the client side since recreating it on the server side is a very resource intensive task. I started off with building it with just JQuery, since I only needed a few things, but soon I found myself having trouble keeping track of the callbacks I wrote just last week. Hence, I wanted to refactor. While I was at it, Angular looked like the best fit for my programming style.
To address your concerns:
I think that it is more maintainable, since it encourages you to split things up. This, however, depends totally on your team and your discipline to keep things maintainable.
The Angular team definitely thought about testing when they were making it. Things are very easy to test, from unit testing to e2e testing. Others have even found a middle ground in between.
We use Jenkins at our Microsoft shop for continuous integration since it was easier for us to plug in our own programs to make it work with our complex environment setups. However, I don't think this relates much to which framework you decide to go with.
Coming from Visual Studio, I find JavaScript in general leaves something to be desired. I love edit and continue, unwinding the stack, and dragging that yellow arrow around. That stuff is just pure magical bliss. Debugging on the browser just doesn't give you all of that.
Security is pretty good. Looking through the docs, you can see that the team is concerned with security issues such as XSS and CSRF attacks. However, anything done over the browser is hard to secure. There are new attacks and bugs discovered every other day. If you are really concerned about security, you wouldn't have an online app. You would make sure that your customers only banked in the branch with multiple forms of ID. With that said, I don't think Angular is any less secure than any other JavaScript solution.
I would like to raise another issue with all of these JavaScript frameworks/libraries. They're all fairly new and constantly evolving. Look at how many functions JQuery has deprecated recently, and you'll get a sense of how hard it is to keep on top of your libraries. Many of these are also forgotten and left to rot. Angular being one of Google's products also makes me a little scared, since they have been cancelling waves of their projects. Hopefully, Angular does not become one of those.
The documentation is also lacking. Although the community is good, the documentation is not. Many pages are half done. Again, compared to the latest stuff from Microsoft, the documentation is pretty sparse.
This being one of the new things, it is harder to hire someone to help/take over this stuff.
Despite all these drawbacks, I really like it, and I'm definitely going to push my company towards adopting it.
Yes I have used Angular with Asp.net WebAPI along with MongoDB .Pls find my findings
1)Testability is absolutely fantatic .You can easily test you unit test using karma and jasmine
2) CI. Integration of Jenkins is available with Karma
3) Easy to debug similar to Javascript debugging can use chrome extension Bartrang to debug angular apps easily
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 9 years ago.
Improve this question
The benefits of well-factored and modular code, in my understanding are re-usability and organization. Code written in a big chunk all in one file is difficult to read, and re-using small portions of the code requires careful copy-pasting, rather than include statements.
In particular, with regards to Javascript, I came across an example recently that got me thinking about this. A comment was made on SO to the effect that, if you are not including your javascripts conditionally on a page-by-page basis, this "represents a failure to modularize JS code properly". However, from a code re-use and organization point of view, there is no reason to consider what happens at page load time. The code will be just as readable if it is written in a bunch of separate files and then mashed together and minified before being served. The rails asset pipeline, for example, does just this.
When I first encountered the asset pipeline, my mind reeled and I started wondering "how do I make javascripts load only when needed?" I read a few SO questions and an article on the matter, and began to think that maybe I shouldn't worry about what happens to my code after it "compiles".
Is the purpose of writing modular code purely a human-level activity, should we stop worrying about modularity after the code starts running? In the case of Javascript, should we be concerned that our scripts are being mashed together before being included?
I think the one thing that you are not really talking about in this with regards to performance is actual HTML browser download behavior. I believe you have to walk a fine line between only displaying the javascript needed on a page by page basis and leveraging browser caching and download behavior.
For example, say you have 20 different javascript snippets that are going to be used on every page. In this case it is a no-brainer to compile/minify them into a single file, as the fewer files your browser needs to download, the better. This single file would also be able to be cached, that is assuming it is a static file or appearing to be static (via headers sent) if it is dynamically compiled.
Now say of those 20 snippets, 15 are used on every page and the others are used intermittently. Of course you put all 15 of the always used snippets into a single file. But what about the others? In my opinion you need to consider the size and frequency of use of the files. If they are small and used relatively frequently, I might consider putting them into the main file, with the thought that the extra size in the main file is outweighed by the need to have additional request to download the content later. If the code is large, I would tend to only use it where necessary. Of course once it is used, it should remain in cache.
This approach might best be suited for a web application where users are expect to typically have multiple page loads per session. Of course if you are designing an advertising landing pages or seomthing where the user only may see that single page, you might lean on keeping the initial javasciprt download as small as possible and only loading new javascript in as necessary based on user interaction.
Every aspect of this question boils down to "it depends".
Are you writing an enterprise-level application, which results in 80,000 lines of code, when you stuff it all together?
If so, then yes, compilation time is going to be huge, and if you stuff that in the <head> of your document, people are going to feel the wait time.
Even if it's already cached, compile time alone will be palpable.
Are you writing dozens of widgets which might never be seen by an end-user?
Especially on mobile?
If so, then you might want to save them the download/compile time, and instead load your core functionality, and then load extra functionality on-demand, as more studies are showing that the non-technical end-user expects their mobile-internet experience to be similar to their desktop experience, not only in terms of content, but in general wait-times.
Fewer and fewer people are willing to accept 5s-8s for a mobile experience (or a desktop experience on mobile) to get to the point of interactivity, just based on the "well, it's mobile, so it'll take longer" train of thought.
So again, if you've got an 80,000 line application, or a 300kB JS file, or are doing a whole lot of XML parsing, et cetera, prior to load, without offering a separate mobile experience, your stats on mobile are bound to hurt -- especially if you're a media site or a commercial/retail site.
So the correct answer to your question is to say that there is no correct answer to your question, excepting that there are good ideas and bad ideas, based on the target-devices, the intent of the site/application, the demographic, the code-base, the anticipation that users will frequent the site (and thus benefit from cached assets), the frequency of updates to the codebase (having one updated module, with 20 cached modules, versus a fully-invalid 21-module chunk, due to one updated line, with a client-base of 250,000 customers, is a consideration for several reasons)...
...and more...
Figure out what you're doing.
Figure out what you need to do to make that happen.
Figure out how to do it, while providing your customers a good experience.
Know how to combine files.
Know how to load on demand.
Know how to build a light bootstrap, which can intelligently load modules (and/or learn require/AMD).
Use these as tools to offer your users the best experience possible, given what you're trying to accomplish.
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?