jongdubois

When you see billboard advertisements for apps which themselves rely 100% on advertising for revenue, that's when you know it's a bubble.

It's as though ad-supported companies are advertising each other to keep the money flowing because they can't get any outside money.

I think that a lot of people are missing out. I also feel like a lot of genuinely exciting projects get drowned out by the noise created by well-funded mediocre projects.

There is a problem in society now whereby successful (sometimes well-deserving) people are helping their friends too much. I have seen really poor quality projects (with 0 growth) keep receiving funding year after year because the CEO was friends with the investor.

The marketing noise created by these mediocre projects prevents a lot of quality projects from reaching the awareness of consumers.

I often wish that all newly minted tech millionaires would just keep their money to themselves and go on a perpetual holiday to the Bahamas instead of using their money to pollute the market with poor quality projects/companies.

Funding isn't necessarily evil though, funding the wrong project is (even though it is unintentional).

I think that pulling the core out into a separate engine is definitely the right direction and it will be interesting to see what framework they come up with. It definitely needs a clean slate - The Famous/Angular stuff looked promising but it came across as a bit bulky.

From a development efficiency perspective, Famous is not as good as Angular or React. From a rendering perspective, it's not as good as three.js. It's not yet a leading tool. Jack of all trades, master of none. Maybe it will make more sense when VR platforms become mainstream.

Maybe if he tried to learn some of these other tools which he currently 'has no time for' - He would realize quickly that they pay for themselves in time saved. I guess it's probably more of a sentimental thing for him though.

Overall, JavaScript is a great language. I don't find the prototype-based approach to OOP any less intuitive than the class-based approach. I much prefer it in fact.

It just so happens that the prototype approach didn't catch on early enough. Developers are now just really set in their ways and are rather pretend that JavaScript is not a true OO language.

I feel that the addition of a 'class' concept to ES6 adds no value to the language itself, but I think it was probably a good decision anyway - Because JavaScript is more flexible and adaptable than the minds of most people - It might as well use that to its advantage.

Unlike the stubborn developers who refuse to learn about prototype inheritance, JavaScript is capable of change.

Some apps have lower profit margins than others. Also some companies need to be able to integrate with their realtime channels on the backend (E.g. for doing custom realtime analytics, integrating with third-party services, applying transformations/filtering to messages in realtime, capturing certain messages for storing in your database, launching various realtime-based background tasks, etc... You do lose a lot of flexibility by going with a service like Pusher. Though it is well designed and very convenient.)

It really depends on a lot of things such as how often users send messages on average and what kinds of messages (JSON or plain text?). The latest version of SocketCluster can handle 25000 concurrent users per CPU core each sending a JSON message every 6 seconds so the 50K number does match my own benchmarks if you assume that each user sends a JSON message every 12 seconds on average.

SocketCluster's API is similar to that of Pusher so it can be a good self-hosted alternative: http://socketcluster.io/ - It's also designed with scalability in mind. You do have to manage presence yourself though but that shouldn't be too difficult (You can keep track of user presence in your own database - That could actually be an advantage since you can go ahead and use that presence data easily on your back-end to do other stuff - Easy to integrate).

We're currently working with a couple of fast growing startups so it's getting traction (still early adopter stage though). We'll be announcing our native iOS client near the end of this week. (disclosure: I'm the main author)

Really great news. I guess io.js fulfilled its purpose of shifting control of Node.js away from Joyent and giving it the vitality it needs to remain a leading backend technology.

"It seems that perfection is attained, not when there is nothing more to add, but when there is nothing more to take away."

Great quote - It reminds me of the story of when Michelangelo unveiled the statue of David, someone asked him how he managed to create such a masterpiece and Michelangelo answered "It was simple, I just chipped away all the rock that wasn't David".

Maybe if you had started programming at an earlier age like I did (instead of playing hide and seek with your friends), your wrist bones would have evolved a natural keyboard-optimized curvature and you wouldn't need wrist braces...

You are lazy and weak.

I think there's no point trying to avoid memory leaks in older versions of IE. Circular references due to closures are too common and it's not worth messing with your code.

IE users are probably used to getting a horrible user experience anyway. I'm sure they can cope with a few browser freezes/crashes every once in a while - They know how to take a beating :p

I think that the idea that you can succeed without "knowing what you're doing" may be more common to Silicon Valley. From what I've seen, the startup environment in most other places is not so forgiving.

I think that from the recruiter's point of view, there is an argument for either side. I really think that the employee that has been with multiple companies is often more 'talented' overall but they are usually less loyal.

In software - It's highly desirable for an engineer to be adaptable - Changing companies is a good way to expose yourself to different environments/perspectives (and therefore become adaptable). It's hard to get the same range of experiences from a single company.

This is especially true if you want to become a technical manager/lead (or CTO/CIO) - You need to be exposed to different approaches so that you know what works and what doesn't. You need to have a clear picture of what constitutes a good engineering culture vs a bad one.