workhere-io

For PostgreSQL: RDS or Heroku Postgres.

Does this mean that all FastMail accounts are now hosted in Iceland?

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.

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).

Which I emphasized in the post :)

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.

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.

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.

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.

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.

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).

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.

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.

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.

Clientside rendering doesn't need to be heavy at all. In fact, you could do it with just $.getJSON('/api/users', function(data) { $('#users').text(data.content) }.

Sure, that requires jQuery, but most "normal" sites require jQuery, too.

As I mentioned in the post, all these problems can be solved by using real paths/URLs and changing them dynamically using pushState.

I see what you mean. However, given the large number of different CMSes, I'm not sure designers would appreciate having to re-learn how to design every time they use a new CMS. Right now they use a relatively small "default" set of tools, with PhotoShop being the chief one.

I'm not a designer, but my feeling here is that designers wouldn't appreciate the workflow you're suggesting. Any designers here who'd like to weigh in?

Once you leave design and layout to non-designers/non-layouters, they will ruin everything, and you will get angry calls from the companies' designers, complaining about how their beautiful design was ruined by someone using Comic Sans on a header. I've seen it happen. This is why CMS makers know that editors / article writers should not be allowed to design/layout pages.

Ideally, a WYSIWYG editor in a CMS should only allow users to use bold, italics, links, and perhaps insert small images. Anything more than that, and your web pages end up looking like MySpace/GeoCities.

Braintree's checkout process is every bit as easy to implement as Stripe's. However, signing up for Braintree and getting approved takes longer (at least in the EU - I don't know what the situation is in the US). On the plus side, Braintree works in several countries that Stripe doesn't yet work in.

A bit late to the party. The issue has already been discussed on HN, and the Swiss ended up rejecting the bill anyway: http://www.thelocal.ch/20140518/swiss-vote-on-worlds-highest...

I didn't dismiss anything, and I'm not saying $7.25 is okay. I'm merely saying that cost of living should be taken into consideration when comparing countries' minimum wages.

Before you compare it to American wages, keep in mind that Switzerland has one of the highest costs of living in the world. http://www.numbeo.com/cost-of-living/rankings_by_country.jsp

I am not sure where the mail servers are located.

I asked them about this some time ago, and they said their mail servers are in France.

Fastmail.fm is a completely different option, I am using that as well, their biggest problems are: - lack of proper push email (on mobiles)

Plus the fact that their servers are hosted in the US.

http://www.gandi.net/ includes a 1 GB IMAP account with every domain purchase.

I see that Python is still used as hobby language and something serious is written in Java.

Google, Dropbox, NASA, Instagram and Pinterest seem to think Python is more than a "hobby language".

I’m going to go out on a limb and predict that Python is being replaced by Go. I don’t have a lot of information to back up this prediction except that most of the positive articles I read about Go are written by Python developers

The fact that many articles praising Go are written by Python developers doesn't necessarily mean that pythonistas are flocking to Go. It could likely just mean that a few of the people who've hit a performance wall with Python prefer Go to, say, Java.

And you won't necessarily hit a performance wall with Python - it all depends on what you do. Instagram and Pinterest seem to be doing fine using Python.

I'm working on a website for that: http://workhere.io.

AdWords was run on MySQL up until two years ago. The vast majority of developers working on "web-scale" projects won't get to handle projects with larger requirements than AdWords. In that perspective the whole NoSQL trend makes very little sense, especially given the fact that e.g. PostgreSQL and MySQL have a lot of needed features that many NoSQL databases don't, and that the most "hip" NoSQL database a couple of years ago was a database that doesn't even scale that well (MongoDB).

As long as you're aware of the SEO issues it shouldn't be a problem. Whether or not SEO matters in your case depends on what kind of app/website you're building.