Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Your App Is Not Better than an Open Protocol

andjosh.com

Post reply on HN
Print view View original

81–90 of 135 posts

Re: Your App Is Not Better than an Open Protocol

#81

Post by jackmaney »

amelius wrote: post #79
jackmaney wrote: post #73

Earlier quoted context omitted.

An interesting idea, but it would likely result in the creation of a crap ton of (what in effect would be) umbrella companies. "Google? No, I technically work for Search Ad Services by Google."

But think about it... Suddenly every company can have Search Ad Services as good as Google's. Also, if you don't like what company X is doing, you just need to find N qualified people, and you can start your own X.

That's assuming that Search Ad Services by Google will have--or will be allowed to have--clients other than Google. And that, of course, is the entire point: to split a company up into what are technically smaller companies that, in effect, are just part of the head company.

Re: Your App Is Not Better than an Open Protocol

#82

Post by rhino369 »

pixl97 wrote: post #46
astazangasta wrote: post #44

Earlier quoted context omitted.

Nonsense. Why does Apple have their own plug format instead of supporting USB? Is it somehow better? Easier? Blatantly not. This is just vendor lock in, the opposite of the fundamental ethic of the Internet.

> Is it somehow better? Apple's magsafe and lighting adapter plugs are far better than USB connectors. They are reversible and don't have tabs to break off on the device side.

I really hate to admit it, but I love the lighting adapter. Blows micro USB out of the water.

Re: Your App Is Not Better than an Open Protocol

#83

Post by vcarl »

jowiar wrote: post #76

I don't like the shot at Flipboard here. HTML was designed for marking up (hypertext) documents. It's a perfectly fine language for marking up documents. It's a terrible kludge for defining application user interfaces, as anyone who has ever built such an application can attest. What we're seeing now is a shift to JSON-over-HTTP from HTML-over-HTTP as the protocol of choice for connecting the internet, along with a w…

Not to mention that they open sourced their interface for rendering React on canvas, which is opens the door for more (smaller) companies to do the same. What they did is phenomenally friendly to the open source community.

Re: Your App Is Not Better than an Open Protocol

#84

Post by liotier »

BinaryIdiot wrote: post #32

This is far too naive. User Experience drives everything. If your open protocol is the best thing since sliced bread but it's too complicated for the audience who should be consuming it? It will die and an application with great user experience will take its place. While I love open protocols and will use them as much as possible, at the end of the day I'm still going to do whatever it is that provides my users with…

Lack of open protocol implies that client choices will be essentially limited to what the service provider offers. This is bad user experience.

Re: Your App Is Not Better than an Open Protocol

#85

Post by pjc50 »

amelius wrote: post #17
mangecoeur wrote: post #6

Perhaps a bit naive - these companies that start by embracing open standards then pull back from them are just pulling a classic bait-and-switch, with a bit of freeriding off open-source efforts thrown in. They bootstrap their user base and arrive to market quickly by using tools built by others. Then once they grow and gain market and mind share, they can start closing themselves off, walling the garden. And it's ju…

Here's an idea: there should be a maximum number N of employees a company can have. This enforces companies to think about the greater good, because if you're in a company that is split because of size, you might end up in a different company. Also, a maximum on the number of employees stimulates the "modularity" of the market: large conglomerates with internal markets will not be possible anymore. I'm not sure of al…

Coase, Ronald H. (1937). "The Nature of the Firm". Economica 4 (16): 386–405

http://www.sonoma.edu/users/e/eyler/426/coase1.pdf

Re: Your App Is Not Better than an Open Protocol

#86

Post by untog »

xyby wrote: post #18
archagon wrote: post #15

Earlier quoted context omitted.

You cannot build a 60fps scrolling list view with a DOM. Can't complain; their results do look gorgeous.

I would love to see a minimal example of a "dynamic scrolling list view with custom animations" that does not work smoothly on my old Nexus 4.

As someone who spends almost every day working on mobile web stuff, I promise you - doing anything involving custom animations on scroll is awful. Because you have to hook into the onScroll JS event and change properties on the fly, the effect is usually janky at best. Particularly on iOS < 8, because it didn't fire onScroll events regularly.

Re: Your App Is Not Better than an Open Protocol

#87

Post by pjc50 »

amelius wrote: post #80
rmc wrote: post #55

Earlier quoted context omitted.

Technology companies may be able to run with ~100 people. But how are you going to run a large hospital? The NHS in the UK employs more than a million people.

Every department could be run by a separate company. This also ensures quality at the department level. These companies could then be hired by the hospital itself.

You were that guy promoting the "NHS internal market", weren't you? This is basically what happened: individual hospitals run by trusts, services contracted in. GPs responsible for allocating budgets. It hasn't made much of a difference beyond increasing the number of administrative staff.

Re: Your App Is Not Better than an Open Protocol

#88

Post by untog »

Your app might be better than an open protocol if the open protocol doesn't do what you want it to. RSS is great, until you want to add a feature that RSS doesn't include. And let's face it, if you tie your business to standards ratified by standards bodies you're going to need funding for the next ten years or however long it takes them to ratify something.
Post reply on HN