Web Development: A Crazy World - <AUTHOR> http://rubiken.com/blog/2013/02/11/web-dev-a-crazy-world.html <comment><USER4> I've found that a large subset of programmers share the same trait as a large subset of photographers: they become so obsessed with tools that they lose sight of the fact that the end product is what matters at the end of the day.

For example: there are many people who spend thousands on cameras and gear, and still take terrible photos. There are many developers who spend a lot of time keeping up with what they think is the latest trend, and yet they never finish any projects that get used.

Then you have the photographers who take great shots no matter what gear they use, and developers who write and ship great code and products using Java and other unsexy languages.

Can better tools help you be more productive? Absolutely. But if you spend all of your time worrying that you're not using the latest and great tools, you won't get much done, and you won't be satisfied with what you do get done. I have 15 cameras and unfinished projects in 10 languages that demonstrate that.

My advice? Sit back, pick technology a couple of steps behind the bleeding edge, and focus on results. Choosing Ember over Backbone isn't going to cause your project to fail; building the wrong thing or failing to finish, however, will.

<comment><USER5> Author of the original rant here, funny it became viral and translated to Chinese (and back to English) :)

The rant was made as a comment here: [http://www.zemanta.com/blog/i-bet-you- over-engineered-your-s...](http://www.zemanta.com/blog/i-bet-you-over- engineered-your-startup/#comment-685047168)

Picked up by a Tilo Mitra: <http://tilomitra.com/the-crazy-world-of-code/>

And as discussed here in HN before: <http://news.ycombinator.com/item?id=4226990>

The point of it was actually: it's impossible to always keep up anyway so take something you like or already good at and move with it otherwise you'll never get your project done. It's nice to learn new frameworks, and you should, but it's mandatory that by the time you pick up something there will be something else that is considered better / more popular.

(I'm not saying "use Java Applets / Flash / XML+XSLT" just because "you are already good at it", sometimes you must let go of what you know and adapt to change, just don't over-kill it by learning EVERY new technology as it comes out, taking 1 step back is always a good thing)

I think the spirit of it was a bit lost in translation so here is the original text:

> I agree, I can't keep up, I just finished learning backbone.js and now I've > found out on HN that it's old news, and I should use ember.js, cross that, > it has opinions, I should use Meteor, no, AngularJS, no, Tower.js (on > node.js), and for html templates I need handlebars, no mustache, wait, > DoT.js is better, hang on, why do I need an HTML parser inside the browser? > isn't that what the browser for? so no HTML templates? ok, DOM snippets, > fine, Web Components you say? W3C are in the game too? you mean write > REGULAR JavaScript like the Google guys? yuck, oh, I just should write it > with CofeeScript and it will look ok, not Coffee? Coco? LiveScript? DART? > GWT? ok, let me just go back to Ruby on Rails, oh it doesn't scale? Grails? > Groovy? Roo? too "Springy?" ok, what about node.js? doesn't scale either?? > but I can write client side, server side and mongodb side code in the same > language? (but does it have to be JavaScript?) ok, what about PHP, you say > it's not really thread safe? they lie?? ok, let me go back to server coding, > it's still Java right? no? Lisp? oh it's called Clojure? well, it has a > Bridge / protocol buffers / thrift implementation so we can be language > agnostic, so we can support our Haskell developers. Or just go with > Scala/Lift/Play it's the BEST framework (Foresquare use it, so it has to be > good). of course we won't do SOAP and will use only JSON RESTful services > cause it's only for banks and Walmart, and god forbid to use a SQL database > it will never scale I've had it, I'm going to outsource this project... they > will probably use a wordpress template and copy paste jQuery to get me the > same exact result without the headache and in <del>half</del>quarter the > price

p.s. it would have been a longer rant today, I have lot of new things to add to it, sadly things didn't get any better: Now I'm trying to choose between yeoman and brunch, coffeescript vs livescript vs typescript, LESS vs Sass vs Scss vs stylus, Haml vs Jasmine vs that weird language called HTML, testacular vs mocha, fixtures vs mocks, RequireJS vs CommonJS, with almonds or without, I started using underscore then figured out it's already "old school" and I need to actually use lo-dash. So I think I'm going to take your advice ;).

<comment><USER6> The absolute worst is SOA (the "enterprisey" buzzword for lots of small services) architectures in which _every service is written in a different language_!

"Oh, our payment processor is in Node, but our site's in Ruby. Our file caching layer is in Python with bits of C for high performance and our crypto stuff is in C++ with Boost and libcryptopp but it talks to a Java app that uses Cassandra..."

(Runs outside, sets self on fire, shoots self in head...)

<comment><USER7> What's wrong with that if every service is using the right tool for the job and provides a sane API? Maybe maintenance?

<comment><USER6> A few things:

(1) Code reuse, or lack thereof.

(2) Multiplication of surface area for things like security bugs... now you have five different stacks to keep track of security updates for instead of just one.

(3) Multiplication of deployment resources-- now you need multiple VMs, maybe multiple instances with different stacks to run them on, etc.

(4) Developers can't pinch-hit for each other unless they know every damn stack in the world.

(5) If you sell, God help whoever has to support that stuff in your new organization.

<comment><USER8> _(5) If you sell, God help whoever has to support that stuff in your new organization._

It would be interesting to know if an acquisition fell through because due diligence revealed something like this and the purchasing entity didn't want to deal with that mess or it conflicted with their culture.

<comment><USER9> Absolutely not - no it manager worth their salt will pass up the opportunity to say - well we can do it but we will need more cash - we have to hire a ruby team a node team a ...

:-)

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> While some might complain or worry, this is what makes this field so fascinating. A myriad of options, toolsets and methodologies means that it is alive, open and thriving.

Imagine is Adobe, Oracle or MS had won the Flash/Flex, Java or ActiveX battles, where would we have been today?

As much as I use Chrome (and love it), I can't help but admire the work done by Mozilla to rescue the Netscape codebase and mould it into Firefox. I think they deserve a lot of the accolades that enables this zany ecosystem to thrive.

<comment><USER11> > Imagine is Adobe, Oracle or MS had won the Flash/Flex, Java or ActiveX > battles, where would we have been today?

I don't know what 'would have been', but I know that we would not be where we are today (in a positive sense) without those companies and the many many technologies and products they have provided us with (even though some of them can only serve as bad examples).

<comment><USER10> I'm not bashing them as a whole, just some of their technology decisions. To be honest, I've always felt that MS gets a bad rap. As much as it was anti- competitive, bundling IE in Windows enabled users to download alternative browsers. Obviously, there are other ways to do it but I doubt many users would have gone down that road with higher technical obstacles.

As for Oracle, not much can redeem them. Flash had it's day, but I wish Adobe would let it die already.

<comment><USER11> > As for Oracle, not much can redeem them.

If anything. :)

> I wish Adobe would let it die already.

I know many here can't accept the truth that Flash had, has and will have its place on the Internet. There was a need for such a technology and there still is. I will be here for another 5-15 years or so, so we should make the best out of it instead of screaming 'DIE ALREADY'. But as always, there is plenty of room for improvements. :)

FYI: Adobe donated Flex to the ASF a while ago and the mailing list is already the most active on ASF. It is actively developed and people are quite motivated.

<comment><USER10> If it wasn't the security issue laden monstrosity that it is, I could see it living on.

