I want to develop an application that does a bunch of cool stuff. The first thing that I need in it is to get information about the page a person is browsing.
With that said, I need for example to know how long a user stayed in a page and where was the scrollbar. While getting that data, It's all saved to a database.
The thing is, I prefer doing that in Flash [although I have no experience in it] over Ajax since I want to hide the code - which as far as I know not possible in Javascript/Ajax.
So, can I do all that in Flash? - Read the content of the page, get the status of the scroll bar..
Plus, I then need to go threw the gathered information that is saved in the database. Since there could be many calculations i thought C++ .Net is better than PHP [which I know better].
Is that all possible or am I just crazy? :)
Thanks ahead.
Server side
I think it doesn't matter whether you'll use PHP/C++/Java/Ruby/Python/whatever... each of these is fast enough to do complex calculations, especially if we talk about pure math.
So if PHP is what you know the best, then it's obvious to use it.
Client side
Flash is pretty cool for animations and others visual effects, but for things like scroll position, time spend on website JavaScript is just better. It doesn't require third-parties plugins, it's integrated with DOM. Personally I just thing JavaScript is the most proper tool for this task.
I vote for JavaScript, you can do in JS all that you mention, using the DOM, and it has not a proprietary license.
Although you cannot compile JS code, obfuscation tools offers a decent level of protection. Closure is worth of mention too, YUY minifier etc.
Also check this ready made JS heatmap.
I advise against using C++ for server side programming. You'll be better off with Ruby/PHP etc.
Related
Ive gotten mixed reports as to how to handle this question while reviewing the web so I thought I should ask you all. I am not sure if its possible to even do with JavaScript, PHP, and MySql, but here is what I wanna do.
Im a manager at a small retailer where I have to schedule 20 people each week. Each day we have different hours, some people are part time, others full time, etc.
Can I create a webpage that can handle this? I was thinking of making a employee database with their status as FT or PT etc but did not know what language would be best to use for a full out functioning scheduler. Also, Id like to eventually add the option to enter day off requests into the form so that the scheduler would not allow them to work on those requested days.
The scheduler would have to be automated and of course may require some user tweaking after it generates.
I AM NOT LOOKING for the code for this.... just suggestions and thoughts as to where you would start (what language, format, etc)
Like #gilly3 said, the language you use is really up to your personal preference and what knowledge you already have. Here are some overviews of the ones I think would be acceptable:
Python is probably one of the easier languages to learn, mostly because of the way it's so easy to read.
There are many great ways to learn it. I like this nettuts+ series. The series is about creating dynamic websites with Django, but before it gets to that, it goes through the python language quite thoroughly. There are also may other sites you can go to to learn about python, such as python.org and others.
Python works best with creating local applications, not online ones. However, there are ways to use python in web development.
You would most likely record peoples stats (part-time, full-time...etc.) in a file, either a python file or another file that could be parsed by python (eg. XML or JSON).
For the results, you could have it print something out to the command line/teminal or use the tkinter library. to open a window and display the schedule visually.
PHP would be your best choice if you plan to record peoples stats in a MySQL database, maybe with phpMyAdmin or something like it.
PHP would need to be hosted on a server (Apache, IIS...etc.), but that shouldn't be a problem.
That too is an extremely easy language to learn, due to the vast amount of resources available, php.net is one of the best places I think, but you may find another that you like better.
If you like HTML, CSS and JavaScript, then you could simply create a webpage and have the user open it in their browser.
If you used this option, you would write out the people's stats in a file (probably JSON if you're working with JavaScript or it could be just plain JavaScript), and simply reference it with a <script> tag or and Ajax call.
There are so may resources out there for learning these that I can't even remember my favorites.
JavaScript is probably the best if you want the user to be able to edit the schedule right in the program.
If you like HTML, CSS and JavaScript, but want a desktop application, check out TideSDK
Keep in mind that if you use PHP and MySQL, you will also have the full power of HTML, CSS and JavaScript in your hands. For that reason, I would recommend PHP. It's only drawback is needing a server, but there are many ways to get around that (XAMPP (windows/linux), WAMP (windows), MAMP (mac) and probably others, but those are the most famous.
Sorry if I've left anything out, feel free to edit.
Again, to re-iterate: This is not a request to program anything for me. I am looking for more experienced web developers to tell me if my idea is really doable, as it involves some pretty tough issues (at least, I think so). Please, if this post is to be closed, could I at least get a little advice on where I should be posting instead first?
Imagine: You visit a website (say malonssite.com). You sign in, you get a double-paned window. Left side is chat list(think FB buddy list). Right side is a "browser".
The chat list is populated by other people who have signed into malonssite.com AND are visiting the same page as as you using the "embedded" browser.
Each user has the ability to "allow followers", at which point whatever site they visit, all their followers "follow".
Image sketch:
My abilities:
PHP
MySQL
Javascript (node.js included, but that's more serverish I guess)
I've done long polling and ajax, but this gets complicated. I am thinking something like this might be best done in flash? Or maybe an oldschool Java applet? I am just not sure.
I am pretty confident I can make this thing on my own, I am just not sure what technology to use. I usually hit stumbling blocks in each area, normally along the lines of the same origin policy. I know that JSONP can get around the SOP, however is it powerful enough to do what I want? I am not familiar enough with it.
Sockets in general (websockets, flash sockets, etc) and node.js are pretty new to me, and I think they somehow hold the answer, I am just looking for some verification.
Thanks!
As I see it, you'll just need an iframe with a JScript asking its src and sending it to the server. So basically the user will stay on your own domain, browsing other web sites in the iframe and you will have no cross-origin-request issues.
You could use ape engine for the server side, which is exactly meant for this sort of things.
It is very possible.
Simple? no. But possible.
HTML/CSS/JS will easily take care of the front end layout,that should be elementary.
Node.js is a good option, and would be best suited if you know that traffic will be heavy.
If traffic won't be heavy, i guess php is OK.
And you will also need a backend database...again, depends on how many users you think you'll have. nosql ones would suit well, although oracle just claimed they 'exponentially' improved mySQL performance.
But think about this idea carefully. The concept of allowing users to communicate if they're on the same page is neat - but they'd have to browse a site within your site....furthermore, you have to account when the user presses next/back button in the browser.
perhaps you could make a fork of firefox and implement this as a software
did you mean something like talkita
or any other solution on google search "chat with others on same page"?
some of them also allow followors (subscribers) etc..
have a look, maybe youll get an idea.
please forget about flash and java applets...
i think this is a great idea and i hope you can get it to work.
I would really use NodeJS + (Socket.IO | SockJS) for the server-side and realtime communication, all your SOP problems will be gone.
As for the client side, just take care of cross browsing the javascript and css
For data persistence, some kind of nosql implementation: mongoDB or couchDB for example
I'm new to PHP, AJAX, and databases.
But I want to know what experiences programmers think and do.
When using AJAX, do you worry about users who have JavaScript disabled?
Do you have a backup solution? Or is the number of those who have JavaScript disabled so small that it isn't a concern?
Wow I got a lot of opinions, which is good, but I think it's important for me to clarify a bit.
I'm asking specifically in terms of AJAX in websites.
When it comes to JavaScript in my websites, I work with the goal of using it to ENHANCE the experience of the user, but ensure that the core of the site will still function for users with JavaScript disabled.
But from my understanding of AJAX, it IS the core functionality is it not? It communicates with the server or database the way PHP does. So how do you make a fallback for that? Or do you?
Again, if I'm mistaken about the role of AJAX, please forgive and enlighten me.
They key is to understand the viewers you are targeting. If your site is plenty useful without javascript, then it may be worth the extra effort to make a reasonable experience when javascript is disabled. You would have to understand the functionality of your site and targetted viewership to know whether that extra effort was worth it or not. There is no single correct answer here.
If your site isn't very useful when javascript is disabled, then it may not be worth the extra effort to try to do anything beyond tell the users that javascript is required. Why put in a bunch of extra effort (and a lot of extra testing) if those viewers won't be loyal to your site and be regular visitors anyway because the user experience will be fairly undesirable.
So, the answer is it depends a lot on what your site does, who your competition is and who your viewers are. Though people on SO like to argue with me in this regard (out of the purity of every web site should work for all - I think), it is getting harder and harder to justify the business case for the extra work for making many sites work without javascript these days. It, of course, depends upon the specifics of your site, competition and viewers. In my book, it is by no means a given that you should make every site work without javascript enabled.
If you Google, you can find articles that discuss how many users have Javascript disabled. This Yahoo article from mid 2010 says that they saw .25% - 2% of users with JS disabled.
As for Ajax specifically, there is no like replacement or fallback without Javascript. If you have a design that depends upon using Ajax for communicating with your server, then that design will require Javascript - period. Your only alternative would be to have a non-Ajax design (a more traditional page request from your server with one URL for one static page) that could be served instead that did not use Ajax. If your other design used and depended upon Ajax, this non-Ajax design would be a significantly different design and implementation.
When creating a website, the key is to create a site that works regardless of the user's settings. Your site's design and functionality should not be dependent on the user having Javascript enabled.
Just make a container around everything and set the display to none using CSS. Set "onload" to a JavaScript function that sets the display back to "block". This way, only stuff in the "noscript" tag will show when JavaScript is disabled. You can use it to say that your web application uses AJAX, ect. I like to showcase a privacy policy that NoScript users will be happy about on these fallback pages.
So, I'm new to dynamic web design (my sites have been mostly static with some PHP), and I'm trying to learn the latest technologies in web development (which seems to be AJAX), and I was wondering, if you're transferring a lot of data, is it better to construct the page on the server and "push" it to the user, or is it better to "pull" the data needed and create the HTML around it on the clientside using JavaScript?
More specifically, I'm using CodeIgniter as my PHP framework, and jQuery for JavaScript, and if I wanted to display a table of data to the user (dynamically), would it be better to format the HTML using CodeIgniter (create the tables, add CSS classes to elements, etc..), or would it be better to just serve the raw data using JSON and then build it into a table with jQuery? My intuition says to do it clientside, as it would save bandwidth and the page would probably load quicker with the new JavaScript optimizations all these browsers have now, however, then the site would break for someone not using JavaScript...
Thanks for the help
Congratulations for moving to dynamic sites! I would say the following conditions have to be met for you to do client-side layout (it goes without saying that you should always be doing things like filtering DB queries and controlling access rights server side):
Client browser and connection capabilities are up to snuff for the vast majority of use cases
SEO and mobile/legacy browser degradation are not a big concern (much easier when you synthesize HTML server side)
Even then, doing client-side layout makes testing a lot harder. It also produces rather troublesome synchronization issues. With an AJAX site that loads partials, if part of the page screws up, you might never know, but with regular server-side composition, the entire page is reloaded on every request. It also adds additional challenges to error/timeout handling, session/cookie handling, caching, and navigation (browser back/forward).
Finally, it's a bit harder to produce perma-URLs in case someone wants to share a link with their friends or bookmark a link for themselves. I go over a workaround in my blog post here, or you can have a prominent "permalink" button that displays a dynamically rendered permalink.
Overall, especially when starting out, I would say go with the more kosher, better supported, more tutorialed, traditional approach of putting together the HTML server side. Then dip in some AJAX here and there (maybe start out with form validation or auto-completion), and then move on up.
Good luck!
It is much better to do the heavy lifting on the server side.
In CodeIgniter you create a view, looping through all the rows in the table adding in the classes or whatever else you would need. There is no reason at all to do this in Javascript.
Javascript is a sickly abused language with unfortunate syntax. Why on earth would you want to load a page, and then issue a AJAX call to load up some JSON objects to push into a table is beyond me. There is little reason to do that.
Javascript (and jQuery) is for end user enhancement. Make things slide, flash, disappear! It is not for data processing in even the mildest of loads. The end user experience would be crap because you're relying on their machine to process all the data when you have a server that is infinitely more capable and even designed for this specifically.
It depends on your target market and the goal of your site.
I strongly believe in using the client side where ever you can to offload work from the server. Obviously its important you do it correctly so it remains fast for the end user.
On sites where no-js support is important (public websites, etc), you can have fallbacks to the server. You end up doubling code in these situations but the gains are very beneficial.
For advanced web applications, you can decided if making JS a requirement is worth the trade of losing a (very) few users. For me, if I have some control over the target market, I make it a requirement and move on. It almost never makes sense to spend a ton of time to support a small percentage of potential audience. (Unless the time is spent on accessibility which is different, and VERY important regardless of how many people fit into this group on your site.)
The important thing to remember, is touch the DOM as little as possible to get the job done. This often means building up an HTML string and using a single append action to add it to the page vs looping through a large table and adding one row at a time.
It's better to do as much as possible on the server-side because 1) you don't know if the client will even have JavaScript enabled and 2) you don't know how fast the client-side processing will be. If they have a slow computer and you make them process the entire site, they're going to get pretty ticked off. JavaScript/jQuery is only supposed to be used to enhance your site, not process it.
You got the trade-off correctly. However, keep in mind that you can activate compression in the server side, which will probably make adding repetitive markup to format the table a small bandwidth cost.
Keep also in mind that writing Javascript that works in all browsers (including hand-helds) is more complicated than doing the same server side in PHP. And don't forget that the "new JavaScript optimizations" do not apply to the same extent to browsers of handheld devices.
I do a great deal of AJAX app development and I can tell you this from my experience. a good balance between the two is key.
do the raw data server-side but use javascript to make any modifications that you would need to it. such as paging, column sorting, row striping, etc.
I absolutely love doing everything in AJAX heh.. but there are some short falls to doing it using AJAX, and that's SEO. search engines do not read javascript, so for the sake of your website's page rank, I would say have all data served up server side and then formatted and made look cool client-side.
The reason I love AJAX so much is because it drastically speeds up your APP usage by the user as it only loads the data you need to load where you need to load it, versus load the entire page every time you do something... you can do a whole bunch of stuff, such as hide/show rows/columns (we are talking about table manipulation here because you mentioned a table) and even with these show/hide actions add delete actions where when you click a delete row or button it deletes that row not only visually but in the database all done via AJAX calls to server-side code.
in short.
raw data: server-side sending to the client the raw data in html layout (tables for table structured data, however I do everything else in divs and other flexible html tags, only do tables for column/row style data)
data formatting: client-side which also includes any means of interacting with the data. adding to it, deleting from it, sorting it differently etc. This achieves two things. SEO, and User Experience (UX).
I have a doubt: -
Is there any standard/convention that when should I use "Smarty templating" and when should I use Javascript Ajax calls to produce the content? I can use Ajax/Javascript calls to produce the content dynamically.
My application uses both Ajax and Smarty, but I want to set a rule for developers
You should only use AJAX calls to load dynamic data that is not known at the moment the page is loaded. For example, when you click the "comments" link for a given question/answer on Stack Overflow, an AJAX call is made to dynamically load the data. This is a result of the user clicking the comments link, not a result of the page loading. You don't know that you should show those comments at the time the page is loaded, so it is appropriate to make an AJAX call in this case.
You should use templating to show any data that is known at the moment the page is loaded. It makes it easier to deal with people that have Javascript disabled (I know, not a lot), and it provides a clear separation of logic from presentation. Another important benefit of using templating is the fact that is can significantly decrease the number of HTTP requests made from the client's browser.
This is especially important in the mobile browsing world where latency, not bandwidth, is your biggest obstacle. In mobile Safari, for example, a single HTTP request to a Smarty-templated page will load significantly faster than a request to load a Javascript-templated page that makes five or six additional HTTP requests. This is especially true when using EDGE, 3G, and other non-wifi mobile data services. In fact, this is so important that it is the first guideline in Yahoo's Best Practices for Speeding Up Your Website.
Ideally, you should also gracefully degrade functionality when Javascript is disabled. A good example is an auto-completing search box. It's really cool to have suggested search terms magically appear as you type, but if you turn off Javascript, you still have a functional search box. That's a classic example of a good degradation in service. Stack Overflow generally does a great job providing a solid non-Javascript experience. One place it falls short is in the comments. When Javascript is disabled, only the most popular comments are displayed, and posting new comments is disabled.
Unless absolutely necessary, you should think of Javascript as a bonus feature that might not be enabled, not as something that should be used to construct critical pieces of your website. There are obviously exceptions (some things just can't be done without Javascript). You'll notice, for example, that Stack Overflow is very usable with Javascript turned off. You won't get the real-time updates when new answers are posted, or fancy real-time Markdown previews, but the core functionality is still there. All the "heavy lifting" is done with HTML and CSS. Javascript is just icing (admittedly very good icing) on the cake. This is kind of a side note, but it's important enough to mention.
It probably depends on what sort of work you are doing in your templates. Personally, I hate doing a lot of heavy style/layout stuff strictly in Javascript. If you can load the bulk of your layout via. Smarty and just change specific bits of data (just the data, not the markup/style, if possible) that might be a good place to start with for standardizing within your own developer team.
Use templates for server-side generation and DHTML/AJAX for anything after the original page load (not using a refresh). Even then, the server response for the AJAX call itself can be assembled with a template, which may work best for any non-trivial content.