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'm implementing typical server-push (comet) application. I'm choosing between two options: the longpoll XHR and iFrames. What are pros and cons of these? I know about the cross-site restrictions and that iFrame is pretty heavyweight component... are there any other differences? For example the "reliability" of the transport or level of control over the component?
What do you think, is there a single right answer which approach is better or there are use cases for both of them?
Thanks in advance.
P.S. I got a pretty good working XHR implementation, but I want to consider the alternatives.
you should use socket.io or an equivalent library. It supports both ways you mention and more:
http://socket.io/#transports
However, let's assume your using an appropriate abstraction layer, and now want to decide which transport to use. :)
IMO, the deal-breaker for iframes is error handling. The continuously loading iframe technique makes it much harder to do error handling. You're not informed via a convenient event of 404s or timeouts, so you have to set an interval in the JavaScript to watch for errors.
Supposedly iframes have less overhead than making a new XHR/HTTP request to reconnect after every message, but when I tried it all I saw was increased memory overhead on my server and zero responsiveness improvement; probably it depends on your choice of backend.
Another interesting factoid is that browsers are limited to two concurrent requests to a server by the standard, but Mozilla made an exception for XHR only:
https://developer.mozilla.org/en/XMLHttpRequest
When you're making long requests, the 2 connection limit is really important: if you tie up both pipes, nothing else will be able to get through! You have to be care to set up a single channel that all the code on the page shares. But on Firefox, you now get some wiggle room, if and only if you use XHR.
Iframes do have the advantage of being able to make cross domain requests.
I would suggest a third option: websockets. The websockets api is an evolution from long polling and is developed for real time client-server communication.
The protocol isn't supported by all browsers so you actually still need to support long polling when websockets aren't available.
There are libraries that degrade nicely (if websockets are available they use those, else they fall back to long polling). You have socket.io (supports all browsers). A jQuery alternative is jquery-graceful-websocket. Both libraries expose the websocket api but fall back to alternatives for the communication if necessairy.
One thing to potentially worry about if it's going to be smartphone friendly is that carriers can and will mess with data as it goes through their network. Normally to compress it.
Since the iframe method kind of streams a webpage with some JS in it, it looks more like a webpage to the carrier and is more likely to be messed with by a carrier. In this instance, them cacheing it up so that it can't leak through would be my primary concern - they are unlikely to change the meaning of your actual JS.
An XHR (especially if you're actually returning XML) is less likely to be messed with by the carrier.
Of course, a good carrier will understand what is going on and let both methods work. Not all carriers are good, though.
A difficult thing to judge and plan for but worth considering.
I don't know what you mean comparing iframe to longpull, but in my opinion iframes are very risky and make developing harder many times because of mentioned by you browser restrictions. And from the other side longpull XHR should be simplier to implement with your current XHR implementation. It also gives synchronizing comparing to asynchronous XHR.
Certainly XHR is the cleaner solution and has all the previously mentioned benefits.
Since the code is easily implemented, I suggest you do both and test on a number of platforms. Create two apps which will display the number of missed polls, and beg a dozen friends to run the app on as many of their devices as possible.
Then report back!
I think longpoll XHR is a better route to go for a couple of reasons:
It's the future. iFrames are loosing ground fast.
I think it's a better seperation of data and display. You can get the data, and then handle the display in the client. This will also allow you to have the same data source and display it differently for different platforms. Display in a PC web browser would be different than display on the iPhone.
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 10 years ago.
I want my node app run continuously. I'm sure that some crashes can appear during the app's work. Nowadays i can see 3 ways of making an app work continuously:
Start my app with forever, so when the app crashes forever will restart it automatically
Use domain module to catch errors and start the app again when "error" event is emitted
deprecated process.on('uncaughtException')
The question is: which of these 3 ways is better to use. It seems to me like there's no exact answer to this question, so any comments are welcome.
In my opinion the first one is more appropriate because node process memory consumption doesn't grow with time - each time the node process crashes forever starts another one.
Ah, that's a tricky question. First of all, domains approach differs from forever in that it doesn't force you to restart the whole Node process. Say, for example, your Node application processes requests coming from several clients simultaneously. By carefully configuring your domains you (at least, in theory) will be able to prevent other requests from failing when one of the requests throws an error.
However, in practice to get domains work some components of your application has to be domain-aware. That applies to third-party components, too. For example, a database connection module that uses a pool of connections internally, should not wrap them into it's own domain, but rather check if the callback has a domain attached to it already. Otherwise, an exception thrown in a database code would be caught in a module's own domain and your domain wouldn't know about it. So, in order to use domains with third-party code you have to heck first if that code was written with domains in mind.
forever simply restarts your application whenever it crashes. It sounds like a worse idea than domains, but it also doesn't impose any specific requirements over a third-party code. Thus, you can use whatever library or module you want. You also don't have to put any complicated error recovery logic into your code. Sometimes having a simple codebase is more important than having non-failing yet complex one.
As for process.on('uncaughtException') I wouldn't use it. It's deprecated now, so it will probably be removed at some point.
Here's my breakdown:
forever
Pros:
lets you keep your codebase simpler and smaller
allows you to write your application logic first and think about error handling later
Cons:
Single uncaught exception causes all other requests to fail
Use when:
Your Node process and your requests are cheap
Clients can retry on error
domains
Pros:
Broken request doesn't break other clients
Node process stays up longer reducing your overall downtime
See also domains+cluster combo (Thanks, Isaac!)
Cons:
Can be used with domain-aware 3rd-party libraries
Requires additional logic in your program
Use when:
Your requests or your Node process are expensive (e.g. file uploads, streaming data)
Single-node uptime is important
process.on('uncaughtException') don't use it.
Notes
Isaac Z. Schlueter and Felix Geisendörfer talked about domains in 13th episode of NodeUp
There's a recent article explaining the difference between forever and Unix's systemd. You may find it useful.
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.
Hey everyone — HTML5 Boilerplate and HTML5 Reset are two HTML, CSS, and JavaScript templates with a lot of modern best practices built-in. Their goals are largely the same:
Fast, robust, modern Web development
HTML5 (duh!)
Cross-browser normalization (including support for IE6 and mobile browsers)
Progressive enhancement and graceful degradation
Performance optimizations
Not a framework, but the starting point for your next project
Obviously, they're very similar in function. In what ways are their implementations different (for example, perhaps IE-specific CSS fixes are achieved using different techniques)? Are they at all different in scope? It seems like HTML5 Boilerplate is a bit larger (build tools, server configuration, etc.), but it's hard to know where it goes beyond HTML5 Reset when it comes to the actual site that people will see.
In general, both projects set out to provide a solid starting point for developers working on web projects. They both get rid of a lot of the tedious, some-what error-prone boilerplate that many developers find themselves re-creating for each project. The details in how they go about it are slightly different, but for the most part, they achieve the same results.
HTML5Boilerplate has, as you noted, added in some build-script pieces to help developers follow best practices to speed up their pages in terms of server-side items, such as far-future expires headers, etc. where-as the HTML5Reset project is more focused on the semantics, content, and styling. For example, HTML5Reset has more example structure for the content of the page in HTML5 (to help show people how to use some of the new elements), whereas HTML5Boilerplate does not.
The response-time and page speed parts that HTML5Boilerplate includes get more and more important as more users find themselves on mobile platforms, and as Google increases the effect page response times have on page rank. There are lots of papers that show a small increase in the page response time has a measurable negative impact on how your site is used and perceived (especially in an eCommerce setting...often a 100ms slower page will get percentage less things sold).
On the CSS front, the majority of the reset style section for both projects is very much the same, with some minor differences in what the baseline is set to. The IE specific fixes, however, are largely the same, with HTML5Boilerplate asserting a bit more control than HTML5Reset over how IE styles some things like form elements (ie. check box / radio buttons and valid / invalid states)
Two major CSS areas that HTML5Boilerplate covers that HTML5Reset does not are common helper classes to assist with making sites more accessible, such as .hidden and .visuallyhidden, as well as some substantial adjustments to the print styles that serve to both make printing more similar across browsers, as well as some cost-savings and accessibility things like making background images transparent (to not waste toner), and adding the actual URL to links and the title to abbreviations.
I would highly suggest reading through both projects' info and how they do things in a side-by-side comparison because the similarities, and also the differences (and the reasoning behind them) is quite informative and has helped me to better decide what parts of each I wanted to use.
Ultimately, just like any "library" sort of project, you as the developer need to understand what you are doing and probably should tweak your baseline to meet the particular needs of the project.
You can use either one...
Like #murtaugh said (http://5by5.tv/bigwebshow/45) you don't need to learn anything when u first start with Reset. In my experience, working in an R&D department, when you need to demo or do quick iterations you can use the Reset (or Boiler if u already know it). When I need to build the product for deployment I turn to Boiler just because has more stuff.
Works for me but now because I know both I can easily use either one.
I actually almost want to say using the traditional reset.css is the best... I find no problems with compatibility in my mobile apps. However, I am developing these apps using the jQuery mobile framework.
So I guess it's really conditional as to what kind of tools you are using. Phonegap doesn't seem to have any problems compiling my code into all OS. And viewing my source code in emulators looks perfectly fine...
So I really don't see the point of a boilerplate unless you are trying to achieve polyfills.
I work in an environment where previous developers roped the company into using both JQuery and Prototype...and it's a mess. Not only do we have to work out of compatibility mode, but just think of the extra overhead that it causes. When debugging, Prototype "hijacks" debug messages in Firebug, which leads to even more work. And the maddening part is that I've been undoing this mess for months and am just starting to get close to being done with it....and just when I'm about to pull the plug on Prototype I always seem to find another section that relies on it...
It's for this reason that I argue every time against combinations of frameworks that have similar purposes. For example, no matter how cool you might think YUI Grids is, if you load the entire YUI Framework you best not be doing Jquery, Moo, or Prototype. You'd be just needlessly bogging yourself down. It kills the load time (which wrecks the user experience) and just gives developers headaches and needless work.
Look at this phase of your site like building the foundation. You have the opportunity to use anything you want to use, but you have to be careful not to "paint yourself into a corner" so to speak. So, use purpose-built and best in class tools that are available based on your resources. Don't just use something to be cute! We're lucky in that many very high quality tools are free, so we have a choice. But know that you're steering the direction of your site for the future, and you might be the person like me who has to deal with the consequences if your decisions are hastily made.
So, unless you're NEVER going to use another framework, I endorse Reset...or even just doing top quality standards compliant CSS.
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 12 years ago.
When we make a website with some interactivity (not whole flash site). should we always find a way JavaScript way before to use Flash? Should we consider Flash a last resort, if possible?
It is true Flash will not be indexed by Search engine. and it will not run on apple devices.
Will javascript also perform better than flash, in terms of speed?
Edit:
And how to know , the effect which we want to achieve and possible in Flash , can be possible in javascript?
Flash has it's advantages. I personally love JavaScript and are always surprised what is possible without Flash. But on todays browsers you can do a lot more with Flash and it ill perform a lot faster.
In the bright future, you might be able to do almost everything you can do with Flash using JavaScript and the canvas element. But until the majority of all browsers will support that, there are some things you can only do with Flash.
I don't use flash on any of my projects anymore and I also have a lot of fance stuff on them. But I also have a fallback for non-JS users and you should also have that for non-Flash users. and because a JavaScript application/widget is build using HTML and CSS, such a fallback is much easier to realize than doing it with flash.
I don't say, that you should not use flash at all, but you should make yourself a list of things you want to have on your website and than search for JavaScript libraries or plugins that can do that.
Isn't anyone bored with this question yet? There are tons of answers/non answers on the internet. One could write a book about Flash advantages & disadvantages, actually many books :) I personally don't think there's a rule you can apply to every project that will let you know if you should or shouldn't use Flash. This is a personal choice , based on the type of project you're dealing with , the languages you're comfortable with and the objective you're trying to achieve.
Some clients won't care about not being able to be accessible on Ipads, some others will. You don't tackle a business site the way you would tackle an artist portfolio. Keep your options opened and , more to the point, master as many languages as you can and when you do, I have no doubt you won't bother with this question again.
so:
should we always find a JavaScript way before to use Flash?
why not? if JS can do it with similar quality & performance, why go Flash?
It is true Flash will not be indexed by Search engine.
Google has made a lot of progress in indexing Flash content so it's not entirely true
and it will not run on apple devices.
False. It will run on most apple devices, of course not the Ipad!
Will javascript also perform better than flash, in terms of speed?
that would depend on what you're trying to do
And how to know , the effect which we want to achieve and possible in Flash , can be possible in javascript?
Some level of understanding of both languages would help
I'd say no, but then again I might be bias.
Flash is good for its own certain points and needs. I think that it has received bad press as it has been misused a lot, it is not a replacement to other languages but has been used that way for quite a while. It should be used when needed, rather than an instant fix to make things look "cool" or "modern".
Flash is good for application based design, multimedia and complex animations. This admittedly is rather fuzzy, but it's hard to define nowadays closer than that. Javascript on the whole is a very powerful tool, and the new HTML <canvas> tags allow a great flexibility on what can be accomplished with JS, CSS and HTML, but requires specific support that isn't guaranteed on all browsers (10% of people still use IE6 supposedly) so it's very much a gamble on who your target market is to what you should be doing.
On the whole if you know what you are doing it is possible to do nearly all that flash does in javascript/css/back end technologies, but it is less encapsulated than a flash example, and as far as I know flash is more efficient in its resource allocation and can take advantage of CPU enhancement, where javascript can't as of yet. It all depends on specifically what you are trying to put together and how complex/portable you want the code to be. If you are putting together a 3d shooter, use flash, if you are trying to move a <div> 5 pix to the right, use javascript.
Flash in itself will run on "apple devices" except for the iPhone and offshoots of this technology (iPad for example) but will still run in safari etc. on macs. and is constantly getting better at being indexed on search browsers, and there are get-arounds for that anyway, so that shouldn't be the reason for stopping you.
Have a look at jquery examples like this page to see some of the fun things you can do, and maybe some inspiration.
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 13 years ago.
Sometimes I hear the argument against doing things on client side using javascript. People say stuff like "JavaScript is inefficient...or slow". I'm wondering if there actual facts supporting this conclusion?
There are really two factors to Javascript performance:
Your code
The scripting engine running your code
Your code is the easiest factor to fix. As you develop, optimize your code as best you can. Easy.
The second isn't always as easy. I've had some applications where performance on one browser was excellent and another was slower than mud. Others run great across the board. Best you can do is test, test, test, and test again. If you want a good article, check out the link:
Coding Horror: The Great Browser JavaScript Showdown
That depends alot on the browser's javascript engine.
Over all, it's a scripting language, so it won't do as well as C++ or another compiled language. However, it's good at what it was intended for, and that's drive web pages.
Javascript is FAST if you use it properly. Otherwize it behaves bad.
Eg: an unlimited loop can hang your browser. (But browser will ask you whether to stop the execution)
The choice of what tasks to perform on the client versus on the server is an important one, and the efficiency of JavaScript as a language is not the only factor which needs to be considered.
Data which will be manipulated on the client must be transmitted to the client. If the script does not need all of the information which will be pushed down to the client, then page load time will suffer, and the filtering operation will be done on the less-efficient end of the link (i.e. you will pay for the network transmission time before the user gets their information).
Business rules which run on the client will be exposed to curious end users.
Validation business rules which are run on the client must be run again on the server, because you cannot trust code running in an environment you don't control.
The different browsers and even between ECMAScript implementations available within a given browser family make this question nastily subjective and subject to a lot of variation.
Well, it depends. What are you comparing it to? It differs alot between differnt browsers.
It can be really well performing, or the opposite, depending on the code written.
You HAVE to use JavaScript to do certain things, like manipulating the dom for example.
I would imagine that in most cases it is much quicker than a post back!
I would say it's incorrect answer. How would you measure JavaScript performance and that would you use for comparison. I guess as long as JavaScript is the only option for client side web programing (I'm not talking about VBScript) you cannot really say anything regarding it's efficiency.
Also depends on how you write your code. If you follow best practice it's fine and as said before, it's better than postbacks!
You can only really answer that question in the context of a specific problem you're trying to solve. Post an example and then we can debate the merit's of various technologies...
Javascript is not inefficient, efficiency does not depend on the language. Interpreters might be inefficient. For instance Firefox interpreter runs very slow in FF for Linux and much better in FF for windows. Chrome has implemented an interpreter which is much faster. There are Javascript interpreters that does not run into a browser, they are usually faster.
I guess what people are trying to tell you is: do what you can on the server, instead of putting all of the code in the client side.
Javascript performance differs from a browser to another (or from an interpreter to another), but javascript shouldn't serve the same purposes as server-side languages.
I'm a 'numbers guy' so when anybody says things like "well X is slow" or "of course, because Y is fast" that really gets my goat. So for starters, you need to use real data if you're going to make any kind of assessment:
JavaScript Performance Rundown
I also think watching Dromaeo in action is kinda cool
Modern browsers are implementing more and more just-in-time compilation to their interpreters.
My rule of thumb is that if you can't rely on JavaScript being turned on, do as much on the server as you can. If you absolutely know that JavaScript is on, do as much in the client as you can and you'll save on bandwidth and server load.
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.
As users, we love the power of Greasemonkey. As developers, it can complicate things.
Some people advocate defensively disabling user scripts; others are willing to die to defend them.
Is there a middle ground? How can we reduce the threat of an evolutionary arms race between users and unscrupulous advertisers?
Any control you think you have over which user agents your site visitors use is illusory. However, the vast majority will be using vanilla IE/Firefox/Safari. But, if you've a site where the audience has adopted a Greasemonkey script en masse, then treat that as a strong vote from your users that the site needs to change!
If your users are using a Greasemonkey script and coming back, take it as good fortune: there's something they need that you're not giving them, and they haven't left yet.
If they didn't have Greasemonkey, they'd be gone. What can you do to keep them?
If someone uses a browser plugin or modification of any kind, you shouldn't attempt to block them or disable it- that's just likely to result in more problems.
On the other hand, you shouldn't support them either; if it works, let it work, if it breaks, let it break.
Lots of people use dodgy browser add-ons, sometimes unintentionally and occasionally without any choice (Corporate IT imposes some dodgy IE modification on them). Try to play nicely with everyone.
I agree with MarkR (+1, by the way).
The application is on the client side...
So whatever web designers will try to do to stop some feature, they will either anger their users, have them hack away another solution, or move away to friendlier sites.
(I hate it when some broken down site needs me opening my Firefox debugger to enable me to complete my correct for just because some braindead developer forgot to declare his i loop variable and thus, making it a global... And I did it again less than two days ago)
As online apps should never rely on client-side controls and protections (i.e. testing the date value on client is a cool bonus, but testing it anyway and always on the server is the thing to do).
To the worst thing that could happen would be for the app to break on the GM user because of some faulty script. But from the server viewpoint, it should remain pristine.
... Thus, the client should be held responsible...
That means that whatever hack the user adds to his browser, the user is then on his own. At the very best, he/she could discover some hidden bug and report it. On the worst side, the site won't work properly
...Now, does it means client/server cooperation, too?
Most people using GM or whatever to enhance a site is showing that the site does not suit exactly is tastes. The good thing, like Rich wrote down, is that they are still on your site, and not elsewhere.
Either the "enhancement" is for his/her own very personal taste, and, hey, what's the problem if he/she wants to see your black-on-white web page with yellow-on-blue? Or perhaps the "enhancement" adds a lot of value to your site. In this case, I guess that what you want is to either offer the same features for everyone (thanking the author of the GM for his idea could be a good idea), or perhaps support it as an optional feature ("click here for advanced experience") or... an GreaseMonkey script?
I don't see why developers should hate it?
Advertisers? Nowadays, I doubt people write GM scripts to get rid of ads, they use AdBlock [Plus] instead...
In general, I write GM scripts to improve something lacking in the sites where I go frequently, so if you try and take measures to disable GM, I would be very upset and might boycott the site.
Beside, I guess that the number of people knowledgeable enough to install GM (even those using pre-made scripts) is quite small with regard to total number of visitors.
We've got accept the reality of our platform: once your website is in the (computer) memory of the viewer, they're able to do whatever they want with it, without your permission. Popular sites that try to dictate their own viewing terms to their audience often suffer immediate and angry backlash - instead of trying to do it your way, let the users do what they want, embrace it, and you'll end up providing a better service, which your users will appreciate and reward.