But the facts are that the only real "secure" version is the PPAPI implementation in Chrome (which has it's own limitations), Adobe has dropped future development for embedded systems and that it is almost non-existent on mobile does not speak to the longevity that you predict.

Flex is cool, but it's dependency on Flash will be it's noose.

</comment></comment></comment></comment></comment><comment><USER12> I love how YouTube approached this: Choose the simplest and most stable tools and use those.

It's a great strategy for developers that want to ship. Otherwise one can easily be lured by the siren calls of new tech.

I've certainly fallen victim to this temptation, but I've found that as I let go of the new pretty things and focus more on using the old boring workhorses of the interwebs, I get a ton more done.

Plain vanilla seems boring - but it's bad-ass in web architecture. We forget that YouTube had plenty of competitors that were well ahead them before they dominated.

They kept things simple and solid and that allowed them to scale. It's certainly not the only reason they won, but I'd bet it's a huge part of it.

\---

For more on YouTube's stack, see: [http://highscalability.com/blog/2012/3/26/7-years-of- youtube...](http://highscalability.com/blog/2012/3/26/7-years-of-youtube- scalability-lessons-in-30-minutes.html)

</comment><comment><USER13> It blows my mind sometimes, looking at a web page made of mostly simple text and a few images, to view the source and see page after page after page of CSS and javascript just to make something that looks only slightly better than

[http://www.w3.org/History/19921103-hypertext/hypertext/WWW/T...](http://www.w3.org/History/19921103-hypertext/hypertext/WWW/TheProject.html)

<comment><USER14> "Slightly better" is a subjective assertion. Especially in the webdev world where the pace of design and functionality improvements tend to move so fast. Granted, you may display the same/similar information in a text-only page, such as your example. But you won't be engaging users much or creating a site that people will want to see & return to, which is where the money that is spent on webdev work generally comes from.

</comment></comment><comment><USER15> Wow. Fantastic piece.

This is precisely how I see the ecosystem too. If I've learned anything:

1\. Focus on _something_ —Rails, Python, Javascript, WordPress, something 2\. Learn to actually program — any language will do

<comment><USER16> Maybe this is a side effect of this current day and age being a specialist society? Everyone needs something to differentiate themselves from the crowd, and Javascript being such a recent growth in setting a "standard" with regards to frameworks and tools makes for a good incubator for specialists.

</comment></comment><comment><USER17> I'm far from an expert coder compared to most on here...but...what's the big deal? Once you've grokked server-side code and framework, is it really that hard to move from Rails to Sinatra or even to Django? Once you know databases, how hard is it to switch from SQLite to Postgres or to even Mongo? Same goes with Javascript frameworks.

Now, I'm referring to the scope of what a _web-developer_ needs to know to interface with these technologies...obviously, a database engineer is expected to dive deep and know all the quirks/limitations of NoSQL vs SQL.

Is the complaint that "Oh shit, I don't know if I can learn new syntax?" Or is it more, "The hiring market is segmented by too many technologies for me to claim to be an expert at?"

<comment><USER18> > "The hiring market is segmented by too many technologies for me to claim to > be an expert at?"

I think that's a concern to many new programmers (myself included) when looking at the pace these tools and frameworks are coming out and then maturing.

<comment> jmcdonald-ut As a computer science major this doesn't worry me at all. Learning the fundamentals, the theory, and the overall science leads me to believe we will be just fine on the market.

As an intern I use PHP on a day to day basis. At school classes have been fairly language agnostic, switching from C++, C#, Java, PHP, and others. I have classes that force you to do all your work in the terminal, and some that allow you to use powerful IDEs. Furthermore, I have classes that you rarely even touch a computer (Algorithms, which should be more aptly named Algorithms II since Algorithms & Data Structures is a pre-req).

In my experience, switching tools/languages/frameworks isn't as hindering as lacking core engineering skills.

</comment></comment></comment><comment><USER19> Learn technologies that are popular, such as jQuery. The community will help make this easy. You will use jQuery on almost every project, so this will be time well spent.

Master components that are core, such as JavaScript. You will use JavaScript on every project. A true understanding will be essential to everything you choose to do with it. It amazes me how many developers do web development without ever trying to learn how to write effective JavaScript.

Lastly, do something just for fun. Programming is fun, enjoy it once in a while. Try a new language you will probably never use. Use a new framework or library. Look into something old. It is amazing how many old things are new again.

Do all this and the web won't be such a scary place.

</comment><comment><USER20> Quite amusing and very true. Just had a little look at Handlebars - writing 3 to 4 times as much to generate very little.

Also reminds me of this tongue in cheek site : <http://html9responsiveboilerstrapjs.com/>

<comment><USER21> Heh... [https://github.com/impressivewebs/HTML9-Responsive- Boilerstr...](https://github.com/impressivewebs/HTML9-Responsive-Boilerstrap- js/issues)

</comment></comment><comment><USER22> I think its so great that we have so many new toys and such innovation going on in the world of the web. I remember when I was first starting out as a developer (when I was 10, it was 1996, I wasn't very good) all we had was HTML and CGI scripting. CSS was the new hotness that no one understood and PHP was just learning to crawl. Those two technologies were all there was and I don't remember other developers ever going nuts like an adoloscent girl at a Beatles concert over any of the stuff that was coming out then. It really is nuts how we push all this latest and greatest stuff only to abandon it next week. I remember just about a year or two ago the HN community was in absolute love (like 'The Notebook' style, forever and ever, everlasting love) with Rails - even more so than now. There were endless debates over its merits and its pitfalls and I watched as the people who took those debates the most personally agonized over every small bit of the development process while those who didn't really care as much just built stuff.

It really is great that these new toys are coming out but what I see as the real problem is that we lose sight over one particular piece of the bigger picture. We forget to ask ourselves "Does this solve my or my users' problem(s)"? Even when we do ask that question we then get caught up over minutia like the elegance of code and performing between two competing tools.

That stuff doesn't matter yet! What matters is that you grasp the concepts the tool promotes and can use it effectively. Beyond that there's usually not much difference in the "elegance" or performance of your code between two tools and it usually comes down to subjective views and how you work. Even if you do choose the "optimal" tools you're most likely fucking up some other part of your codebase anyway. None of us write perfect code. That's why refactoring is a thing.

Are you stuck when it comes time to choose handlebars or mustache? Can't decide between Ember and Backbone? Is Rails or Sinatra better? CodeIgniter or Laravel? Thinking of using Django over... uh... whatever the competitor to Django is? Then you've got your head stuck way too far up your ass and focusing on the wrong thing. I don't mean to offend with that crack - I too have had my head up my developer ass many times before and all it got me was a 'Hello World' page in a project that was stalled before it even started.

So my point is that using the new hotness is fun and challenging and it can do you a lot of good but the moment you stop developing and start _chasing_ the new hotness you've become kind of a tech groupie rather than a developer.

</comment><comment><USER23> The analysis paralysis on which tools to use really comes from lack of focus on which problems you wish to work on. Many people are either told what problem to work on (employees), or have an unclear focus (I just want a job, any job!).

Therefore, they feel they need to learn and use _every_ tool so that they can be prepared for "choosing the right tool for the job".

The solution is to focus on projects of your choosing. When it's clear that your problem is a nail, you can tackle it with any tool that can pound with force: hammer, mallet or shoe heel will all work; frozen cucumber will not. In other words, there are clear wrong choices - get rid of those and pick one of the right ones. The paralysis melts away once you have a problem around which to frame your analysis.

Another beautiful thing about web development: you can learn to use a hammer (let's say, Rails) and you can use that hammer to pound a million nails.

It's a fallacy to think that you have to learn everything, every methodology, so you can be prepared for some ambiguous future project, in hopes of solving some unforeseen problem.

This approach has another great side effect: you won't be easily side tracked by the new shiny thing that promises async evented dilly every few months. If it doesn't solve YOUR problem, move on.

</comment><comment><USER24> _Most_ of the 'mess' I see is the current state of Javascript frameworks, which are in the Cambrian explosion phase of things.

I'd just use Rails as a default for most things I do these days, and if it's not a good fit, evaluate other technology.

<comment><USER9> I was just about to post "Cambrian explosion" as an metaphor for the state of javascript libraries.

There are good reasons to get the HTML formatting off the server and into the client, so the new style JS is all going in the right direction. So another metaphor:

All these frameworks are trying to solve the right problem in the right direction - which one will win out eventually - who knows, but even if you hitch a ride on one that stops half way, you are half way closer to the right destination than if you wait.

<comment><USER25> What will be funny is when we move everything back to server-side once we don't have network latency/bandwidth issues.

<comment><USER9> Really? transmitting just the data and letting the client handle the display and interaction seems a much more natural split.

It alos makes my server software conceptually simpler - which is always nice

<comment><USER26> I agree. Separation of concerns is a very good design pattern. MVC server frameworks (like Rails and Django) have already separated out the concern of displaying data to the user with their template systems. its a very reasonable next step to just migrate the entire template system off the server and let the client do it.

This has gigantic performance increases for servers under heavy load, and it puts the display logic in a domain that is more naturally suited to dealing with it (JavaScript and the DOM instead of treating HTML as just a string).

The pattern also promotes the use of RESTful APIs for data access from the server, which has the wonderful bonus of allowing you to make your data publicly accessible for free if you want to.

<comment><USER24> Templates... ok - that's fairly convincing. I'm less convinced about keeping the model and controller client side, because they end up replicating stuff that still has to live on the server anyway, to some degree. That just seems to make things harrier than they were to begin with.

<comment><USER9> I think if you are trying to replicate the same functions you are right. But if I have, say, a User model then it is merely a conveniently name for two groupings of functions.

My client side user should know nothing about Dbase lookups or persona verification - just as server model should not care about displaying addresses. Overall I think getting the crap out of the server makes it much much easier to reason and architect

</comment></comment></comment></comment></comment></comment></comment><comment><USER27> Sounds like <http://en.wikipedia.org/wiki/Analysis_paralysis>

</comment><comment><USER28> Yes, this

The amount of 'meetoo.js' is amazing(ly bad)

Because of course everybody has to have "MVC responsive html5 cascading containers with chocolate covering"

Not to mention most of these are underdocumented, bug-ridden, too specific, etc

Need a js library? JQuery. period (and don't get me started with mootools, I need to ship, not swim around their docs figuring out how to do what in jquery is easy )

And focus on the backend, a competent backend development will eat your whatever.js "specialist" except for the most specific cases

<comment><USER29> > Need a js library? JQuery. period

Sure, if you love writing the same boiler plate code over and over again to make sure your dom is updated and your data is synced. JS frameworks _are_ solving a problem, whether or not people like that there are so many out there. We are in the early days, and of course there's going to be a lot of competition. A few will rise to the top and become standards. You know, there were quite a few competing JS libraries before JQuery became so popular..

<comment><USER28> What I mean is "don't use a jQuery competitor (or jQuery 'sized' tool) in place of jQuery"

Sure, if you need something else/more use it, still I've been burned by those "wonderful js frameworks" and I'll make sure to not use them unless needed and thoroughly evaluated.

<comment><USER29> Well, at some point, there will emerge the "jquery of js frameworks."

</comment></comment></comment></comment><comment><USER30> This piece first appeared as a comment on this page in ENGLISH in July 2012: [http://www.zemanta.com/blog/i-bet-you-over-engineered- your-s...](http://www.zemanta.com/blog/i-bet-you-over-engineered-your- startup/)

while the author claimed to have it translated from Chinese back to English, surprisingly almost exactly the same as the original English version. I guess English-Chinese-English translation has reached an amazing stage!

<comment><AUTHOR> OP here. I've updated my blog to credit eranation (author of the original English post) and relevant links. I was not aware of the existence of the original English post and thought that I should share it as lots of us suffers the same frustration.

 _I guess English-Chinese-English translation has reached an amazing stage!_

I would take it as a compliment as my 'unofficial English version' isn't too far off.

<comment><USER30> Yes, it is a compliment :) btw, if it is possible can you also show the link to the Chinese version?

</comment></comment></comment><comment><USER31> Call me a masochist, but I love the huge amount of selection, I love how passionate people are about their own solutions meaning they rapidly improve, and I love getting my hands dirty with pretty much anything I can get my hands on.

It's great having too many tools in your toolbox.

<comment><USER32> That last sentence conjured an image of a person trying to drag a giant toolbox with him everywhere for some reason :) I do tend to disagree with the sentiment though.

The initial time investment per tool is steep.

Also, the tools' values deteriorate rather rapidly. Languages/Frameworks will become less used over time as something new replaces them (generally), and even your specific skills with a language will get worse over time if you aren't using it.

</comment></comment><comment><USER33> Web Development is fine, it's the Javascript, and especially the frontend world that's the problem.

Why do we bother with a language that's inconcise, lacks so many common, useful functions (enumerals, strings, etc), and general doesn't do what we want it to do? In spite of fundamental problems, people try to address them with custom solutions. Those are inherently very PERSONAL solutions - <USER2> everyone wants to do it well and better - bound to raise discussion and competition at some point. That's what's happening. People are trying to fix something broken with their own, idealistic ideas.

There's nothing wrong with that, don't get me wrong, but I think we all know that we can do better on a more fundamental level.

<comment><USER29> I'm shocked nobody has pointed this out, but we "bother" with javascript because it runs in browsers, and browsers are ubiquitous. Why does everyone who has personal issues with Javascript or web development in general seem to forget that it has become popular because of the webs ubiquity and the promise of cross-platform development?

<comment><USER33> And that's exactly the problem. The promise has been there for _years_, it just never has been made up to. Sure, cross-platform development is cool, you can do that in Java. I can also do it in Ruby, Go, Rust, Clojure, Erlang or Haskell. And those solutions don't feel like a duct tape on a drainpipe.

It's still the same as it was 10 years ago, we can't wrap our head around a solution that works for all browsers, hence, we can't _just_ make the language concise, let alone change it fundamentally to solve the more actual problems of front end development. And then, if frameworks don't have to fix a language in their own way, we can get something real going. In any case, I just can't wrap my head around the discrepancy as to why-the-fuck-still.

<comment><USER29> I'm not sure I'm understanding. I develop web applications that run well on all major platforms and it's not nearly as hard to do as people make it out to be. And the difference between Javascript and Java, Ruby, Go, Rust, etc. is that it runs in an environment that literally everybody already has installed when they buy a computer - the web browser. No mucking around with installing the JVM, or downloading an application to install and keep up to date, etc... you just point your browser to say, Facebook.com or news.ycombinator.com and boom, you are served a nice, cross-platform application that never needs updating. Thus, the popularity of javascript and web technologies.

<comment><USER33> Ubiquitous does not imply concise across. Which is not the case.

</comment></comment></comment></comment></comment><comment><USER34> As with all technology choices, you've got to draw the line somewhere - <USER3> and risky, or old and proven, or somewhere in between.

What matters these days is probably how well you and your team already know the technology, how good the documentation is, community size/takeup, how quick the devs are to respond to issues, and how mature and stable the API is from release to release. How popular/old the technology is also counts for more if you're looking to hire people with experience in it.

MVC on the client is becoming more and more important, once you start slapping a lot of js on a page it can quickly become un-maintainable. We went with Backbone as Ember was changing too quickly in backwards-incompatible ways.

MVC on the server (Django/Rails/Express/whatever) still has a place - you want something serving restful data / html skeletons and mapping urls to responses. In my day job that's Spring MVC because that's what people here know and it ain't broke.

Frontend language choice: Learning JS seems to be the natural choice here. Things that compile to JS e.g. CoffeeScript or DART might also work for you; I don't have experience with them but I'd imagine debugging problems in the resulting js would be a pain until browsers support them natively.

<comment><USER35> I used to develop with JavaScript, and JavaScript with Backbone before we switched to ClojureScript.

Backbone helped me to better structured my code but I found it also brings its own problems. There is a quite a lot of boilerplate code and views composed of other views were for me hard to manage.

I also wrote some macros to use Backbone from Clojure but the mismatch between object/mutable and functional/immutable is too high.

Finally the approach from <http://clojurescriptone.com/> seems promising. It uses a simple yet flexible event dispatcher. Add that a templating engine and you are done.

Debugging ClojureScript within the browser is harder than normal JavaScript but it's easy nonetheless to find what generated JS functions corresponds to your ClojureScript code. If you compile in debug mode you can set a breakpoint as usual. Compiling ClojureScript adds a bit of overhead to the workflow but I compiled it continuously in the background via Emacs and forget about it, it just popups when an error occurs.

In general I found ClojureScript much cleaner than JavaScript and it's easier for me to write cleaner code with it when the data manipulation or the logic is not trivial.

<comment><USER34> Yeah, we had to write our own view nesting logic and allow this to be used within our dustjs templates.

Marionette (<https://github.com/marionettejs/backbone.marionette>) lets you do all of that stuff out of the box; I've not used it though so can't comment.

</comment></comment></comment><comment><USER36> I like many of the state of the art frameworks, especially backbone.js and I'm really thankful for how much impact they had on making complexity in web apps manageable. That said I absolutely agree with you regarding the fragmentation problem which seems more like a stack problem to me.

For me personally it looks like what the web desperately needs is a common ground for how widgets work and behave. Web Components look like what we will get and I really can't wait to see that happen: [https://dvcs.w3.org/hg/webcomponents/raw- file/tip/explainer/...](https://dvcs.w3.org/hg/webcomponents/raw- file/tip/explainer/index.html)

Here are some examples from Dart Web UI (web component polyfills for Dart) <http://www.dartlang.org/articles/dart-web-components/>

Also here is a great article about the web stack fragmentation that you might be interested in: [http://zef.me/4835/dart-web-fragmentation-vs-web- development...](http://zef.me/4835/dart-web-fragmentation-vs-web-development- fragmentation)

Exciting times, Thomas

</comment><comment><USER37> This has been my experience, too. But I think it's wrong to jump to the conclusion that because going too far and having to learn too much is a bad use of time that you should just stick to one or two things. This is black- and-white thinking and I think in this case, your response should be in the context of the problems you face and the career you are building.

We do need to move along with technologies if we want to stay relevant. But you need to know what's a fashion and what's worth adding to your skillset. After leaving University I mainly knew Java but I learnt PHP and JavaScript because I wanted a web development job; later on I felt that none of the cool startups were using PHP and all of its warts had become very apparent to me so I picked up Python which seemed a lot more elegant. (However this was more a case of fashion that gave me access to higher-impact and higher-salary jobs. My actual needs to code in a general-purpose language with nice libraries isn't a worthy goal in itself.)

Currently I am working entirely in Node.JS and I don't consider myself to be drinking the Kool Aid because it made more sense to stick to one programming language and I needed long-running processes. I do have to be careful to not add too many libraries, however. There is so much activity in the JavaScript world currently.

I say you should focus on your career and wherever you see that leading you. To a certain extent programming languages and libraries will come and go (they will coalesce on principles so this is worth paying attention to), but architecture remains the same, social structures and positions remain the same, and sales remains the same. Apply yourself where you can see the maximum potential for personal growth and personal growth that doesn't slip (as it will when you have spent 20 years programming using the library X and everybody else switches to Y.)

</comment><comment><USER38> I don't agree with this rant. Just becuase 50 libraries exist doesn't mean you have to be an expert in all of them or even use all of them.

I think it's great that so many frameworks are sprouting up, and once you've been around long enough, it shouldn't take more than a weekend to try one, see the benefits, and use it or learn from it and move on.

Since when is having more choice bad?

I've been out of web development for a number of years, and it is delightful to have all these options now. I am loving working with knockout.js and looking forward to trying ember next.

<comment><USER39> > Since when is having more choice bad?

[http://www.ted.com/talks/barry_schwartz_on_the_paradox_of_ch...](http://www.ted.com/talks/barry_schwartz_on_the_paradox_of_choice.html)

</comment></comment><comment><USER40> I agree and can see where OP is coming from. As a Chinese, I notice the difference in how we approach problems. Let me make an analogy:

Chinese and western dude learns guitar. The Chinese player will worry about the scales, the hammer on/off drills, chord drills, picking drills, and maybe practice a song and focus on technicalities; western dude would pick a guitar, learn a few chords to play a song, realise that to play more songs he/she must practice hammer ons, etc, but everything is so that he can play more songs. They have never had to worry about drills. It's a means to an end.

Web frameworks are just drills to choose from. Pick the one you need and move on. With experience, you'll be able to tell what is good and what is not.

Why worry about which framework is "best"? It doesn't matter. If WP template and jquery solves the problem then why is he even talking about Haskell?

<comment><USER41> I think you are generalizing the issue too much. also take a look at the comment of the original author of the post. he is not Chinese: <http://news.ycombinator.com/item?id=5206578>

<comment><AUTHOR> OP here. Thanks for the tip. I've updated my blog to credit eranation (author of the original English post) and relevant links.

</comment></comment></comment><comment><USER42> 1\. Go to Home Depot.

2\. Pick the tools you like. Get a good hammer, saw, adjustable square.

3\. Leave Home Depot and go get good with them.

4\. If something breaks or doesn't perform a task you need, go back to Home Depot to supplement your toolbox.

<comment><USER43> You forgot the laser-guided dado cutter, and the telescoping illuminated wet- dry vac with AM/FM radio.

<comment><USER42> Who can spend time in the shop without a nice ball game on the AM radio!

</comment></comment></comment><comment><USER44> Marco Arment gave a great talk at Webstock about how he uses PHP and MySQL because they're battle-tested and he knows them inside-out. I think many of us could use a dose of Marco's pragmatism. It's worked out _really_ well for him.

<comment><USER29> I sincerely hope nobody reads this anecdote and decides to use PHP and MySQL based on it.

</comment></comment><comment><USER45> The original post shows definitely one thing: decision making is an important skill.

Obviously every framework has its pros and cons. But always focussing on the cons and restlessy looking for even hotter solutions makes you more worry about technology choice than about your code. It makes you worry more about whether you did a sane technology choice than it makes you solve actual problems.

At the end of the day it is better to focus on one chosen technology and get the most out of it. If its cons matter, one will see soon enough and learn how to circumvent. This gives deeper understanding of the technologies and give tools to solve problems.

</comment><comment><USER46> Maybe part of the problem is that "design" has been forced to merge with "engineering."

That and everyone seems to want to discover a language or framework like it's an Indy band. "I was using _____ before it became popular." That credential and $5 gets your coffee at Starbucks.

Let's face it. If the high-paying gig comes along and, god-forbid, demands .net or PHP, you're not going to argue, you're going to quickly adapt and get it done right? That's because all these things solve basically the same problem and it's a problem that you're used to solving.

</comment><comment><USER47> Maybe this post is the original one: <http://tilomitra.com/the-crazy-world-of- code/>

<comment><AUTHOR> OP here. Added this link to my blog post. Thanks for the tip.

</comment></comment><comment><USER48> I hope that there aren't any actual web developers who think like that on a daily basis and that it's meant as humor. You don't need to use technology invented yesterday to write good software. Infact, most of the "blue chip" technology out there: Java, Python, Ruby, PHP, and the relevant frameworks used in those languaes (Spring, Django, Symfony, Rails, etc...) is being updated all the time.

Another advantage of not using the latest, hottest, tech, is that there will be several gigs of mailing list archives out on the net of people's past problems (also, stack overflow will be filled to the brim) with answers, to your common pitfalls.

Go with X.js + HipsterDB and you're gonna have a bad time when you run into a problem, because it's just so new that you're likely one of the first to run into it.

The article ended with "I just used wordpress and copy pasted some jquery" -- I approve.

The bottom line is getting shit done, not being a hipster.

</comment><comment><USER49> I like this because it demonstrates the complexity that can possibly be involved with some serious web development projects. Also, I think it is the skill/ability to make the decision between these tools and platforms and know that you only need some etc - is what separates the good educated developers from the rest.

</comment><comment><USER50> Yeah, lots of technologies out there.

Personally I consider learning a technology as an investment. And with my investments I prefer them to be low risk. That's why I only choose technologies which are definitely going to last a while. Sometimes it's hard to decide if a particular technology will persist. I usually look for support and endorsement of big players in the industry and sufficient user adoption.

Right now I am contemplating using angular.js. I think it would be low risk to learn since it will probably last a while because of Google's involvement and already wide usage.

Other safe options include Twitter Bootstrap, Node.js, Android and jQuery and ?

I would like to read a blog post about what Hacker News considers to be safe options to learn. Anyone interested in writing one?

</comment><comment><USER51> Adopting new technologies doesn't always mean you try to follow trends or be cool. There are plenty of reasons that new ways of doing things come up all the time(be more productive is one of them). You may start slowly, but with time it pays off. I mean teams that can evaluate new trends and see if they get any benefits or not...

I personally think "just ship the damn thing" is BS, I'm pro delivering often, but good quality of product/service starts in back-end, again I'm not saying it should be perfect, but it MUST be open for new changes and be ready to scale... no one wants to wake up and be impotent with number of users they have, if you don't expect to scale, why are you doing this in 1st place?

</comment><comment><USER52> As you can see, he hadn't heard of Python.

<comment><USER53> Which version of Python ? Django or Flask ? Django ORM or SQLAlchemy ?

<comment><USER54> There are only two practical choices right now, both for Python 2:

1) Django 2) Flask + SQLAlchemy

Not that much choice, is there?

<comment><USER52> With Django 1.5 (final just about to be released, hopefully within a week) supporting Python 3, you're not tied to Python 2.

There are other good options, too. Here's one, also conveniently Python 3 compatible:

(3) Pyramid with (a) SQLAlchemy; (b) ZODB; (c) something else—whatever you want!

I'm actually working on a Pyramid + traversal + ZODB project just at present. It's very instructive when once you have become used to URL routing and pattern matching (I've worked with Django hitherto).

</comment></comment></comment></comment><comment><USER55> I've been wanting to use one of the new JavaScript frameworks on a new project, after dabbling with backbone and getting lost very quickly trying to clean up zombie views/events. My latest project is a front end site to a JSON API, so I thought it was the perfect opportunity, but after discussing it with my client we both decided not to.

Because I know what I'm doing best in PHP. So the site is going to do REST queries, but on the backend. We still have the ability to use the API in other clients, and we could in the future use shinyFrameworkOf2013.js, but for now we're building something we know will work.

</comment><comment><USER56> Thats the reason why its more important to learn the fundamental ideas behind the frameworks and not just the syntactic sugar . A deep understanding of any one will help in easily picking up any of the newer ones.

</comment><comment><USER57> any human (or even nature) domain knowledge is enormously detailed rich, with countless sub-domains, methodologies and references beyond the scope of a single person. And thanks god for that.

</comment><comment><USER58> I think this is evidence that we're in a golden age of web development. It's the opposite of monoculture, and it's awesome.

</comment><comment><USER59> <http://zef.me/4235/pick-your-battles>

Pick technologies which are most suitable for the job, not the most "hyped" ones. Also don't forget that sometimes the latest technologies comes with innovation tax, you may be the first to solve some issues, because of the small ecosystem.

</comment><comment><USER60> Architecture is not as important if you're building an app that will scale slowly. But if you're betting on scalability to make money, then the story is very different.

Relevant: <http://www.youtube.com/watch?v=rV_GIGzXrvA>

</comment><comment><USER61> To quote Jamie Zawinski: "At the end of the day, ship the fucking thing! It's great to rewrite your code and make it cleaner and by the third time it'll actually be pretty. But that's not the point—you're not here to write code; you're here to ship products."

<comment><USER51> Yeah, I bet he'd say the same thing to his car service technician, just fix the f*king thing, use duck tape if needed...

</comment></comment><comment><USER11> Reminds me of this: [http://www.gamasutra.com/blogs/SteveFulton/20120926/178364/N...](http://www.gamasutra.com/blogs/SteveFulton/20120926/178364/Not_Flash_The_Still_Angsty_Zeitgeist_Of_HTML5_Technology_Burnout.php)

</comment><comment><USER62> Recently redid a WP site a neighbor had for his small business. Single page flat html using bootstrap. What fun that was! So refreshingly simple.

</comment><comment><USER63> Not only can you waste time over-analyzing the number of choices, you can waste time discussing the choices. Like this thread. Back to work!

</comment><comment><USER64> I tend to pick the environment/framework/library that has the functionality already written that I happen to need at the time.

</comment><comment><USER65> I would try explaining those concerns to a client to see just how silly and nonsensical they are.

</comment><comment><USER66> He left out Basic. Bill Gates is still using that one according to his Reddit AMA yesterday.

</comment><comment><USER67> Just choose the right tool for the job. Beside that, variety is a good thing, isn't it?

<comment><USER68> No, variety also means:

1) scattering of effort (each framework gets less total attention by fewer people),

2) duplication of effort (besides what is unique in each, tons of effort is spend in implementing mostly the same things),

3) Many half-finished frameworks

4) Worse documentation and less books/manuals/video tutorials (see 1, 2)

5) Less chances of getting an answer to a framework problem in forums/irc/SO (again: scattering of resources).

6) Less vibrant ecosystems around the framework (if each of 10 frameworks has 10% of the market, it's not as good a business to invest in making plugins as something that has 30-40%). Same for hosting offerings, support, etc.

So you want variety but not too much. 2-3 big players would be mighty fine. 10 players of equal size, not so much.

<comment><AUTHOR> Agree. The current war of numerous Javascript MVC frameworks reminds me of the situation of Python Web Framework a few years ago, the community was confused by so many choices to select from. In the end, nobody wins, even the ultimate winner Django lost the opportunity to become mainstream. In that sense, the merging of Rails and Merb seemed to be a wise and successful strategic move in hindsight.

<comment><USER26> Django is pretty mainstream. Its not as popular as Rails but its hardly a maverick.

I think the reason why Python never went all in on a single web framework is just because the Python community itself is much larger and more diverse than the Ruby community. Consequently there were alot more opinions and alot more people willing to develop those opinions into separate projects.

Maybe you're right that there are advantages to converging on a single framework, but I'm not so sure. Rails is omakase, so if there's some part of it you don't like its not really easy or a good idea to change it, and you don't have any other options in Ruby. Django is also omakase but if there's some part of Django that you really disagree with you can just move to web.py or flask or pyramid. these are all built on the common core of Python's wsgi module so these are just different opinions on how to accomplish the same task.

<comment><USER69> With Django in specific you can swap out a component. For example, if (like many people) you don't like the HTML template syntax, just swap it out for Jinja2 or Mako. In Django it is also usually easy to customize something minor by use of overrides (OOP).

<comment><USER70> This is also true of Rails. That's what the Gemfile is--a list of optional packages that you can swap out. (Almost) all of your configuration happens in that one file where you tell Rails what packages (gems) you want to use with your application.

</comment></comment></comment></comment></comment></comment><comment><USER71> qooxdoo solved all the problems of web development long ago in a single simple uniform complete way.

As long as you arent forced to use apologetic strap-on technologies, I see no reason to look elsewhere.

</comment><comment><USER72> W in Wordpress stands for web scale.

</comment><comment><USER73> Living in a bubble.

</comment><comment><USER74> fvckin A+ on this.

</comment><comment><USER75> how about copy a line?</comment>


Teaching, Playing, and Programming: Ten Years of Purely Functional Data Structures - <AUTHOR> http://okasaki.blogspot.com/2008/02/ten-years-of-purely-functional-data.html <comment><USER2> The book has excellent examples of amortization.

</comment><comment><USER3> Go - read the papers.</comment>


Trends for Social Networks, Messengers, and Digital Media - <AUTHOR> https://consumer.substack.com/p/state-of-social-2020 <comment> swagasaurus-rex No mention of ycombinator, the last bastion of high quality technical content.

What ever happened to slashdot.org?

<comment><USER2> > What ever happened to slashdot.org?

I asked myself the same thing not too long ago and ended up putting slashdot back into my RSS reader for a while. I was (sort of) surprised to see that basically everything in the "best of" HN RSS feed was also covered in the slashdot feed. They were almost identical for the few weeks I was subscribing to both, the same stories are covered...

<comment><USER3> I found that Slashdot reposts from HN and Reddit reposts from Slashdot.

the cycle is continuous.

You do have imgur which at one point was largely teamed up with reddit and was originally built for reddit in the early days. However reddit got unhappy that they were making money off reddit's user base so they quietly sank that ship.

Not sure where gfycat originated from but Digg was my first aggregator site before the makeover which I can only assume content came from HN too.</comment></comment></comment>


React-MD – React components built with Sass - <AUTHOR> https://react-md.mlaursen.com/ <comment><USER3> Even though I'm not completely satisfied with its state, I've recently picked Material UI over React Toolbox. Too bad React-MD wasn't around at the time because it seems like a fierce competitor at first glance.

Things I like about React MD over Material UI: * Fully tested * Separation of styles * Grid included

On a sidenote: the page's styling messes up during loading. It takes one second before it morphs into the actual state.

<comment><USER4> Have you run into any significant issues with the overhead of "bloat" that comes with inline styles? Injecting so many styles inline especially for complex list items might potentially have some performance issues despite having a virtual dom.

I have been considering refactoring my personal ui lib to use css for static styles with css modules while all themable/dynamic styles inline. Many might say the mixture gets increasingly complex scaling but I have not run into such an issue.

<comment><USER5> This is a very fair point. We've followed a similar approach to what you're considering, with styles living in a couple places:

\- Scss library of variables, mixins, and functions that can be imported in whole or piece-by-piece into components that can use them. Doesn't compile any CSS classes on its own.

\- A lean global "browser reset", uses some of the global style variables from the library.

\- A simple React component (we call it `Cell`) that is used absolutely everywhere. This component has its own .scss file which imports the global scss library, and is essentially a one-stop-shop for `functional` CSS for colors, dimensions, typography, elevations (drop shows and zindexes), scrolling, etc. React authors use it via props instead of writing class names. Eg `<Cell color='action-primary' elevation={2} fontFamily='header'>`. Heavily reusing this component is what most directly addresses the performance concerns you note.

\- While Cell is sufficient for composing most layout and aesthetics at all levels of the page, one-offs are often needed for fine detail work:

\--- Simple cases are handled directly where needed via inline styles (easy to read when everything is in one place). We don't do anything fancy here for authoring (no radium etc), just an inline style autoprefixer that runs through postcss loader via webpack.

\--- Per-component scss files for more complicated needs (unique animations, novel compositions, complex interactions, etc). The component scss imports the global scss library so all our standard theme/helpers/etc are available everywhere. The component scss outputs to unique hashed classnames via webpack, so there is no risk of class name collisions between components. This allows for very focused scss files with short, straightforward names.

A lot of this works very well - in particular the global scss library, the Cell component, and the ability to opt-in to more fine grained control per component. However, there is some duplication between the scss library and a few javascript utils we've made to help keep inline styles consistent. These issues are somewhat made up for by how transportable our style layer is - <USER2> we were to switch away from React, or start a new project on a different stack, having the style vars and class library defined in scss already would make it easy to simply drop in and get rolling.

<comment><USER4> Interesting insights, though I wish much of these practices to be viable outside of closed source.

-A Scss library for functionality rather than compiling definitely seems interesting as a halfway point between pure css or pure javascript.

-When I was using pure inline-styles I rarely ran into cases where I couldn't get away with using divs or other style-less elements. The downside was div soup and bloat when rendering large quantities of components that had resets.

-I would be very interested, if allowed, to see the design of your Cell component. Rather than a component itself I find it simpler to define certain highly reused styles in the global scope, such as grid layout. Styles like these generally don't need encapsulation and are highly reusable since they are mainly containers.

-

\--I must admit that prefixed inline-styles are atrocious to look at it definitely is enjoyable dealing with a component in roughly a single file. Big loss was targeting an n:child for styling

\--Since I don't write any production code I can get away with the web animation api or any resource still in early stages or have not been highly adopted yet. I generally have a prefix for the global css classes e.g. 'qp- grid' and my projects are hardly big enough to have naming collisions.

It is unfortunate mixing css and inline-styles make it quite difficult to apply to an open source lib but I am quite hopeful for a solution or practice to address the issues.

</comment></comment></comment></comment><comment><USER6> What I like about this library over Material UI is the complete separation of styling, I really don't like how styles are written and passed as an object in Material UI and the requirement of getting muiTheme() from context for most components is just maddening, especially painful during testing. But what I'd really like to see from a material ui library is one that uses ITCSS for styling, check out the grommet UI library which is just an amazing library to work with, and the ITCSS makes editing and customising components a breeze.

<comment><USER7> Check out the material-ui `next` branch. It uses JSS and is much easier to customize.

</comment></comment><comment><USER8> Nothing to do with this project per se, but I still do not understand the deal with material design on the web. I can understand the case for it's use in small screens and maybe falling back to it based on media queries makes sense but I'm yet to see a good looking website on a laptop using material design.

<comment><USER9> I tend to enjoy it, mostly because it's a good "baseline". The phrase "nobody ever got fired for choosing IBM" comes to mind.

It might not be the most beautiful, it might not be the most information- dense, it might not be something that an actual designer would want to implement everywhere, but it works consistently, and it works pretty well on all screen sizes and shapes and input types.

It's a set of guidelines to hold your hand in making something that's not terrible even if you have literally no design experience, and I think it's doing a great job in that.

But, I also really like the look of MD. The animations, the "inky" taps, the shadows, the movement. It looks nice to me, it helps give a sense of "where" parts of the app live, and it tends to be consistent enough that if I notice an app doing it, I can generally grasp the "where would I go for this" much faster than other designs.

</comment></comment><comment><USER9> One thing the author has pointed out on reddit was that many of the components have a property to wait to fire until the ink animation is done.

That looks like the cause of the delay and "sluggish" feeling some people are reporting. If you don't set that prop, it's very quick even on a nexus 4 which tends to be my baseline device for "web apps" right now.

Why you'd want to set that I'm not sure, but it's there.

</comment><comment><USER10> Did the author try to use the components from a low end phone? Generally it looks good but all the jumping, flashing and crashing do not signal version 1.0.0.

<comment><USER11> Totally. 64% of my users are on mobile. Can one really afford to ignore that crowd?

Of course, mobile web development is, as I tend to say, the IE6 of modern days. So many older devices, and we also need to more or less support all of them.

Graceful degradation is the key, yes, but React-MD doesn't even seem to cope well with high-end devices.

</comment></comment><comment><USER12> Perhaps the name could be re-thought? I expected something Markdown related.

</comment><comment><USER13> This is awesome! Any plans for TypeScript support?

<comment><USER14> Looks like that might happen: [https://github.com/mlaursen/react- md/issues/175](https://github.com/mlaursen/react-md/issues/175)

</comment></comment><comment><USER15> I would be curious to know how this compares to Material UI. Has anyone tried both?

</comment><comment><USER16> Somewhat relevant: It seems like Google is using [1] for some of their projects...

[1] [https://getmdl.io/showcase/index.html](https://getmdl.io/showcase/index.html)

<comment><USER17> Huh? This is a list of sites that use Material Design Light, which is not React-MD. Also, I don't Google even uses React.

</comment></comment><comment><USER18> Wow very pretty. I love material design.

</comment><comment><USER19> sweet, I have just yesterday implemented MaterialUI to my react app... I will change it asap :)

</comment><comment><USER20> Am I the only one who thinks Material Design and its derivatives is just plain ugly? If I see a website created with this style, I press Ctrl+W close to speed of light.

<comment><USER21> It probably makes sense in Google's own ecosystem of apps, but as an aesthetic style it seems to be intentionally bland and tasteless.

<comment><USER22> I think you can defend your use of the word 'bland' here but 'tasteless'? That seems a little overblown.

<comment><USER23> I mean, they they are synonyms after all ;)

<comment><USER22> Ah. I guess I was reading 'tasteless' as implying that you had to lack taste yourself to like it rather than 'this thing has no flavour in itself'. Hmmmmmm....

</comment></comment></comment></comment></comment><comment><USER24> what a slow, clumsy, and flickering website of a modern ui framework

</comment><comment><USER25> ~deleted~

<comment><USER9> Because even their CSS implementation will still be css-in-js, not to mention that this framework seems to be going in a slightly different direction than material-ui.

Not everything can be done in a PR. I doubt the callmeall people would enjoy someone switching them to SASS, or rewriting some of their components entirely to work with a keyboard easier, or any other major changes.

And what is "half baked" about this? Besides being newer, it doesn't look any worse to me at first glance.

</comment></comment><comment><USER26> MD is not a clean UI....

<comment><USER27> What's a clean UI ? Gcloud admin implements material design, it looks clean to me.</comment></comment>


Steve Jobs is a Ninja and Carries Throwing Stars - <AUTHOR> http://www.fastcompany.com/1688850/steve-jobs-carries-ninja-throwing-stars

<comment><USER2> This is an interesting article, which doesn't explain the answer to a basic question: why does Japan care about personal near-field weapons for passengers in private jets?

It's hard to understand the use cases where these are any sort of a danger to society compared to just ownership of the jet.

<comment><USER3> "This is an interesting article"

It is? I'm not a good hacker, but this one didn't gratify my intellectual curiosity at all.

<comment><USER4> Apparently _you_ don't carry throwing stars when you travel..

;)

</comment></comment></comment><comment><USER5> "Steve, I'd like to complain about the piss-poor reception I get on my iP-"

 _there is a flash of movement, a pause, and my torso slides gracefully off my waist, splatting to the floor_

</comment><comment><USER6> A gift for his friend Larry Ellison?

[http://www.pcworld.com/article/179353/ellison_the_last_samur...](http://www.pcworld.com/article/179353/ellison_the_last_samurai_in_woodside.html)

</comment><comment><USER7> I think Steve Jobs is our current hypnotoad: [http://www.mostlymaths.net/2010/02/all-hail-steve-jobs- and-h...](http://www.mostlymaths.net/2010/02/all-hail-steve-jobs-and-his- ipad.html)

</comment><comment><USER8> Yes, but we knew that, right?

</comment><comment><USER9> If you mean an MS DOS-programming Ninja, and then, yes he once was a Ninja. Then he was a Grandmaster in Windows. Now he is somewhat of a red belt in Philanthropy (see him make progress here <http://twitter.com/BillGates> ) with a blue belt in watching his former company make horrific mistakes. But MS is not dead yet, and he isn't either. Maybe he will get bored and take it over again one day.

<comment><USER10> I hate to break it to you, but Steve Jobs and Bill Gates are likely two separate people.

<comment><USER11> Have you considered the possibility that Steve Jobs is such a good ninja that he can also appear to be a man we all know as Bill Gates?

<comment><USER12> I'm always amused that people on such an ostensibly geeky site have such intense hatred for lame, geeky kinds of humor. I kind of like it, though.</comment></comment></comment></comment>


Larry Ellison starts to reign over Sun - <AUTHOR> http://www.guardian.co.uk/technology/blog/2010/may/13/ellison-oracle-sun

<comment><USER2> OK, but where does this "cloud" come from? Space? Nope, it's real physical kit in a datacentre somewhere, bought by someone, operated by someone, sold by someone. Think aviation industry. Does the fact that an airline leases its planes from a holding company mean that any less planes get made?

</comment><comment><USER3> i just do not like that guy</comment>


Japanese toilet can save penalty kicks - <AUTHOR> http://www.theregister.co.uk/2012/10/30/sgtk_japan_toto_toilet_football/ <comment><USER2> Ah, future... you promised us the flying car, and what did you give us instead???

<comment><USER3> The sweet irony of this is that the Japanese will have flying toilets before the U.S.A. has flying cars.

<comment><AUTHOR> True that ! Here's another one! [http://www.slashgear.com/chat-perf-accessory- makes-your-ipho...](http://www.slashgear.com/chat-perf-accessory-makes-your- iphone-smell-good-17252408/) LOL !</comment></comment></comment>


Government shutdown: TLS certificates not renewed, many websites are down - <AUTHOR> https://www.zdnet.com/article/government-shutdown-tls-certificates-not-renewed-many-websites-are-down/ <comment><USER2> From reddit:

> This article is overly hyperbolic. Some obscure subdomains of government > websites are serving expired x509 certificates. They're not down and this > definitely doesn't compromise the encryption that protects any login > credentials. Anyway, it is embarassing to see certificate renewal is not > automated - it's something any good sysadmin would have set up.

[https://www.reddit.com/r/technology/comments/aeps41/governme...](https://www.reddit.com/r/technology/comments/aeps41/government_shutdown_tls_certificates_not_renewed/)

<comment><USER3> Nothing to do with SSL, but a fair amount of US government websites are hard down, on purpose, due to the funding dilemma.

Like: [https://www.data.gov](https://www.data.gov)

 _" Due to a lapse in government funding all Data.gov websites will be unavailable until further notice."_

Which is pretty odd, because putting up these blocker pages probably costs more than just letting the sites run unattended.

<comment><USER4> Government departments are legally required to budget for the possibility of a shutdown, which means they have to keep the money around that they will use to shut down.

[https://en.wikipedia.org/wiki/Antideficiency_Act](https://en.wikipedia.org/wiki/Antideficiency_Act)

<comment><USER5> Yes, but this coupled with the fact they shut down things that don't otherwise really require a human to actively working proves that it's all just a political ploy.

<comment><USER6> > _.. proves that it 's all just a political ploy._

Security maintenance, keeping databases up, monitoring the various systems, risk of DDoS, answering to users' inquires, bandwidth... - it requires real money to keep any production site live.

Given that these folks are basically working without pay, I don't blame them for wanting to put a cover page saying "Sorry, we're down", and call it a day.

<comment><USER7> Many are not legally allowed to work for free or be ask people to work (I forget which). The range of people allowed to work (even for free) is pretty limited to dealing with loss of life or property.

</comment></comment></comment></comment></comment></comment><comment><USER8> Serious question for US members of HN: how do you _tolerate_ these shutdowns?

I mean, apart from the loss of services, including websites, it seems like many federal workers aren't being paid. Will they be paid back after the shutdown impasse is resolved or is the money they didn't/couldn't earn lost to them. This seems unfair and, in the meantime, how are they supposed to go about their lives?

Overall it seems potentially damaging and disruptive for any organisation or individuals with dependencies on the government.

The reason I ask is I've been turning over what it might look like if a similar situation occurred in the UK, where it'a difficult to envisage a scenario that doesn't end with rioting in the streets.

<comment><USER9> Because most of the government is a waste of money and exists merely to perpetuate itself. The fact that it just shuts down sometimes is a great indicator of just that. It's an entity that is accountable to nobody because no matter how well or poorly it performs it just collects revenue anyway. You can't #deletegovt. The sooner people move away from viewing it as a good employer, the better. There's no smooth or elegant way to make this happen, unfortunately.

<comment><USER10> Instead of downvoting the parent, make an actual argument instead. You'll find it difficult. If the current shutdown proves anything, it's that many functions of the federal government are un-essential to daily life. Those un- essential parts should be eliminated.

<comment><USER11> For most people this argument doesn't follow because they don't see elimination of government as a terminal goal. We believe the government does a lot of useful but un-essential functions, like operate federal parks.

The other thing is the vast majority of the government's budget is Medicare, DoD, and social security which are all still operating to my knowledge.

<comment><USER12> The two arguments do not necessarily need to be mutually exclusive. You can have governance without monopoly. This would be the ideal scenario.

Governments operate federal parks, but there are also private parks which are just as well kept, sometimes even better - and they do it at much lower costs. See for example, this small public bathroom which cost $2M to build: [https://twitter.com/JohnStossel/status/1077921975123804162](https://twitter.com/JohnStossel/status/1077921975123804162)

Such enormous waste of resources is so common in many areas of government, and if they operated like any regular business they would be bankrupt overnight. Of course it did not take $2M to build that little shack - there is a huge amount of corruption and everyone involved is taking their slice of the taxpayer's money.

<comment><USER11> I think it really did take 2 million dollars. The video explains why. We have decided to make a lot of trade offs when doing government infrastructure work that makes it really expensive. But this isn't government in general, it's American government specifically that is really inefficient at building things.

In Texas I've been to over ten government run parks (like ones you'd go camping in), and I've never even heard of a private one.

<comment><USER12> If given the option for a $2M toilet where "the locals are engaged", and takes 4 years to build, or a $300k toilet which is built in 6 months, which do you think most people would opt for?

The real problem is government is _too damn big_ that it becomes impossible to separate out such concerns from every other aspect of government, and each time government expands, it adds more inefficiencies.

A park should be a self-contained enterprise so that it doesn't _need_ outside government spending. If you take for example, Shinjuku Gyoen in Tokyo, you need to pay 100 yen to enter the park. The park gets millions of visitors a year, and the money it takes can easily pay for the upkeep of the park. It could be completely private, but in this particular case it is inherited from the imperial estate and is run by the government. The fee has the additional advantage that it keeps out vandals and thugs - only people who want to enjoy the park will pay for it.

Highways in Japan are mostly toll roads too. They're operated as companies with the intent on making profit. Some are privately owned, although most are government owned. The "who will build the roads?" complaint is one of the most common attempts to retort the argument for small government.

<comment><USER11> > If given the option for a $2M toilet where "the locals are engaged", and > takes 4 years to build, or a $300k toilet which is built in 6 months, which > do you think most people would opt for?

You and I both know this is not the cause of a 86% of expenditures.

> The real problem is government is too damn big that it becomes impossible to > separate out such concerns from every other aspect of government, and each > time government expands, it adds more inefficiencies.

Do you mean too damn big by % of gdp? If so we could double the size of social security and not change the costs of infrastructure.

Do you mean too damn big by employment? If so during census years infrastructure costs don't change much.

If you mean by number of regulations? I think reducing regulations could definitely decrease the cost of infrastructure, but this isn't what most people mean when they talk about the size of government. Texas is a very conservative state with little welfare, not very many services provided by the government, but we have an enormous amount of regulations. An incredible amount of red tape and laws.

<comment><USER12> > You and I both know this is not the cause of a 86% of expenditures.

This is missing my point. The point is that if it were a private development, then they would be sacked and replaced. This isn't some isolated case and many areas of government are similarly ineffective. The problem is that you can't just replace the one area - the government isn't modular enough to fix its individual parts - it's a monolith.

When I say the government is too big - it's trying to do too many things, and does most of them badly. Markets are better at selecting for efficiency than a single centralized entity. Each 'ministry' or whatnot should be a distinct entity, and should operate like a for-profit business. If one ministry is performing poorly, it could be replaced with a different company in a free market. The threat that they could lose such a contract would force them to perform. No performance, no job - like the rest of us.

To be clear, I'm not for "no government," but for very limited government and little regulation. Governments should not be interfering in markets for instance. Things like environmental regulations are obviously more complex issues which require people to come together for solutions rather than competing.

Another example of a more free market is the education system in Sweden. Instead of funding people to go to the nearest public school to them, they give vouchers for education which are redeemable at any school, private or public, and children can choose. There are no restrictions on location. Because private schooling is almost always better than public schooling, this system has caused the public schools to improve out of necessity - they're competing for children to get the funding - in turn the private schools need to innovate to retain their edge. The result is an overall improvement of the entire education of the country, and reduced government spending.

<comment><USER11> > When I say the government is too big - it's trying to do too many things, > and does most of them badly. Markets are better at selecting for efficiency > than a single centralized entity. Each 'ministry' or whatnot should be a > distinct entity, and should operate like a for-profit business. If one > ministry is performing poorly, it could be replaced with a different company > in a free market. The threat that they could lose such a contract would > force them to perform. No performance, no job - like the rest of us.

This is just passing the buck. Right now the government bid out the creation of a bathroom and it was done expensively. But you are arguing that if the government bid out the entire parks system it would be done really well? I don't follow the logic. In my experience the more complex the RFP the more the sophisticated parties(the bidders) are going to fuck the unsophisticated party(the government). It's easy to specify what a bathroom should be and take the lowest bid. It's way harder to do that with the park's department.

And not everyone thinks the Swedish model is a success. Lots of people blamed them for causing Sweden to have some of the fastest dropping test scores in the world. And I'm not arguing privatization is always a failure. I'm just arguing that it's not always a success, and that it's success and failure is dependent upon how it's done. I'm not sure why you are so privatization is always a success every time when clearly the historical record says it's a mix of successes and failures.

You argue the government should be smaller. 5/6ths of the government is insurance(medicare/medicaid/social security)+military and then 1/6th is everything else. That includes education, protecting the environment, funding research, parks etc..

I would love the government to be smaller, I don't think we need to spend so much on the military but I do like social security, medicare, and medicaid. I don't want to be in the position where I have to decide between mortgaging my house or letting an elderly relative die of cancer. And it's really nice we don't have to make those decisions.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER13> They should have used Lets Encrypt. TLS certificate renewal should be completely automated. No excuse.

</comment><comment><USER14> It's been interesting reading the public info posted for furloughed employees. For example, I didn't know that Equifax has a workforce management division and that they manage parts of NASA's workforce.

</comment><comment><USER15> My bet what will trigger the next recession proper was on Brexit, but 45 is beating the Brits to it. Not shabby for a temper tantrum.

This week I read up on Reagan's firing of 11000 flight controllers because the union that formerly supported him demanded better working conditions. It took a decade for air traffic control to regain the old levels.

<comment><USER16> Trump is asking for less than 1/1000 of our annual budget for border security. We spend 10x that on foreign aid annually. This entire thing is political BS over what amounts to a rounding error while congress almost unanimously approved $38 billion in money for Israel

<comment><USER17> Maybe we can stop being obtuse? The senate can end this by passing a budget and override the president's veto. They're choosing not to.

<comment><USER5> This is the part that people so easily forget. The power is truley in Congress' hands. That said, appropriations bills must originate in the House and the new speaker and flock of freshman Representatives haven't passed anything yet.

<comment><USER18> Why would the House waste time passing bills that aren't going to have a veto proof majority? Congress generally waits until they're close to having the votes before going through the process.

<comment><USER19> The Senate passed the House bill before the winter recess. Trump threw his tantrum, though...

</comment></comment></comment></comment></comment></comment><comment><USER20> I am afraid this is the beggining of the collapse of Us standard of living. Developer with 20 years of experience from greece and PhD. Working for goverment for 6 dollars per hour.

</comment><comment><USER21> Nasa.gov[1] and justice.gov[2] resolving and have valid TLS certificates for me.

> In the end, nothing good will come out of this shutdown.

Some people believe increasing border security and funding to reduce crime, reduce sex trafficking, and better protect border agents and law enforcement as good.

      [1] https://www.ssllabs.com/ssltest/analyze.html?d=nasa.gov&latest
      [2] http://ssllabs.com/ssltest/analyze.html?d=justice.gov&latest

<comment><USER22> There's been little disagreement about the broader idea of "increasing border security". Poll I saw the other day showed (IIRC) something like 80%+ of polled people saw a need for 'increased border security'. The phrase is incredibly broad. What is in dispute is what to spend money on, but I suspect you already know that.</comment></comment>


Nutrition/Fitness trackers – no clear winner. Partner up - <AUTHOR> http://blog.halfmoon.ws/on-tracking

<comment><AUTHOR> Jawbone UP has had me wake up earlier in the morning pretty well in the past few week though. I've gotta give them that.</comment>


Ask HN: How to split equity? - <AUTHOR>

I am about to ship my second app and I'd like to bring in a good friend of mine who I believe can contribute a lot in many areas that need to be covered in order to build a succesful app company. How do I go about forming a mutual agreement as to how to split equity?
To explain what I've done so far:
- Developed and shipped first app.
- first app has a few thousand downloads and growing.
- put up investment for the development of second app (validated market with customers, great potential).
- invested my time for 3 months almost full time (taking care of metrics, marketing, managing developer/designer etc.)
Any more info that is needed please ask. All comments or helpful links are appreciated. <comment><USER2> People who are doing this for the first time care a lot about the numerical split but people who do this professionally care a heck of a lot more about vesting. Whatever you choose, your outcome will be a lot better with a defined vesting schedule. The standard one in the Valley is (for both of you!) "four year vesting with a one year cliff", which means that 25% of the eventual grant is durably yours on the 366th day and then 75% gets parceled out in equal increments every month for the next 36 months after that.

I'd be inclined to have the company write you an IOU for your _cash_ contributions so far, and split it 50/50, perhaps with one of you getting a tie-breaking share. The company can dispose of your IOU like any other short- term debt of the company at some point in the future when it has the financial wherewithal to do so. [See below about IOUs.] Your vesting clock starts 3 months ago, your partner's starts as of the day when he becomes full-time.

I cannot emphasize enough that your equity split is not _nearly_ as important as "Does bringing this guy on uniquely make this business successful and do I have confidence that we will both be happy with this arrangement 5 years from now?"

Edit to add: As I get older and wiser, I am coming to appreciate the discipline of separating one's personal and business finances and explicitly receiving written acknowledgment for transfers of money into one's company. These feel like moving money from one pocket to another in the early days, but they _are not_ , and explicit written confirmation of that fact will make your life easier in a lot of futures.

For example, I know one entrepreneur who, like many, tightened his belt, ran up substantial personal debt, and put blood sweat and tears into building a company. Professional money came into the company. Without documentation that he had loaned the company money, the best resolution would have been asking the other stakeholders to approve increasing his salary so that he could cover his "personal" debts. Had that documentation existed, he would have had ample authority to extinguish that debt in the ordinary course of business, and it would have likely had favorable personal tax consequences.

<comment><USER3> Are you sure that 1-year cliff is a good idea for founders? A lot can happen in a year, and founder disputes are A Thing; and it sucks for the person with 49.9% to be in a position where any unresolvable disagreement in the first year means he walks away with nothing.

<comment><USER2> I agree with you that a lot of founders have catastrophic breakups in the first six months. In most cases, this kills the company, and good riddance. In the cases where it doesn't kill the company, the cliff minimizes years of painful conversations of the general flavor "Hello, 10th engineer. We are happy to offer you 0.2% of the company, which you'll earn over four years with us. This grant represents 1/250th of what someone who worked with us for two months once earned." or "Hello, potential acquirer. That certainly sounds like a very fair offer. Unfortunately, I'll need to run it by someone who I haven't spoken with in 5 years who you'll be writing a check for several tens of millions to."

Cliffs are, of course, negotiable. If someone suggested one to me with regards to my business, I'd accept it contingent on the clock starting at either launch or incorporation, either of which would result in the cliff being moot.

</comment></comment></comment><comment><USER4> My first advice would be that this friend has to put money into the company. You need him to show commitment. It doesn't have to be a lot, maybe just $ 10,000. If he refuses to put any money into the company, you have an employee, not a partner.

Trust me on this one, you want to test risk tolerance as soon as possible.

Second question, will he work full time? If he doesn't work full time, you should give him very little equity, or just relative to the amount he invested in the company with maybe a little extra relative to the value he brings.

If he doesn't want to work full time and doesn't want to put money, just pay him by the hour. Pay him by the hour can also be a way to start the business relationship and build trust.

Third question, how much can you pay him if he works full time? For example, if he works full time but you can only pay him $ 50,000 instead of $ 100,000 the first year (assuming $ 100,000 is what he could get), he's putting $ 50,000 into the company.

Now, the last part: value your company. The best indicator is profit, when you reach it and how long you hope to sustain it (for ever, possibly). There are many tools and formulas, your accountant can probably help you. Because you have an accountant right? And a business plan, right? ;)

Another approach is that if he puts a decent amount of money (enough to give several months of runway) into the company and works full time for a well below market salary you can give him 49% (or 50%, up to you).

</comment><comment><USER5> Joel's Canonical Guide

[http://www.businessinsider.com/how-to-allocate-ownership- fai...](http://www.businessinsider.com/how-to-allocate-ownership-fairly-when- forming-a-new-software-startup-2011-4)

</comment><comment><USER6> Google "Startup Lawyer If I launched a startup 2014", which sums up most legal questions including equity splits. Founders Dilemma by Wasserman covers the topic from a scientific research point of view.

tl;dr as far as I remember from that book: Make sure it is fair, and enough equity for both to be motivated. You have to discuss with each other to find out. It can be everything between 95/5 to 50/50\. If you value the friendship more than you value the company, you should go for 50/50\. Otherwise 50/50 is not a good option according to Wasserman's research.

<comment><USER7> 5% would be absurdly predatory for essentially a cofounder. (If they're building the company from the ground up rather than merely shaping it, then they're a cofounder.)

<comment><USER6> I agree. With 95/5 you're more like a first employee. My guess is that more popular splits are 50/50, 40/60, 70/30, 80/20\. In that order.

</comment></comment></comment><comment><USER8> Ask her what, in her mind, is fair. If she says "we should do 50% 50%" and she won't give you the credit for starting the venture, you should think twice if you want to establish the partnership with this person. If she says "you did most of the work. 20% is fair" you should do 50/50 with IOUs and vesting.*

*Partners are working full time on this.

Here is a good summary of how to pick a cofounder [http://venturehacks.com/articles/pick- cofounder](http://venturehacks.com/articles/pick-cofounder)

</comment><comment><USER9> Find someone who you believe to be your equal (strength of skills he/she brings, intelligence, future potential) and treat them as your equal (50/50, same vesting schedule) -- you remain CEO. If you don't believe they are your equal, then find a way to hire them (as an employee, contractor, whatever) instead. Most other strategies are recipes for resentment in the long-term. As others have said, weathering the first 4 months will be nothing like what it takes to deliver a success story in 4 years.

</comment><comment><USER10> _I 'd like to bring in a good friend of mine who I believe can contribute_

This is the key sentence. Work together for a month, with no equity. See how much this potential co-founder actually accomplishes. You'd be amazed by the gap between what you dream may happen and what actually happens. Success is hard.

If after a month, you are still super-excited about this co-founder, start discussing an equity split. Always with vesting. No cliff (or very short, that was what the 1-month trial period was for).

If a co-founder doesn't receive a salary, then the minimum equity split would be 90/10, all the way to 50/50\. FYI, at 90/10 I would behave like a super- adviser, but not a fully committed co-founder. 75/25 is the first "true co- founder" deal I can think of.

<comment><USER11> "No cliff" is wishful thinking. Everyone has had the experience of hiring someone who ended up not working out. It almost always takes more than a month to come to that conclusion, and a little longer still to act on it. And finding a viable cofounder is harder than hiring.

Having someone who worked for you for _a couple months_ walk away with tens of basis points of ownership is a pathological situation, not something you should deliberately optimize for.

</comment></comment><comment><USER12> Funny you ask this here. In 2012, 1 in 4 Y combinator starts up broke apart due to founder disagreement. You can bet a large part of that was due to equity distribution issues. Equity issues can get really messy - and easily damage friendships.

Read the reviews for Slicing Pie. It's about maintaining a dynamic model that eventually vest into shares (if the company works out). I read it. It's great quick read. Ideal for your situation, I think. And it may preserve your friendship.

[http://www.amazon.com/Slicing-Pie-Company-Without-Funds- eboo...](http://www.amazon.com/Slicing-Pie-Company-Without-Funds- ebook/dp/B0096EFHBI)

</comment><comment><USER13> If I was in your potential business partner's position, I'd ask for 50/50 vested with a schedule of (say) 12 quarters, so every 3 months I'd get 4.1% of the company, with a cliff of 6 months to test whether the relationship will actually work (e.g., no equity transfer if the relationship breaks down in that time) That would recognise the work you've done already, but also appreciate that if the business lasts a long time the initial work will become less important. There's no good reason why you should have more equity than your business partner after a few years - by that point the risk each of you have taken is effectively the same.

</comment><comment><USER14> Here is some advice from 1996: don't have equal partners. Make sure someone can call the shots or else no one will call the shots: [http://yesatyale.org/wp- content/uploads/2014/06/lecture_06-1...](http://yesatyale.org/wp- content/uploads/2014/06/lecture_06-1.pdf)

 _EDIT_ This moves around so much I uploaded to Scribd: [http://www.scribd.com/doc/234962516/Entrepeneurial-Death- Tra...](http://www.scribd.com/doc/234962516/Entrepeneurial-Death-Traps)

</comment><comment><USER15> Do you plan on an LLC, an S-Corp or a C-Corp?

An LLC would require to define terms of ownership, decission and cashout in its charter beforehand. A Corp is much more flexible, especially if you do not know how much your "partner" will contribute in the future. So you might want to copy the unusual way Wizards of the Coast did: 1 share = 1 hour = $50

So you own already 600 shares, and your partner owns zero. If he invests money or time he earns share and dilutes you, if you invest money or time you earn shares and dilute him.

WotC shares later sold to $1400, iirc - so it was a good deal for the artists who painted those tiny pictures for magic the gathering.

PS: Peter Adkison later wrote that he had no clue how a normal Corp works, and did not consult a lawyer because he had no money for it, and just handwaved a way, that sounded fair to him, to pay the artists without having any money. It worked out, thats all that counts.

<comment><USER11> I don't think it's true that an LLC requires you to allocate equity statically at the time of formation. LLCs routinely issue equity to employees long after formation, and, to the best of my knowledge (I cofounded, co-managed, and eventually sold an LLC with several tens of employees), without modifying their charter.

No matter what your corp structure is, this is an issue you need to spend a few hundred dollars on an attorney on.

</comment></comment><comment><USER16> I wouldn't give any equity away in this case.

Why?

He has not done anything yet.

This sounds like you are afraid of sales/marketing/biz dev/something and you think he will solve your problems.

I warn you: he will not solve your problems, you will have more on your hands.

</comment><comment> Alex-Galapagos it all depends what is he contributing.. You said that you believe "he can contribute a lot in many areas that need to be covered in order to build a succesful app company", but what is it exactly? Who's coding the app? You've already done first app, if he's contributing to marketing of the first app then he can get less than 30% of profits from that app. If you've already built second one, the same thing. If he's building the second app with you and brings more skill you might consider splitting evenly just for the second app, you don't have to give away equity within the company, you can make an agreement to split profits just for the second app, since he can decide to leave.

</comment><comment><USER17> My experience is it should always be evenly distributed at such an early stage (3 months is still considered early). I've started two companies and it has never failed me. This eliminates any drama and holds each founder accountable for the work that is required. If you don't trust this approach, then there are deep underlying issues that need to be addressed first. This could be not trusting the incoming founder to make up for the time that has passed while you were running the company initially.

</comment><comment><USER18> Joel Spolsky has weighed in on this: [https://gist.github.com/isaacsanders/1653078](https://gist.github.com/isaacsanders/1653078)

<comment><USER19> "if someone goes without salary, give them an IOU. Later, .. you'll pay them back in cash ... when the money comes rolling in ... pay back each founder so that each founder has taken exactly the same amount of salary from the company."

This doesn't seem fair. The founder who takes an IOU rather than cash bears the very real risk that he never gets paid back. There should be an interest rate attached to the IOU: something like 15-25% to account for the risk.

<comment><USER20> There should be an interest rate, because the value of money changes over time. There is a difference between the value of $50,000 in hand today, and the expectation of being paid today's $50,000 a year from today. That difference is reflected in the interest rate. Risk is also accounted for in the interest rate, although fundamentally, not all risk can be accounted for. There is always going to be the risk that the startup goes bust before it can pay back its IOUs, and it would be silly to expect an interest rate exorbitant enough to account for all of that risk. A rate of 15-25% is probably fair to the individual in a nominal sense (more than fair, actually), but it is unfair to the company. This is a case where the individual will need to bear some of the risk in the financial interests of having a successful company. He is not a loan shark, after all.

<comment><USER19> "A rate of 15-25% is probably fair to the individual in a nominal sense (more than fair, actually), but it is unfair to the company."

I think we are in agreement on the first part, i.e. that a rate of 15-25% should adequately compensate the individual for both the time value of money and for the large risk of default.

I don't agree that it's unfair to the company. Consider:

\- The company has no alternative, cheaper sources of debt financing

\- The capital and interest will be deferred until such time as the company has money to pay (e.g. from a Series A) so will not cause any hardship by constraining cash flow

\- These IOU are non-participating, i.e. they don't get any of the upside should the company do well.

If you think about it, it's similar to an investment by an angel: you want to compensate for the risk, you don't know when you will be able to return the cash, you don't have a reliable way to come to consensus on valuation.

Perhaps the right way to structure these IOUs is as a capped note with a low coupon (2-5%) but a reasonable conversion discount. That way the equity-like element of the note compensates for the risk, instead of requiring a large coupon on the debt-like part.

</comment></comment></comment></comment><comment><USER21> Here's a link to an in depth talk & infographic that'll help you see a more detailed view of what might impact how you approach equity splitting someone.

[http://blog.saasu.com/2014/03/28/ceo-insights-webinar- record...](http://blog.saasu.com/2014/03/28/ceo-insights-webinar-recording- how-to-register-for-upcoming-events/)

 _Disclosure: I work at Saasu but think this is relevant._

</comment><comment><USER22> I like, a lot, the Grunt Fund idea of Slicing Pie (no affiliation): [http://www.slicingpie.com/](http://www.slicingpie.com/)

The point is: why split the pie before it gets done or after? why not dynamically split based on the actual resources (money, time, equipment, whatever) people put in in the early days?

<comment><USER23> While I suspect that Professor-of-Entrepreneurship has a lot of the details worked out in his book, I would be concerned about tax implications (higher- basis/more-recordkeeping) and the distractions/morale-risks of constant rolling renegotiation about "latest contributions".

For example, when the company hits a rough spot, it may be best for a team of N to be thinking, "We all need to work extra hard this month so that our 1/Nth shares wind up worth something, rather than nothing." Rather than, "I need some recharge time, I'll let others earn a little more this month, and re- engage for my increments if and when it gets less crazy."

</comment></comment><comment><USER24> > I'd like to bring in a good friend of mine who I believe can contribute...

Work to keep him as a friend. Channeling Steven Covey, it would be helpful to first understand what he would like to get out of the business arrangement and what he's committed to invest on his end. Beyond a mutual agreement, find a win-win scenario.

</comment><comment><USER25> Look into dynamic equity models. eg. Grunt Funds ([http://www.businessweek.com/articles/2012-12-18/grunt- funds-...](http://www.businessweek.com/articles/2012-12-18/grunt-funds-are- trending-in-startup-circles) )

</comment><comment><USER26> What you've done to date is simply what was required. All of the really hard work is in front of you. If your partner isn't worth an equal share they're not worth being partners with.

</comment><comment><USER27> > can contribute a lot in many areas that need to be covered in order to build > a succesful app company

You told us what you've done until now, but are those "many areas" ?

</comment><comment><USER28> What is the other person bringing to the table? Just treat them as a first hire and offer the minimum equity needed to get such a person.

</comment><comment><USER29> Sounds like a good time to use the equity equation:

      http://paulgraham.com/equity.html

<comment><USER30> Neat article. I think OP is trying to discern _how_ to map the friend's contributions to outcome of the company.

</comment></comment><comment><USER31> Equitably</comment>


A Legal Review Of The Aaron Swartz Indictment For Computer Fraud - <AUTHOR> http://www.litigationandtrial.com/2011/07/articles/series/special-comment/aaron-swartz-computer-fraud-indictment/

<comment><USER2> key conclusion:

       The whole case looks like the iPhone prototype saga again: a civil claim
       that some overly aggressive prosecutor is trying to dress up as a federal
       crime. JSTOR has more than adequate civil remedies for whatever transpired here.</comment>