As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I've been doing HTML layout as well as programming for many years and I'm seeing a growing issue recently. Folks who primarily do HTML layout are becoming increasingly more comfortable using JavaScript to solve basic page layout problems. Rather than consider what HTML is capable of doing (to hit their target browsers), they're slapping on bloated JS frameworks that "fix" fairly basic problems.
Let's get this out of the way right here: I find this practice annoying and often inconsiderate of those with special accessibility needs.
Unfortunately, when you try to tell these folks that what they're doing isn't semantic, ideal, or possibly even a good idea, they always counter with the same old arguments: "JavaScript has a market saturation of 98%, we don't care about the other 2%." or "Who doesn't have JavaScript enabled these days?" or simply "We don't care about those users." I find that remarkably short-sighted.
I would like the opinion of the community at large. What do you think, am I holding too fast to a dying ideal? Is JavaScript's prevalence a good excuse to use a programmatic language to do basic layout, thus mucking up your behavior and layout? jQuery and similar "behavior" based frameworks are blurring the lines, especially for those who don't realize the difference.
Most importantly, I would like some "argument ammo" to use against these folks when the "it's the right way to do it" argument is unacceptable. Can you cite sources outlining your stance, please?
Thanks everybody, please be civil :)
I consider myself also "old-school" and intend to use javascript in a way that increases user experience, but it is not necessary. So for example (not layout, just easier to understand) i would alert you with js if you haven't filled a required field in the form, but if you have js turned off I'd still "catch" you on the server side.
And yes, wherever I can I try to use static html+css. A good example is: many people use jquery animations, but in some circumstances it is easier / faster / smoother to use css transitions.
I agree with you, but because of the 2% but because of the inconsistent page load. As soon as you use client side functions to change the layout you have a short delay between the fully loaded page and the whole functionality. I usually try to do as much as possible with html/css.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I started using Javascript for HTML5 mobile development but noticed I can use the jQuery library as well. My question is, does jQuery do anything besides require you to write less code? Is Javascript faster in performance? Sorry for the newbie question but I couldn't find an answer and really interested in the difference. Thanks in advance
jQuery is a library built in JavaScript. The more you abstract the less performance you'll get. For example, just selecting an element with the native DOM methods is going to be way faster than doing the same with jQuery.
So the question is not quite "find out which one is faster", you already know jQuery is going to be slower. The question is more like "is the performance hit worth it?". And yes, most of the time it is because the time you save in writing code is much more valuable than the performance hit you get, which most of time is simply negligible.
Another factor is the quality of your vanilla JavaScript code. jQuery has been tested and maintained for years, and it shows.
Your question should not be "should I use jQuery or plain JavaScript" but rather "which library should I use?". No one should be starting a substantial project with zero code, they should have at least a good collection of robust, tested code that can easily be collated into a library or tool kit.
The problem with a general library is that it must provide general solutions, hence why jQuery has 4,000 lines of code that any one project might only really need a few hundred lines of. Some libraries have very many more lines of code. If you use someone else's library, you are often bound to their update schedule and may well end up using plugins that require different versions of the library.
If you have your own library, or one developed and maintained in your work area, you get the same reuse of code and can cut your cloth to suit the project. jQuery (and most general libraries) are monolithic: it's all or nothing, you can't include just one part or another (e.g. you might just want a good addListener function). Your own library can be modular, so you only include the code you need and can avoid many of the cross–browser issues that general libraries must deal with. David Mark's "MyLibrary" is one of the very few modular libraries.
Also, cross–browser differences are becoming less and less of an issue and the DOM API is becoming richer so there is less and less need to use a general library. E.g. no one accounts for document.all anymore, or bothers with browsers that don't support either addEventListener or attachEvent. Once support for IE 6 and 7 can be dropped (a few years yet) there will be very little reason to use a monolithic third party library, modularity will be the key. Everything will be a plugin, there will be no need for a base library, or the base library will be very small to provide a generic API for basic DOM functions.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I've always been dabbling in javascript, but never really got hugely into writing a lot of javascript until last year or so. One thing I noticed is that my javascript started to grow so complex, that parts of it were more complex than the server's application code (minus all the framework code of course, such as Spring or Hibernate).
This caused me to realize that if you want to write a complex javascript application, in the same way you've been writing complex web applications on the server, you have to start thinking about best practices, architecture, how you structure your files, how you test your code, what abstractions do you use to create smaller, more reusable components, what is the best way to pass parameters and send messages, should i pass parameters or object literals, and just best practices all around. None of this provided or encouraged by Javascript itself, and everyone seems to have its own way of going about everything.
And of course, because Javascript offers such very poor api out of the box, I often spend a countless amount of time researching what the best tools for the job are. Facilities like importing files and dependencies, or even a basic collection library, are things NOT handled by the language. Let's not forget that IDE support, even in something like Idea 10.5, is actually pretty bad and nowhere near as rich as say Java due to its dynamic nature and the lack of these hard-bindings for packages and imports.
Outside of jquery, which I really like and feel comfortable with, I still haven't made any decisions as to the "right" way to do things either. This is odd to me.
Everyone seems to have their own coding idioms too - they either write in a pure functional style, or they try and create a whole classical programming model and then use that. People's coding standards and idioms vary from library to library and person to person. All of this makes knowing what the "right" thing to do an incredible task.
Even worse, there doesn't seem to be books on this sort of thing. It's like nobody has bothered to tackle it - which is totally contrary to what we have in the Java space, or many other spaces for that matter.
What is the right/successful path to having a refined way to successfully write nice-looking and robust javascript for complex web applications?
I feel like my knowledge of Javascript expanded and became more complete after reading Douglas Crockford's Javascript: The Good Parts. He really clarifies the most difficult and important parts of the language.
Reading it made clear the different types of inheritance: neoclassical, functional, prototypal. And the different ways to invoke a function: constructor invocation, apply invocation, function invocation, and method invocation.
I would start there.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have been looking for a good Java web framework and found Tapestry, which looks quite nice from an application architecture point of view. Another possibility is ASP and .NET, though I'm reluctant to use them since Java is the programming language most of the company's developer are used to. The reason why ASP is considered is due to its rich set of powerful UI widgets (http://demos.devexpress.com/ASPxGridViewDemos/GridEditing/EditModes.aspx for instance). Is there anything similar for Tapestry? What I am particularly interested in is tables (sorting, filtering, moving columns, hiding columns, etc.) and possibly others. Alternatively, is there a sophisticated Javascript library which can be easily integrated in Tapestry?
At my current job we use Tapestry 4, and we chose to use ExtJS widgets when we need a fancier UI component what Tapestry provides. Their grid widgets are exceptional. ExtJS isn't free for commercial apps, but the abundance of great widgets and documentation makes it really easy to work with, and it integrates pretty easily into Tapestry.
Another option would be to use Java Server Faces, which has several high quality component/widget libraries.
A big library of UI components is a good things. On the other hand there may be no such a set of predefined components that will suite everybody or suite anybody in an ultimate way. The alternative to relying on predefined components (which besides all may require an unexpected time to be learned) is to use a technology with which writing your own components would be an easy pleasure unlike what we see in almost every major Java Web Framework. The approach was implemented in HybridJava which in fact pushed it to the limits with zero predefined components. Yet it may be the most powerful for a task like you've describe.
Tapestry already offers a powerful Grid component.
This component covers all the features you are looking for.
Have a look at jumpstart to see how to sort,move columns, and hiding columns.
if you prefer the jQuery way perhaps you will have to check "Tapestry5-jquery" that proposes some components that make it possible to use jQuery plugins. The demo site only show the default grid component because it's implementation is still the best one.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
The basic idea for writing good code is that the code must be readable, well-commented and documented.
Other basic facts for writing good code regarding all the program languages are structuring the code in directories and files and indentation of course.
In the case of javascript the things could be more complicated,
because the language allows you to use different style to accomplish similar task.
For example there are three different ways to define a JavaScript class.
Said that, which are the best resource (books/sites) or suggestion for writing good code (library) in javascript?
I'd highly recommend reading JavaScript: The Good Parts by Douglas Crockford to get you started on writing quality JavaScript code.
If you're working for a company, is there a standards manual, or something jotted up saying "this is how we want things to be coded"? Yes, it's kinda Dictatorial, but it helps keep things "neat". ---Now, if you do not have one at your company, be proactive, talk to a few higher ups if they think it'd be useful, tactfully get them to delegate it to yourself and then make it. Get some brownie points and a good thing for your resume ---
There's ton's of books on the subject, blogs, pod casts, and probably a radio station somewhere.... that all talk about this subject.
But the #1 thing you will get from people is: Do not put many operations on the same line!
How many times do you look at a script and see a kerfuffle of statements/commands/initiators/setters/getters on one line. Or 4 nested ternary statements.
Sure, it "looks" cool if you're 15, but it is counter productive, not intuitive and not helpful. (yes this is a sour point). Code/Script is supposed to be maintainable. The biggest cost to some companies is maintenance on a product. When you go back to something years/months/days/hours after something is written, you want to be able to understand it without having to tape your eye lids open.
Here's a couple good articles I've read about this. They're not the most up-to-date but the information in them is still strong.
http://amix.dk/blog/post/19496
http://www.codinghorror.com/blog/2008/08/secrets-of-the-javascript-ninjas.html (yes from SO's very own Jeff)
http://www.bobbyvandersluis.com/articles/javascript_good_practices/index.html
Javascript - The Definitive Guide by David Flanagan (O'Reilly)
Pro Javascript Techniques by John Resig (APress)
http://jquery.com/
http://www.crockford.com/
http://developer.yahoo.com/yui/
This list will probably get fairly long, but don't forget you can study most of the code that is out there & you will soon learn what is good and bad - that's one big, great resource.
At the first place i would suggest you to get more familiar with JS object model
I would suggest you to take Douglas Crockford's article on prototypal inheritance:
http://javascript.crockford.com/prototypal.html
and make comparison with classical inheritance model
http://javascript.crockford.com/inheritance.html
More systematic approach of pros and cons of JavaScript can be found in his book
JavaScript: The Good Parts
http://www.amazon.com/JavaScript-Good-Parts-Douglas-Crockford/dp/0596517742
If you search for more broader architectural approach
JQuery, ExtJs (a.k.a. Sencha), MooTools are great java script libraries/frameworks to start looking at their design principles.
I would start with JSLint
I would recommend coffee script as a good tool to help write good javascript. It is very readable, and includes some very clever improvements to vanilla javascript, including a very well thought out class declaration system (not trivial in javascript, which is prototype based rather than class based in it's language definition).
For comments, I would recommend JSDoc, which is a javascript version of JavaDoc. I find it to be very easy to maintain comments in the code, and the output is in a standard format that many editors/tools are able to utalise - so not only for people to read. Google have also provided a good set of guidelines of how best to write comments using JSDoc in a standardised manner.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I noticed most questions related to client-side script on SO are jQuery related and that got me thinking. I'm wondering what the ease of these libraries is doing to actual KNOWLEDGE of JavaScript and the DOM.
So much is done for you that my fear is there is a growing number of web developers that actually know very little about JavaScript besides how to include the jQuery library and use the plug-ins they download. It's the "fast food" approach to software development and, based on nothing more than anecdotal evidence, I think a lot of web "developers" would be in the dark when it comes to client script if they were suddenly unable to use the jQuery library.
My question: are these libraries helping or hurting REAL knowledge of client-side scripting?
In my opinion jQuery is to DOM as the .NET Framework is to the Win32 API, or GTK+ is to X11 programming. It's another layer on top of the "raw" API. It makes things a lot easier to work with, at the "cost" of abstracting the lower level details. Usually this is OK, but sometimes these details are important. It can help at times to be familiar with the underlying API (I think moreso in the jQuery/DOM case than .NET/Win32), but I wouldn't worry overmuch if someone has to hit a reference site or two before coding a pure DOM solution.
It's also important to recognize the difference between "JavaScript" and "the DOM". The DOM is not part of the JavaScript language; it is merely an API exposed by to the JavaScript engines in the major browsers. So while using jQuery might hinder one's knowledge of the DOM, it won't hurt their knowledge of the JavaScript language itself.
This is common question in programming.
Libraries and high levels of abstractions, in general, make things that were once difficult, much simpler. This tends to make the number of people who understand low-level internals smaller, but also increases the overall productivity of the industry.
jQuery have hurt my knowledge of DOM: I forget this **** DOM as a nightmare.
jQuery will never hurt my knowledge of JavaScript. You can't forget JavaScript after Crockford's texts
I started by learning Javascript as a child - HTML + Javascript was the easiest thing to deploy without having to actually know much about how computers worked. Since then, I feel that I know more about Javascript than I ever would have to.
However, there are very few projects now for which I use Javascript without jQuery. In fact, before I knew about jQuery, I made my own libraries. They weren't great, but they worked, and saved me loads of time and repeated code.
I guess my point is that the Javascript pros would have produced great libraries for themselves, no matter how many n00bs ended up grabbing onto them. Even if we're hurting beginners' knowledge of Javascript (an assertion which I'm not even going to make), jQuery is still definitely a good thing. What it does to beginners is a question of the learning process we offer beginners, rather than the tool itself.
I think that jQuery and its peers are probably greatly increasing general knowledge of Javascript. When I discovered jQuery I went from disliking Javascript and using it as little as possible to thinking it was a wonderful and beautiful language. Indeed, it might now be my favourite language in which to program, and I've learned an awful lot by reading the source code of the jQuery library. I can't believe that my experience is in any way unusual.
Why do you care about the "real" knowledge? The end result is all that matters.
If a developer can make a website that loads really fast with a great interface and layout, then he or she is a successful developer. How (s)he did it is irrelevant.