Ajaxian

First, I love reMail. Gabor breathes email and search. If you own an iPhone and use Gmail or Google Apps, get reMail--you'll thank him.

That said, it's easy to skim this article and nod, "Yeah! Yeah!", but when we're discussing these, laymen may need to know a few of these seem over-simplified.

> "TCP connections are great, but for transferring large amounts of email securely, HTTP is the way to go."

1. http://wiki.answers.com/Q/What_is_the_difference_between_tcp_and_http - HTTP uses a TCP connection. For that matter so does SMTP and IMAP and the proposed REMAP.

2. I generally have at least 5 devices using IMAP (on Google Apps) at once, and interleave my interactions with these devices arbitrarily, yet expect each to show me the exact same state when I look at it. Keeping them all in the apparently same state is the sort of intractable software problem bedeviled with implementation details, and I agree throwing out IMAP and starting over with lessons learned could be easier than, say, the RFC linked below.

3. http://ajaxian.com/archives/json-vs-xml-the-debate - Seems this point is something like GIF vs JPG vs PNG, with a bit of "Markdown vs HTML" thrown in. Meanwhile, both XML and JSON are missing an important concept given labels/folders and conversations: multiple references to single objects.

4. Conversations or threads exist today as In-Reply-To: GUID and References: GUID headers, among others, but see the JSON problem above. We don't realize these headers are…

I think this is a super stealth thing, that still has a "but WeBC0mp0n3nts Fa!l3d!" vibe from the usual high-assumption/highly-self-certain camps, but in fact has this quiet underbelly of practitioners who have sat down & worked with it & found it be more than adequate, with a lot of advantage.

There's two social factors I want to comment on about this.

Its weird, the webdev world has lost... culture. We had a time when http://ajaxian.com and other sites kept us super socially aware of what was happening & everyone was sharing & no one knew. We were all watching, learning, together. But now Everyone Is A React Developer (EIARD) and there are normative in-reach-solutions & there's much fewer gathering places & communities to exchange views & possibilities across.

I also think there's an incredibly short-sighted long-dwelling view that anything that doesn't take over & dominate in 5 years is toast. Everyone wants standards to show up & immediately succeed, but actual adoptions is incredibly laborious & slow, and that's just something we have never ever learned. We looked at the colossal growth of startups across the 2010's & let their success determine how much we believe in the techs they were using, and any tech that didn't have gangbusters success for launching billions dollar enterprises was ignored.

And to be fair, Web Components is both an amazing shift, but it's just a start. It has a huge growing-in period, which hopefully never really ends, unlike other…

I agree with this point for sure. Frameworks are great if you are going to leverage a lot of the libraries/modules. But often in practice you never do. So then you end up taking on the issues with using a large codebase. Which is that when you find a bug, it's very hard to trace through code to figure out what's going on.

You are investing in learning a specific library/framework rather than the low level details that are on average what you'll need more because in practice you don't get to use the same framework all the time if you switch companies or projects as they tend to have entirely different frameworks or even languages on the backend.

I like how Marcin Wichiary though in this ajaxian.com article: http://ajaxian.com/archives/web-ninja-interview-marcin-wichary-creator-of-google-pacman-logo-html5-slide-deck-and-more

He basically builds all his libraries from scratch for each project which he can do quickly because he knows what he's doing and can of course leverage his other code for reference. Each iteration simplifies what turns out to be bloated and creates a new code base more matched to the problem he's trying to solve.

Quote from Douglas Crockford (http://ajaxian.com/archives/book-review-%E2%80%9Cjavascript-the-good-parts%E2%80%9D-by-crockford):

When I was a young journeyman programmer, I would learn about every feature of the languages I was using, and I would attempt to use all of those features when I wrote. I suppose it was a way of showing off ...

Eventually I figured out that some of those features were more trouble than they were worth. Some of them were poorly specified, and so were more likely to cause portability problems. Some resulted in code that was difficult to read or modify. Some induced me to write in a manner that was too tricky and error-prone. And some of those features were design errors. Sometimes language designers make mistakes.

Most programming languages contain good parts and bad parts. I discovered that I could be a better programmer by using only the good parts and avoiding the bad parts. After all, how can you build something good out of bad parts?

You should consider using one of the toolkits, many of them have something akin to Dojo's storage http://ajaxian.com/archives/dojostorage-offline-access-and-permanent-client-side-storage . This buffers you from the implementation details and as newer browsers come along they are able to update the implementation to take advantage of newer browsers built in databases, while providing you with the same backwards compatible API. If you have not chosen one, I recommended you take a look at Dojo, if you are going to build a full on web app and jQuery if you have lighter requirements.

Side note: we are really starting to side track this thread, why don't you email me (in my profile) or add me to your contacts in Skype (if you use Skype) that way you can hit me up on any questions you have.

It's funny that one can make the opposite point. As I wrote a couple of years ago [1], we're getting to a point where many sites actually have obfuscated source, as there's much more attention paid to perfromance optimisations. View Source is becoming a thing of the past, at least as far as high-scale production sites go.

While you can still inspect the DOM and so on, but it's not as accessible if the source isn't there. So in fact, open source code on GitHub and so on is the best hope for learning and reusing, but that puts JavaScript in the same basket as every other language.

1. http://ajaxian.com/archives/the-end-of-days-for-view-source