workhere-io
Joined 13 years ago
Karma
1,163
Submissions
371
Member since
May 31
Recent submissions
Comment · 12 years ago
For PostgreSQL: RDS or Heroku Postgres.
Comment · 12 years ago
Does this mean that all FastMail accounts are now hosted in Iceland?
Comment · 12 years ago
Node's big advantage (some would say disadvantage) is that it uses JavaScript (or languages that compile to JavaScript). There's a good ecosystem around it. However, let's face it, the whole asynchronous thing is a pain - even if you use the async library or promises or whatever. Node enthusiasts would say that the asynchronous thing is necessary for great performance, but the reality of it is that there are plenty of languages that outperform Node without using asynchronous calls: Java, C++, Go, even raw PHP without a framework in some cases (see http://www.techempower.com/benchmarks/#section=data-r8&hw=i7...). Another reality is that most sites don't even need such high-performing languages. Instagram with its 200 million users uses Python, and Facebook used "normal" (uncompiled) PHP up until the point when they had 500 million users.
Comment · 12 years ago
Don't think you are gaining any SEO-benefit from one-page JS-only applications, just because Google made it possible for you to start ranking.
No one is expecting to get any SEO benefits that "normal" pages don't have. We are expecting to get the same chance of ranking as normal pages.
You mentioned that single page apps might rank differently or worse than normal pages. Do you have any source for that? (A source that is current, since Googlebot's improvements are quite new).
Comment · 12 years ago
Which I emphasized in the post :)
Comment · 12 years ago
If anything but almost all of your website is static, you won't be saving all that much time.
Single page apps can easily be static (static HTML page + static JSON). The point of this would be to decrease the download size for each new page visited by the user.
Comment · 12 years ago
But, have Yahoo or Bing or DuckDuckGo made the transition to be able to crawl the web with a full JS & DOM rendering engine?
They can just use PhantomJS (http://phantomjs.org/), which is free and open source.
Comment · 12 years ago
What they were saying before was that you always need a HTML fallback for JS-generated content. Now it seems they're saying you don't necessarily need to.
Comment · 12 years ago
For each new page on your site that your user loads, the benefit of single page apps becomes greater: Now she only has to load a bit of JSON, not a full page. So essentially single page apps are a tiny bit slower on the first page load, but much quicker on subsequent page loads.
Comment · 12 years ago
Author here. Some of you are saying that this will lead to bloated, JS-heavy websites. I disagree. The JS necessary for making a single page app can be done with something like 10 lines of JS (plus jQuery or something similar, but that is already included in most normal pages anyway).
A single page app isn't JS-heavy by definition, and a "normal" page (with HTML generated on the server) can easily be JS-heavy. It all depends on how you program it. Just keep in mind that single page apps don't necessarily need to use heavy frontend frameworks such as Knockout, Ember or AngularJS.
Comment · 12 years ago
One potential problem here is that google will use this to widen the gap between it and the 'one page apps' web and other search engines (such as duckduckgo) that can't match it in resources.
There are free and open source tools available that would help search engines parse pages containing JS (PhantomJS comes to mind).
Comment · 12 years ago
I agree with you; developers definitely have to think about the URLs they're exposing to Googlebot. But this is essentially no different from how things were before. Your example with sorting a list by date instead of name would be done with a query string (which Google does index to a point), e.g. /users?sortBy=date=&from=392. This can obviously create quite a lot of links to the same content, and developers should know how to handle this situation. Again, not different from before - single page apps don't change anything in this regard.
Comment · 12 years ago
Those who claims that developpement is easier with framework on a single page have too learn programming, because for most case, the "old" way works very well and is incredibly faster than a bloated javascript page.
Who says the page will become bloated with JS just because you use clientside loading? The mechanism I'm talking about can be done with something like 10 lines of JS or less. No one's saying you have to use AngularJS with every web page you make.
When the article say "put the CSS inside a <style> tag on the page - and the JS inside a <script> tag", it's just horrible, fuck it.
First of all, this is not a requirement of single page apps, just an option. Secondly, when you're developing, you would still have your JS and CSS in separate files. Your compiler would then minify the whole thing and put it inside your minified HTML file.
Comment · 12 years ago
The whole point is to make the experience better for the user: When going to each new page on the site only involves fetching a bit of JSON and not an entire HTML page including header, footer, JS, CSS, etc., that makes the user experience faster. Add to that the fact that since the front page HTML now no longer contains any dynamic elements (you would get those dynamic elements via JS), you can put your front page HTML (the one HTML page there is) on a CDN and get faster load times.
As for speed: Sure there are exceptions when developers go crazy with tons of heavy JS, but that doesn't need to be the case at all.