What I wish I knew about React - <AUTHOR> https://bitsofco.de/what-i-wish-i-knew-about-react/ <comment><USER2> React have _sold_ very well the "it's a library" mantra. I find this, at least, _bends_ the difference to build a _marketing_ point around it.

The point they make, and the one everyone writing about React simply repeats, is that "it doesn't give you everything" so you can use it with any other library/framework without trouble. While this claim may be indeed correct, it doesn't mean it's a library. React is a _UI framework_. It's not a complete Application Framework, sure, and you may mix it with other stuff. In fact, you will generally mix it with other stuff. But I don't think that the difference library vs framework lies in providing for all of the aspects of the application or just for some parts of it.

In this particular case, the author seems to have overstepped that somewhat, saying "With a framework, you're essentially given all the materials to build that house, and it's up to you in what arrangement you put them in."

And in there lies the problem. That is not a framework. That's Home Depot. A framework does indeed tell you in what arrangement you're supposed to put the materials. It's in fact this that makes it a framework. It gives you structure. Or at least, the basis for the structure. You put your materials into the arrangement the framework suggests.

React is only concerned with UI, sure. But then again it _does_ give you quite a bit of structure. It does tell you how you're supposed to arrange and build your UI. You extend _this_ class with these methods, or you create this kind of function using these functions in this way. You put your rendering _here_ , and return it in _this_ way... and then the framework will run it.

What is correct is that React is for _UI_. So, sure, it will not tell you how you should do your API calls. But not because it's not a framework, but because API calls are not a UI concern.

<comment><USER3> I've always found the best distinction between a framework and the library lies in who-calls-who? A library you call when you're ready to use it. With React, that's calling `ReactDOM.render()` when you want to render your application. A framework you just provide code blocks and let the framework call your code, rather than your code calling the libraries/frameworks code.

So with that in mind, you can use React as both. If you ever call `ReactDOM.render()` just once and then live in React land, with all the lifecycle hooks and whatnot, you're essentially treating React as a framework, as React calls everything after the first initialize.

If you call `ReactDOM.render` in multiple places or have something around that handles that for you, then you're using React as a library.

<comment><USER2> Yes. That's the other way of expressing the distinction between frameworks and libraries.

And I think most people do use React as a framework. (But I could be underestimating those who use it in the second way, of course).

<comment><USER4> I can give a production example of migrating to React.

We needed to do it incrementally from a server side rendered Java application, with jQuery and _a lot_ of custom spaghetti code.

At first we migrated the server side templates to JSX and started to use React as a library by calling ReactDOM.renderToString. The first thing our JavaScript did was render the React templates similar to using Handlebars. Then the rest of our code kicked in using jQuery bindings and it's events logic.

Now that our templates were all JSX. It was simple that start converting leaf "components" with simple state into ReactDOM.render instead. Often needing ReactDOM.unmountComponent to "refresh" the state And rerender everything like the jQuery based code needed.

Finally, we worked our way up the stack of components so that more and more were "just normal react components without calls to ReactDOM.

The last thing we did was migrate the top level to use ReactDOM.render and we were fully React based.

FWIW, we thought about Redux but didn't use it. We used the patterns from Redux, but felt we didn't need a library to manage our data. This was also pre-Hooks.

All in all took 1 dev on a team of 9, that all kept working on the codebase, about 4 months working on it off and on 50% time focused on the migration.

There were no issues caused along the way, the automated tests didn't need to be changed (except for the new features - which were orthogonal to the React migration), and customers had a (unnoticeable) latency improvement comparing the metrics at the start and end of the migration.

The incremental use was a huge reason we picked React. Not only to migrate to React but also because we can do the inverse process when we want to migrate away.

P.S. We finished this migration Jan 2019. Since then the productivity of the team has noticeably increased. Even new hire "ramp up" has been reduced with them producing production code faster, on average, than pre-React. I'm sure these successes would be true for a migration to any modern UI tool e.g. Angular or Vue.

</comment></comment></comment></comment><comment><USER5> I am not so up to date with frontend dev but what's with the hate towards React these days? It still does what it's supposed to do very well and very fast. Yeah sure if you want JSX you need transpilation but I would want that anyway if I want any of the ES6 features without losing browser compatibility.

And it's also constantly evolving and getting better. Just recently I started a React project with class components only to learn that hooks are now a thing and they remove a lot of boilerplate code. Even with redux, redux supports hooks as well so you can scrap that entire connect() stuff alltogether. Just back to simple function components.

<comment><USER6> > I am not so up to date with frontend dev but what's with the hate towards > React these days?

HN is rarely the place to read constructive comments about JavaScript and frontend development.

Personally I've been developing web apps for 10 years (with technologies such as Spring, ASP.NET, CakePHP, Symfony, Django, jQuery, Backbone.js, Angular 1) and I quite enjoy React. I think it makes my job easier and I feel productive with it.

Also, TypeScript is awesome.

<comment><USER7> I've been considering the jump into TS, but I don't want to end up in a coffeescript situation (i.e. language is dead, but code lingers on and has to be converted back to JS at some point, rather painfully). Do you think it's worth it?

<comment><USER8> You may also consider Flow. It is literally JavaScript plus type annotations. The annotations can be even put into comments turning the files into vanilla JS making this very clear. So there is no danger that if FB abandons it one ends up with code that needs to be converted.

On the other hand Flow is much less cool than TypeScript these days. Plus using it for development under Windows have issues, although FB has started paying attention to them.

<comment><USER9> TypeScript annotations can also be put into comments. I like TypeScript's approach (JSDoc) better, actually, because it's how you'd want to annotate them even if you didn't have a typechecker, anyway.

Although I still hit enough annoyances that I'd go straight to `.ts` files for my next project.

</comment></comment></comment></comment></comment><comment><USER10> To understand React, it is important to understand the difference between imperative and declarative coding. [0] React is a way to write declarative code that use life cycle hooks or effects to do imperative "stuff".

The best explanation oh how useEffect works is by Dan Abramov [1] It is also worth reading his article on React as a UI Runtime as it is a good explanation of React conceptually under the hood.

[0] [https://courses.reacttraining.com/courses/250055/lectures/38...](https://courses.reacttraining.com/courses/250055/lectures/3897343) (Can sign in for free to watch this one video.)

[1] [https://overreacted.io/a-complete-guide-to- useeffect/](https://overreacted.io/a-complete-guide-to-useeffect/)

<comment><USER11> This is a critical point to understand.

If you're not doing declarative programming with React then you're swimming upstream.

Problem is that the concept of declarative programming would be very difficult to get beginners to grasp. Once you grasp it though, it's absolutely incredibly powerful and importantly - simple.

And this is where React loses beginners who jump to more intuitive programming models.

<comment><USER12> But that's great until it isn't.

You can design all the declarative things you want, but someone will eventually come up with a requirement that doesn't appear to fit a declarative structure, such as an event that fires 2 seconds after something else happens.

And so to resolve that you can construct state machines with transition states to get back to a declarative model, but those state machines can quickly become a bigger headache to maintain (yes, even with redux) than if you'd just been able to setTimeout from the component in the first place.

And you start with the best of intentions of re-usable components but find more things that ought to be owned by the component pushed up to the store and suddenly there isn't a neatly re-usable component but an empty shell of something that still needs the other half plumbed in manually every time.

I love the idea that you can abstract everything happening in an application to state and render reproducibly from that, but the reality is that it's really hard and time-expensive to do compared to jquery.

But that would be fine if the tooling was there. If React had a CLI like the AngularCLI it wouldn't be such a problem to add new actions, or new pieces of state, or new components.

But it doesn't, so each new component ends up adding a little more state into the state machine which ends up breaking types in far off places.

Now there's probably an assumption about how state is built up or how reducers are typed or how actions are defined that I'm missing some reason why this shouldn't be happening. But it is happening, it's the reality for the project I've been working on and it's a real headache.

<comment><USER13> I can call 'setTimeout' from the component?

I honestly don't see the issue with your example.

I'd use an event handler to work out when something happened. This would set the timeout, and the handle would be stored as a ref. I'd have a use effect hook to clean up the timer, so when the component is unmounted the timeout is cleared.

What's the issue here?

<comment><USER12> It's no longer declarative as soon as you've done that though; it's still a break in the declarative paradigm.

</comment></comment></comment></comment></comment><comment><USER14> React isn't a library.

You can't drop a bit of it into your project. It distorts how you build the webapp.

jQueryUI is a library. You can add it in and your code is still vaguely the same.

React is a framework pretending to be a library so people can't say "Oh, what? another framework?"

As soon as you use React, you're in the react universe, not the normal webdev universe.

With a normal webapp, I can just import an external js library. With react, I must look for projects that translate those library into the react universe (react-bootstrap etc).

<comment><USER15> You can just add the bootstrap CDN in the head of your index.html and use bootstrap without installing 'react-bootstrap'

(I don't disagree with anything else you said)

<comment><USER14> If you want to use the javascript components, rather than just the styles, you need the react library version. There are various other UI libraries as well that require you use the react conversion library, which sadly lag behind the vanilla js versions.

Fair enough if you love react then this is acceptable. But it pushes the definition of a library, when just using react means that other libraries need to conform to react to properly work with it.

React does some things nicely. But it's not "It's just a library. Drop it into your existing project. And you're done."

</comment></comment></comment><comment><USER16> Aren't hooks more confusing than the class components? In a class, you write your initialization code in the constructor - no infinite loop if you fetch something. And anyone who has used classes in Java or other languages would feel at home.

<comment><USER17> No, you use componentDidMount etc, spreading out the logic that could go into a single hook into multiple lifecycle methods, spaghettied with other logic. Hooks are much cleaner.

<comment><USER18> Would it be possible to have a single method on a class that behaves like whatever useEffect is doing?

<comment><USER19> Not in a single method, no. Watch this talk for more details! [https://www.youtube.com/watch?v=wXLf18DsV-I](https://www.youtube.com/watch?v=wXLf18DsV-I)

<comment><USER18> Well, I did something a bit similar my own language: [https://github.com/batiste/blop- language/commit/90e7704e125f...](https://github.com/batiste/blop- language/commit/90e7704e125ffb3c1fe6b4de2446680d3819ab7e) Not sure where classes are an issue with doing anything like this

</comment></comment></comment></comment></comment><comment> c-smile Big picture: React (especially with JSX) can be thought as PHP running on client side.

We can replace mentally any <div> or <span> on the page with <iframe src="someScriptFunction()"/>. When the application state (fuzzy term but still) changes we request these content generating functions to re-execute.

The VDOM is just an implementation detail - agreement on what these someScriptFunction()'s shall return. Conceptually they may return just html and so we can use:

        function onDataModelChange(model) {
          element.html = provideHtmlRenderingOf(model);
        }

can be used instead of reconciliation (diffing). Performance of such updates will be the same, if not better than React's, BTW.

The only problem of element.html = ... approach is that such updates will loose runtime state. For example, if you have <textarea> replaced that way you will loose its current editing state - undo/redo stack, caret positioning, etc.

So VDOM and reconciliation mechanism is a palliative - to do not loose runtime states on updates. But, again, it is not a panacea. Think about <div contenteditable/> based editors, their content cannot be reactive in principle.

That update-only-what-is-needed reasoning frequently used by React people to promote "speed" hypothesis is a bit misleading - it was introduced for different reasons really.

</comment><comment><USER20> If you look at it from one side, React doesn't have technical problems or the way it's built. If you look at it from another side - React opens up a wide range of possibilities - you can simply drown in them. Adequate things you have done all your life - suddenly feel not so adequate anymore :) For example, it would be fine to use plain old CSS, but with React it just feels wrong. If you look at the number of libraries that try to evolve CSS, there are many. But there is just no winner in sight. Pretty much the same situation is happening in state handling. The number of possibilities! It's amazing. Eventually, though, something gains momentum, like Redux did. This has consequences for React ecosystem, but also everywhere else in JS world. It slowly migrates to Angular, and other frameworks - as the cool kid on the block.

Elegant, simple concepts of React - they are outweighed by the environment they live in. React allows for rapid prototyping, provokes ideas which sometimes break traditional ways. Anyways, I will leave these thoughts with saying that personally I don't have issues with it. I adapt React to what I want - it doesn't adapt my thinking ;)

</comment><comment><USER21> The more I read about React, the happier I am to use VanilaJS alongside SSR and web components friendly frameworks.

<comment><USER22> You should try to use it too! If you discover you don't like anything about it, all the better, you can say you've experienced it and not just read about it. If you happen to like at least parts of it, you've just expanded your knowledge and arsenal of tools for UI development.

<comment><USER23> I just can't get myself around to use anything by FANG just due to their licenses.

Using a framework means your project will never purely be yours.

React license:

> The license granted hereunder will terminate, automatically and without > notice, if you (or any of your subsidiaries, corporate affiliates or agents) > initiate directly or indirectly, or take a direct financial interest in, any > Patent Assertion: (i) against Facebook or any of its subsidiaries or > corporate affiliates, (ii) against any party if such Patent Assertion arises > in whole or in part from any software, technology, product or service of > Facebook or any of its subsidiaries or corporate affiliates, or (iii) > against any party relating to the Software.

<comment><USER24> Am I missing something, or did they drop that in 2017?

[https://engineering.fb.com/web/relicensing-react-jest- flow-a...](https://engineering.fb.com/web/relicensing-react-jest-flow-and- immutable-js/)

[https://github.com/facebook/react/commit/b765fb25ebc6e53bb8d...](https://github.com/facebook/react/commit/b765fb25ebc6e53bb8de2496d2828d9d01c2774b)

</comment></comment></comment></comment><comment><USER25> I write a lot of enterprise apps and I've seen many many frameworks come and go over the years.

I personally am not impressed with React and don't get what all the fuss is about. We've had Angular, jQuery and a whole bunch of stuff over the years and each one managed to become a 'a thing' for a while

<comment><USER26> React introduced a whole new way of writing GUI's.

I come from a game development background, and there we had Immediate GUI's for some time now ([https://eliasdaler.wordpress.com/2016/05/31/imgui-sfml- tutor...](https://eliasdaler.wordpress.com/2016/05/31/imgui-sfml-tutorial- part-1/)). React basically translates this concept to the web, and does some optimizations to not rebuild the entire DOM from scratch, and only rebuild when state changes and not every frame.

Writing a 'render function' is simpler and easier than building a structure of widgets and letting them handle events. (I like simple and easy)

Anyway, it seems both react and flutter are also gaining on the mobile apps developments, and web developers are very happy using React.

Of course frameworks come and go, but React introduced a shift of mind when programming GUI's.

<comment><USER25> React introduced this concept 'to you' perhaps but it wasn't the first. The framework I used has been doing this in the very early 2000s.

Don't get me wrong it has a lot to like about it - but the only revolution is that Facebook's might propelled this in the minds of developers all over.

<comment><USER27> Just curious, which framework are you referring to?

Every time I see someone claim such a thing, it's usually only distantly related. Like it too has a render() function.

I mean, you can find old FRP phd/whitepapers but I don't think they prohibit you from ever saying "$X introduced $concept" without a disclaimer that it wasn't the first. So if you're going to insist, then why not share some prior art for the discussion?

<comment><USER26> I started my career in 2002 (been programming since '93), and back then there was no client side rendering. So my guess is, he's talking about server side rendering that spits out html.

Since those things really miss the 'react' part of React, it is still quite different.

<comment><USER25> I used SmartClient when it was launched in 2002 and that did client-side rendering back then: [https://en.wikipedia.org/wiki/SmartClient](https://en.wikipedia.org/wiki/SmartClient) \- I've recently taken the JS version (not GWT) and ported it to a set of ES6 classes and modules.

I used to work for a portal vendor called Plumtree in 2004 (later acquired by BEA and then Oracle) and much of their stuff did client-side rendering.

The idea of making web interfaces more declarative and less tied to DOM manipulation has been evolving since then. Many developers I'd encounter back in those days moaned that we were not using jQuery or MooTools or whatever.

React is very nice - don't get me wrong - but its popularity has much to do with the mindset of developers shifting away from seeing JavaScript as a way of 'adding spruce' to 'web pages'.

<comment><USER26> The revolutionary part of React is not client side rendering, it's the composition (and reaction) of GUI through state changes.

A quick look at SmartClient shows that it still uses the old OO way of widget composition (widgets having .show() and .hide() methods, etc). This is not at all how React works. In react you render your GUI based on state, and events never manipulate widgets, they manipulate state. It's a functional way of approaching GUI's instead of an Object Oriented way.

The React way of building GUI's is now used outside of the web, for mobile apps through React Native and Flutter. This is completely different that any pre-existing GUI frameworks.

<comment><USER25> It does have show and hide methods - but inside the framework it is deeply compositional. If you have a chance to look at the docs search for 'autoChild' which achieves much the same as react and co but using different terminology.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER28> React is a framework though, not a library. I don't mean to be disparaging but this is an article about how someone thought react was one thing, found it was another and then wrote a post of random tidbits about things in react you could learn from its homepage?

<comment><USER29> React's marketing (such as it is) has pushed the "it's just a library" and "it's just the V in MVC" hard. I think folks can be forgiven for thinking those notions won't entirely fail to describe the real world experience and use of React in ~100% of actual projects (and even more so now that ditching legitimately-actually-quite-portable Redux for hook-centric logic is trendy) and being a more than a little surprised and perplexed when they do.

</comment></comment><comment><USER30> (Opinionated post ahead...) React is, imo, garbage, but alas it's here to stay -- you know, kind of like Spring or Swing. In 10 years we're going to be wondering how the hell we ever used React 8 hours a day way back then. These kinds of markup frameworks/libraries were touted as jQuery's successor, but, from an architectural point of view, jQuery is by far their superior.

"Everything an HTML tag" is an insane mantra to have. As author points out, what in the world does a <Query> tag even do? It might make sense to us because we're used to it now, but the semantics of a tag is completely lost in this "new way" of using them (don't call it _declarative_ because that's _not_ what it technically is; it's _markup_ ). These days I'm creating HOCs on top of HOCs to support different behavior (from redux stores, to authentication HOCs, to "don't render this thing on the server" async components). It's, simply put, a terrible idea. And everyone just bought into it because the guys at Facebook must be really smart.

The lifecycle hooks are just confusing and unnecessary. They are side-effects of over-engineering. And to add insult to injury, they change every few versions (so old code will inevitably break on new React versions).

SSR. I've brought this point up on HN before, but doing server-side rendering in React is absolutely ridiculous. Every time I need to implement it, I'm constantly battling async stuff, state management, webpack/babel, hot module reloading issues, shimming `window` or `document` on the server side, etc. Boy do I miss the days when I was building stuff in PHP and HTML was simply rendered when I ran the damn thing.

It's crazy to me that it's normal now to have like 3-4 compilation/transpilation steps when working on a simple JS-based app.

<comment><USER31> I love reading about people's first principles technqiues of different technologies on HN! What do you think React will be supplanted by?

<comment><USER32> Maybe something like svelte?

<comment><USER33> I just started studying svelte today (alongside Vue). I look forward to sharing my thoughts soon.

<comment><USER34> Things I wish I knew about Svelte: error handling is fragile and/or non- existent.

<comment><USER33> I will keep that in mind, Thank you :)

</comment></comment></comment></comment></comment></comment><comment><USER35> Excerpt:

"The way I like to think of it in comparison to Angular is this: Angular is a framework for architecting and building applications. It, for the most part, doesn't change the way you write your HTML or CSS, but it heavily controls the way you write Javascript.

React, on the other hand, is a library for building user interfaces. It, for the most part, doesn't change the way you write Javascript that isn't directly related to your UI, but it heavily controls the way you write HTML and CSS (or the equivalent of it). And this brings me to the next point…"

</comment><comment><USER11> I love React. In fact I recently gave plain vanilla JavaScript a go and it was so painful that I was glad to get back to React's way of organising a large application.

I don't use Redux or server side rendering - they're not needed.

The only thing that I think it should do differently is leave styles to be handled natively.

<comment><USER36> You absolutely can, and I almost always do, styles things with native css (well, I use sass compiled to css) to style your react application (or widget!).

To my knowledge, React itself has no opinion on styling. It's more the ecosystem around React that's gone css-in-js.

But, yes, if you want to do your styling natively that's really not a problem.

</comment></comment><comment><USER37> tldr; React is a view renderer. It renders views. Getting data to and from those views not included. Navigation? Not included. Persistence? Not included. Styling? Not included. Why? It's just a view renderer, that is to say, it renders templates.

When the only thing your application shares with its dependencies is its view renderer, you're going to feel a lot of pain. This is one of the big reasons why I use Ember.js for complex web-frontends (though holla to phoenix live views). It's a framework-- it has all them pieces you need included in a sane way that's consistent.

Just my two cents...

P.S. If you write JavaScript UI code, and you want to like be better at it, go write native UI code. You'll learn soooo god damn much, write better JS, and understand a lot more about what the fuck all these pieces (like react) are actually doing (rendering UI, managing state, networking etc) in a sane curated (thanks Googs, Microsofties, and Apples) way.

<comment><USER38> Except that it's not only a view renderer, it reacts to changes in state, and it has ways to do stateful thing after a component is rendered or stops being rendered or at other times.

And in practice some state is specific to some component or group of components and some state is global or the group of components doesn't translate to a subtree of HTML's tree structure. Also the kind of thing that has to happen based on what happens in the app is often deeply async.

And it all becomes a mess.

But it's still not as bad as a mess as without React, I believe at this moment.

</comment></comment><comment><USER39> I'd rather use no JS framework at all. But, if forced to use one, I'd pick Vue, as that seems the less opinionated and simple framework.

<comment><USER40> Writing Vanilla-JS as we speak - don't be jealous! :)

</comment></comment><comment><USER41> A nice side effect of the article: by reading the inverse of it, I get a better understanding of Angular which I haven't used since 1.x.

</comment><comment><USER42> I tried React and hated it, especially JSX, but I made some decent money working on React projects in the past. I much prefer libraries/frameworks where the view is completely separate and is more "pure" HTML. I ended up creating my own framework that was much easier to understand and manage, but is obviously not generic enough to publish. Maybe one day I'll clean it up and push it to a Github repo, but then again, does the world need yet another MVC framework? I think not.

<comment><USER27> > I ended up creating my own framework that was much easier to understand and > manage, but is obviously not generic enough to publish.

You lost me there.

Cute for a solo/learning project, but when other people are touching the project or you're trying to build a business, you have to answer for why your project was so special that it needed its own ad hoc framework. As opposed to, say, a framework with real documentation. Or one with an ecosystem so you can escape this culture of NIH.

When I hear someone building their own JS framework, I see someone who wanted to procrastinate the hard part (building a business, shipping a product, appealing to users). Like when game developers decide to build an engine and never make the game, aka the hard part ([https://www.voxelquest.com/](https://www.voxelquest.com/)).

<comment><USER42> Gatekeeping much?

</comment></comment></comment><comment><USER43> Off topic, but the yellow border on the page kept drawing my eyes away from the text to the edge of the screen.

</comment><comment><USER44> Do you wish you knew VueJS? :D

</comment><comment><USER45> tldr; RTFM

</comment><comment><USER46> >> React is a library, not a framework

They say it often but it's not true. React forces you into an entire workflow with JSX, bundling, source mapping, babel transpilation and often restricts you to using components that are designed specifically for React; accessing the raw DOM is nasty business.

If it was a library, it would not hijack the DOM and override it with its own; that fact alone is more than enough to call it a framework. Any tool which takes over the execution environment is a framework by definition.

A library is something you use, a framework is something you work inside. You could argue that react could be used to target only specific components but this would be missing the point that 99.9% of the time, React is not used like this; as soon as you have a hierarchy of components, it's a framework, not a library.

<comment><USER47> You don't need to use JSX in order to use React; it's just syntactic sugar.

[https://reactjs.org/docs/react- api.html#createelement](https://reactjs.org/docs/react-api.html#createelement)

<comment><USER48> And who uses react without JSX at any scale?</comment></comment></comment>


Ask HN: Why can't Python be compiled? - Kepler-295c The old answer was that types were not known in advance. However with Python 3.6, it's possible to give type hints. Given this, is there anything stopping Python being compiled natively? <comment><AUTHOR> Cython compiles any python code to C which is then complied normally. If you provide type hints cython will use that to produce more optimized C code.

That being said the speedup from compiling your untyped python code is minimal, generally in the 0-40% range. However by adding types to your code you can often get significant speedups.

</comment><comment><USER2> Yes. Exactly the same as before: dynamic typing. Optional type hints don't change this.

And Python actually _is_ compiled. Where do you think these pyc and pyo files come from?</comment>


Movim 0.16 – A federated web-based social XMPP client - <AUTHOR> https://nl.movim.eu/?node/pubsub.movim.eu/Movim/e10a8998-5e4d-4b52-9b9e-2f103b446d94 <comment><USER2> Off-topic: I wonder why XMPP didn't take off.

Most people attribute it to the lack of standardisation regarding server implementations, or "which XEPs can I support" but normally when those situations happen a single set of things takes off because it's highly polished or packaged as a bundle.

It feels like we were -nearly- there with regards to decentralised IM, but then suddenly we regressed to walled gardens and now I have 10 applications on my phone to communicate with people, each with their own account and very little cross over.

<comment><USER3> Because there are too many clients with a wide range of supported/unsupported features.

The only solution out there that supports cross platform JINGLE is AstraChat[^1], which is closed source and commercial, but they lack OMEMO and Carbons.

Conversations on Android has both OMEMO and Carbons, but no audio/video or p2p transfer files.

Pidgin, Empathy, Gajim, etc are lacking behind with features, though Pidgin can be made reasonable up to date, still without JINGLE[^2].

Dino[^3] is promising, but it linux only.

I don't know how Trillian is doing these days.

[^1]: [https://astrachat.com/](https://astrachat.com/)

[^2]: [https://petermolnar.net/instant-messenger-hell/#adding- netwo...](https://petermolnar.net/instant-messenger-hell/#adding-networks-to- pidgin-technical-details)

[^3]: [https://dino.im/](https://dino.im/)

<comment><USER4> > ... p2p transfer files ...

XMPP seems to be moving away from that as it is impossible to do reliably with the current brokenness of the internet. The current hotness involves uploading the file to the XMPP server and then just providing a https link to the other client(s). The contents can be encrypted but client support is spotty. So sometimes you have to trust the server. Still way better than the old thing.

I am personally not at all sad if my IM client can't do audio/video. Just let me send a damn text message and have it come out at the other end reliably.

<comment><USER5> > XMPP seems to be moving away from that as it is impossible to do reliably > with the current brokenness of the internet. The current hotness involves > uploading the file to the XMPP server and then just providing a https link > to the other client(s).

Could be even more cool if you could just post a file to a group chat and it would be shared via BitTorrent behind the scenes.

> I am personally not at all sad if my IM client can't do audio/video. Just > let me send a damn text message and have it come out at the other end > reliably.

I agree. I can hardly see why texting and voice calling is always meant to be done with the same app.

</comment></comment></comment></comment><comment><AUTHOR> Hi, author of Movim there. Do not hesitate to ask me questions about the project or XMPP :)

<comment><USER6> Hi! How many users do you have on your main pods (nl, de, jp and fi)?

<comment><AUTHOR> [https://de.movim.eu/?infos](https://de.movim.eu/?infos) 409 [https://jp.mov.im/?infos](https://jp.mov.im/?infos) 133 [https://nl.movim.eu/?infos](https://nl.movim.eu/?infos) 10669

Those are the accounts that already logged in on those pods. You can check the "currently connected" stats for real time numbers :)

FI is actually down at the moment.

</comment></comment></comment><comment><USER7> I still remember writing an XMPP-Client and IRC-Client servers which were widely used across our organization. Later on, we developed our cloud-based chat application with mobile apps. Then we had support for xmpp/irc for those chat apps, eventually dropped the xmpp/irc support too. I think the reason is major players (Google/FB) dropping the support for xmpp and at the same time evolution of many cloud-based chat apps. XMPP is well standardized and documented. If it could have been TEXT based instead of XML many developers could have adapted (IMAP protocol still being widely adopted).

</comment><comment><USER8> Because nobody said it and everybody is centered on how XMPP is ugly/beautiful: Congrats for the release :)

</comment><comment><USER9> I'll be the one to bring about the usual naming nitpick.

With several different vi(m)-implementations around, like neovim, my immediate assumption was that this was another vim editor-fork.

Another name might help emphasize that this is a chat-related product/service?

<comment><AUTHOR> Neovim was launched in 2014, Movim in 2009 :) But yeah I got a few people that told me that that it was a vim fork or something related.

Actually the name contains IM (we have the mov.im domains as well).

Originally the name is an acronym (My Open Virtual Identity Manager) but was lately abandoned to keep only the main name.

<comment><USER10> > we have the mov.im domains as well

I don't know to what extent the name Movim confuses people, but when I read the name in the title of this post, before I read the rest I too expected something related to vim.

If rebranding it as Mov.im is an option, since you already own that domain name, I suggest considering doing so. Though I guess there is a risk then that people think of the QuickTime file format instead?

I don't know what impact such a rebranding would have on search results rankings but among all possible rebrandings, if any were to be considered, I would think it would have the least impact at least. And also would involve a low amount of work since other domain names and such still make sense.

</comment></comment></comment><comment><USER11> Why this and not converseJS? What are the killer features :)

<comment><USER12> I think this uses ConverseJS. Converse is not a full featured client on its own, and will require your own websocket-enabled proxy most of the time since BOSH is rarely enabled.

<comment><USER13> Movim doesn't use Converse. It's an older project than Converse.

> Converse is not a full featured client on its own

I guess that depends on your definition of "full featured", but it has more features than a lot of other clients.

Most XMPP servers support BOSH and websocket directly and since direct TLS connections aren't possible in the browser Converse uses those.

If the XMPP server admin doesn't enable BOSH or websocket, that's not really Converse's fault :)</comment></comment></comment>


Groovy & Grails presentation at Kabisa ICT - <AUTHOR> http://marceloverdijk.blogspot.com/2010/03/groovy-grails-presentation-at-kabisa.html

<comment><USER2> I lurve some Groovy and Grails. Seriously, if you are a Java developer you need to take a look at this. Even if you're a curious Ruby/Python/PHP developer, this might help dispel some of the FUD about Java-based apps.

<comment><AUTHOR> Groovy is a unique and appealing language for developers that use Java to write "Business Apps".

You can start out writing plain Java code. Then start to add a little Groovy syntactic sugar. Then increase your dosage of Groovy syntactic sugar. And before you know it your code looks a lot like Ruby.</comment></comment>


McDonald's ex-CEO: $15/hr minimum wage will unleash the robot rebellion - <AUTHOR> http://arstechnica.com/business/2016/05/mcdonalds-ex-ceo-15hr-minimum-wage-will-unleash-the-robot-rebellion/ <comment><USER2> I was at the very same restaurant show this week as Rensi mentions in the article.

The only robot he could have possibly have been referring to was a Baxter robot that Middleby Corp set up as an attention-getting gimmick. It was not an actual product for sale. You can see for yourself here.

[https://twitter.com/WeRRestaurants/status/605484681245499393](https://twitter.com/WeRRestaurants/status/605484681245499393)

It was also at the show last year:

[https://www.youtube.com/watch?v=mPwjG- CnLgA](https://www.youtube.com/watch?v=mPwjG-CnLgA)

Automated kitchen technology is way more primitive than this...for multiple reasons.

<comment><USER3> Asia is far ahead of the game.. [http://www.parentherald.com/articles/42018/20160508/artifici...](http://www.parentherald.com/articles/42018/20160508/artificial- intelligence-invades-fast-food-how-ai-technology-could-change-way-humans- dine.htm)

</comment></comment><comment><USER4> Nice fear mongering from ex-CEO. We all know that robots will be here regardless of what the minimum wage is.

<comment><USER5> I'd rather see forward-looking companies replace their CEO's with AI.

</comment></comment><comment><USER6> "Robot rebellion" in fast-food industry has already quietly happened. Those robots are called "vending machine".

There is even a moderately successful fast-food chain in the Netherlands that have fully embraced this "rebellion" some 70 years ago, and they are still going strong [1].

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

</comment><comment><USER7> Our local Chipotle has such inconsistent quality, I would welcome our robot overlords. Last time they put on double the normal amount of sour cream... tasted like burrito soup.

</comment><comment><USER8> If robots are worth it to replace $15/h workers in fast food stores, then they would've been worth it to replace $8/h workers 5 years from now (or less).

<comment><USER9> Technology gets cheaper (and more advanced/capable) over time.

</comment></comment><comment><USER10> McDonnalds is paying even higher costs than that in other countries and hasn't done it.

We have fully automated pizza making machines, but you still see plenty of people in pizza shops. The economics clearly don't work out in favor of full automation at the moment.

</comment><comment><USER11> CEOs have been replacing workers with machines since the start of the industrial revolution. Calling the machines "robots" is just a different label for the same-old-same-old.

P.S. they have also been crying about the minimum wage as a "job destroyer" since it was introduced a century ago.

</comment><comment><USER12> Good, this means that fewer people have to work, which should be humanity's goal. I don't get this fetish with working. We should decouple labor from income and try to get rid of as many jobs as possible.

<comment><USER13> If you decouple labor (or work, productivity, whatever) from income how do we know who gets what? I can only speak for myself but I wouldn't want to live only at the bare minimum UBI stipend.

<comment><USER12> > If you decouple labor (or work, productivity, whatever) from income how do > we know who gets what?

It's already mostly decoupled anyway. The 1% don't actually perform any labour yet they get most of the money created by people who actually do the work. The only thing I'm proposing is a better distribution of wealth and free time.

</comment></comment></comment><comment><USER14> People still "eat" at McD's?

<comment><USER15> Now more than ever it seems [http://www.ibtimes.com/mcdonalds-corporation- mcd-q1-2016-pro...](http://www.ibtimes.com/mcdonalds-corporation- mcd-q1-2016-profit-expected-rise-revenue-projected-drop-2357882)</comment></comment>


Bitbucket Cards - <AUTHOR> http://www.bitbucketcards.com/ <comment><USER2> "bbcards is requesting read and write access to your public and private repositories."

Scary. Very, very scary message.

<comment><USER3> Well, how else would you do it?

<comment><USER2> I'd at least say that it is a product of Atlassian (and not some random project by unknown authors) and that it won't touch my repositories, just my issues.

</comment></comment></comment><comment><USER4> A pretty shameless rip-off of Trello, yet it makes sense. I'm just about to set up collaboration using Bitbucket and Trello* and there's too much manual linking involved.

At the moment it looks very v0.1 though. I'll wait for the release version.

'Raise a bug' ->

<http://www.bitbucketcards.com/samtardif/bitbucket-wallboard>

-> 'Error: Couldn't find that repository.'

* (Of course, if Fog Creek hosted git repos I never would have been a BB user in the first place..)

<comment><USER5> Jira has had the card view for a while, it's more likely to be inspired by that.

<comment><USER6> I think Agile had it first...

<comment><USER5> My point is that an Attlasian employee would be likely to be inspired by an Attlasian product.

<comment><USER6> They're all inspired by Agile, and the way it avoids large specs in favour of lighter processes like ... index cards, and moving them around on a board.

</comment></comment></comment></comment></comment><comment><USER7> I don't see all the projects I'm following in the dashboard. I'm the owner of all of them. Some public and some private ones show up. Can't wait for this to get these few little wrinkles worked out.

<comment><USER7> OK, now I see what it is - I needed to enable issue tracking on the other projects (which makes sense, as the cards are essentially a UI over their existing issue tracking).

<comment><USER8> YouTrack from jetbrains is going the same way - putting a wrapper around their existing issue tracking - [http://www.jetbrains.com/youtrack/agile_project_management/i...](http://www.jetbrains.com/youtrack/agile_project_management/index.html)

</comment></comment></comment><comment><USER3> I've started on something similar for GitHub... See <https://airport-r7.appspot.com/madrobby/zepto>

</comment><comment><USER9> Just yesterday I was searching for an app or something to interface with my BB issues as I found the issue tracker interface extremely clumsy (Update issue status -> save -> reload issue list -> click next issue).

This looks like exactly what is needed. I think I'm being cemented in as a serious BitBucket advocate.

</comment><comment><USER10> This was started as a 20% project by @samtardif - so awesome to see this ship :)

</comment><comment><USER11> This is something that was missing and it's really cruical.

One `usability` thing: it will be good for example to have a button in Bitbucket which will open Cards in new tab in for a given project.

</comment><comment><USER2> I like the idea but I can't use it because I need to be able to manage more than 50 issues per version.</comment>


Ironclad (YC S15) Is an Automated Legal Assistant for Companies - <AUTHOR> http://techcrunch.com/2015/07/30/yc-backed-ironclad-is-an-automated-legal-assistant-for-companies/ <comment><USER2> Law is a strange business to which to apply automated functionality.

On the one hand, and especially touching on startup-related areas, the law can have incredible complexity. When you consider that corporate law, securities law (federal and state), tax law, contract law, employment law, and copyright law all apply in varying degrees just to do a standard corporate formation, you can imagine how many opportunities might present themselves for missteps for founders trying to guide the process themselves.

In addition, there is not merely the issue of overt error in missing legal requirements, etc. There is also the issue of omitting to make the best strategic choices from among those potentially suitable for a venture, and this means being able to stand back from one particular well-trodden path (Delaware C-corp with one class of common stock) to assess whether that path in particular is best for your venture. While many startups are well served by following the Delaware C-corp (single class of stock) path, others may not be. Believe it or not, there are some startups that are best incorporated in their own local state and not in Delaware. There are others (particularly "lifestyle" ventures, certain specialty ventures or bootstrap ventures that want to start on the cheap and convert later) that may be best served by setting up an LLC. Even in Delaware, there is the vanilla setup (and by this I mean even a savvy one like the type YC uses) and there are others using super- voting classes of stock or FF preferred or other variations. There are also fine-point decisions within a typical Delaware C-corp setup that can easily be missed. Do you axiomatically go for a cliff for founder vesting (like YC does) or do you use pro rata vesting from inception? Do you prevest some founder stock or not and, if so, in what cases? How do you handle acceleration of vesting on certain triggers occurring? How do you best deal with IP issues for various scenarios where multiple persons have worked on a venture prior to company formation? Even mundane issues such as how to handle real cash contributions sometimes made by founders without messing up the common stock price can prove troublesome if mishandled.

All that said, and on the other hand, it is true that many legal transactions today fall cleanly into well-established patterns that do not require any form of specialty legal help. While founders can and do often use law firms for such steps, it is a very legitimate question to ask, "what is the real value from the lawyers?" and "is it worth the cost?"

So you have the two sides of law: the incredibly complex and the perfectly mundane.

And here is the problem for many founders: not knowing which side of the line you are on when it comes to this or that issue in the choices you make when you form or build a venture.

Of course, when you also add the vast range of laws that apply to a venture beyond formation, the issue gets even trickier.

No one wants to spend money unnecessarily on things that don't add value commensurate with what is spent. But no one wants to make crucial legal errors either. If a big one should occur, your early-stage cost-saving efforts can quickly transmute themselves into the penny-wise/pound-foolish category.

This is where the opportunity presents itself for tools and platforms that seek to streamline and improve legal transactions and this is what I like about Ironclad's philosophical approach in particular.

The idea is not to have some end goal of replacing lawyers because that leaves founders helpless when it comes to the "incredibly complex" legal aspects of what they do in their ventures.

The goal is to streamline the process of working with lawyers while giving founders the choice to work without them, or to work with them in limited ways only, whenever they feel comfortable doing so. This keeps the founders in control of the process. Any founder who has been whisked into a legal environment where the lawyers are advising this and advising that, and are meanwhile adding a team of departmental specialists to the mix, just to handle what you might have thought a fairly basic set of issues knows the frustration of losing control in such cases. Even with the best of automated tools, that risk of losing control will never fully be eliminated, as law is indeed complex in many, many ways. But, whenever you can take that risk out for important classes of cases, you empower the founders to be much more in control than they historically have been. And that is what Ironclad seeks to do philosophically. The goal is highly commendable and should not be resisted even by lawyers. People have problems enough to deal with and no one, even lawyers, should have a stake in waste and inefficiency.

Even more, there is huge value in making legal transactions quick and efficient in their processing, whether working with a lawyer or not. If you can get your standard forms processed quickly and properly without a paper- shuffling and delays, that is a huge value in itself.

So here is hoping for elegant execution and great success. I had spoken with Jason about this back in the day when he was with Fenwick and he does indeed bring a great perspective, skill set, and passion to the task. Congrats on getting to this level and looking forward to what will follow in the execution.

<comment><USER3> I don't see why automation means one must follow the "well-trodden path." Software isn't limited to a linear script.

I'm no lawyer, but all those questions (where to incorporate, classes of stocks to use, etc) seem like they could be codified into decision trees and similar algorithms. I can see why a human would be better at learning and exploring to know what questions to ask, but surely applying them to a particular startup is mostly routine work?

<comment><USER4> If that were true then every business would be a Delaware corporation. Many are, but many aren't. No flowchart will get to every nuance.

<comment><USER3> Why not? Assuming lawyers aren't working based on hunches, one should be able to write down the process followed, which could then be encoded in software (as a flow chart or otherwise).

In fact, even if the lawyers _are_ working from "instinct" and can't fully describe their process, it's just a matter of getting a good sample of existing companies (a few hundreds, perhaps, some of which not Delaware corps) and asking the lawyer to "fake advise" each one. At the end of the process, you'd have a pretty good model of that process.

<comment><USER4> Because, following the corp hypo, it isn't the lawyer's decision. A lawyer doesn't decide which path is best for a corporation. A lawyer outlines the various options and allows the corp's leaders to make the decision. Sometimes there is an obvious answer, sometimes not. Therefore any accurate flow chart would end with a series of options. The lawyer then stands ready to answer questions about those options. It's a back-and-forth conversation and, imho, the client rarely agrees completely with the lawyers opinion.

</comment></comment></comment></comment></comment><comment><USER5> Hi everyone! I'm one of the founders of Ironclad and would be happy to answer any questions you might have. Before starting Ironclad I was an attorney at Fenwick & West, and my co-founder was an engineer at Palantir. Let us know how we can help. We're excited to launch :)

<comment><USER6> Minor point: the screenshot shows "Wiley E. Coyote" but it's actually "Wile E. Coyote". Otherwise, seems like a much-needed service. A lot of what lawyers are used for is little more than mail merge, so I'm happy to see this aspect of their work being commoditized.

<comment><USER5> This is an excellent bug report. Filed!

</comment></comment></comment><comment><USER4> Full disclosure: Actual flesh-and-blood lawyer here.

These tools are great when things are going well. If you are a business for whom lawyers are an inconvenient expense, paperwork devoid of real value, then go ahead and download your legal advice. You'll probably be fine with boilerplate legal documents. But realize that as with the concept of 'technical debt' you might be pushing off minor expenses today in exchange for huge expenses tomorrow. That can be a valid startup strategy only IF you remain cognisant of the associated risk.

Two things could happen. First, things might hit the legal fan. Your now large business will be in need of some actual lawyering but you won't have worked with anyone. You don't want to be googling "IP lawyers in my area" the day some troll's demand letter arrives. You want someone who knows you and your business.

The far far worse option is that things don't hit the fan. You could go for years blissfully unaware of the damoclean sword over your head. But the sword never falls, the business grows, and eventually you want to take things to the next level (IPO/buyout/new investors). Then you meet your first lawyer and he or she isn't working for you. I've been that lawyer walking into a room of wannabe millionaires who think they have all their legal ducks in a row. I write a memo to my client about some gaping legal hole I've found, and the next thing you know all that money goes away. You'll probably never learn why those potential investors stopped calling.

Common big holes: Bad/fraudulent PII/PCI compliance. Improper labor practices (common when everyone is working their first real job). Poor or absent organization structure. Failure to abide applicable foreign laws. Tax fraud due to reliance on tax-filing software. Failure to properly protect IP. "Creative" accounting practices. Lack of industry-standard security measures.

And my personal favourite: Onerous contractual/financial obligations due to failure to seek adequate legal advice at time.

<comment><USER7> Full disclosure here - attorney as well.

You absolutely raised some valid concerns. And I hope, I hope, I hope that startups aren't using these templates as-is (or possibly at all). Each company's business operations, policies, risk tolerance, etc. will be different and their standard contracts need to reflect those positions. They need to have lawyers write the agreements/policies/etc. to make sure they're following all applicable laws.

However, I think that Ironclad (and possibly others) are trying to make the administration of those contracts easier. Real trouble, from a business perspective, comes when the company gets bigger and they don't know the risk on their books because they can't manage their contracts.

I don't think these tools will cut out the lawyers, but instead help the companies manage their contracts and be able to better use us lawyers.

<comment><USER4> I'm all for anything that gets people to pay attention to legal obligations. I do agree that many lawyers are inefficient and could be helped by automated tools. But I know of many, such as MY lawyer, who are very reasonable.

I do see many companies who don't know how to use lawyers. They do things like ask outside counsels to attend on-site meetings in person. Or they lie, forcing the lawyer to do things five or six times based on new information they pull out each cycle.

</comment></comment></comment><comment><USER8> I _really_ wish the free plan wouldn't allow users to easily create NDAs. _Anything_ but NDAs!

<comment><USER5> Haha, you got us there. Laughed out loud at this one.

</comment></comment><comment><USER9> I think this could be really valuable but I think there are two hurdles it needs to get over.

1\. Confidence that the docs are really "ironclad"

2\. Flexibility with equity options

To expand on 2. I worry that having the basic stock option grant approach as the only option just solidifies further how embedded that framework is for employees. We discuss a lot on here how the typical option agreement is rife with pitfalls and typically leaves early employees high and dry even if there is a big exit.

I would suggest adding in the alternative of an Equity Incentive Plan which sells restricted stock to employees in exchange for a promissory note held by the employer and due at exercise. It is a bit more complicated but is better overall as it requires no out of pocket expense for the employee upon purchase (or even at exercise is the company chooses) and actually gives them real shares that can't be easily written off by an acquisition or later investment. It also requires an 83b election which is something that most companies don't know about - and would be very helpful to have an automated way to walk them through it.

[1][http://www.fwlaw.com/news/8-a-practical-guide-equity- incenti...](http://www.fwlaw.com/news/8-a-practical-guide-equity-incentive- plans)

<comment><USER5> I think this is a really cool idea. One of the things we're designed to do, as the administrative layer, is take these conventions that are set up by experts and put them into software so that anyone can then execute on them. This would be a neat example.

</comment></comment><comment><USER10> I wonder whether the higher price for custom templates is warranted. I would think that this would be a very good data source for Ironclad to mine future templates, identify intricacies etc. On this front, I wonder how lawyers would respond, given that this might streamline their work but it might potentially, as a centralised data source, commoditise big chunks of it. I am saying that because I have a similar example. I.e. I am doing system implementations for Finance departments, and the cloud options definitely give the vendors an easier peek at the design decisions and techniques an integrator uses. Maybe this is not an immediate concern, but I would not rule out vendors monetising that data source of designs from specialised integrators. E.g. a vendor already performance profiles a huge range of their client applications and then provides a metric on quality given the comparison (quite rudimentary now.)

</comment><comment><USER11> We use IronClad at Zinc and they are amazing. Whenever we have a new contractor, we shoot them an email (actually now we click a button) and they take care of the rest. Saves me a lot of time while ensuring we get all the boxes checked.

</comment><comment><USER12> Jason is on point, he's pretty much answered me back within 1-5 minutes every time. Congrats on the TC article!

</comment><comment><USER13> Is it template-based like Clerky (with the same Delaware C-Corp limitation), or is there more to it (advice on which document to use based on the situation, clauses that change depending on context, etc.)?

<comment><USER5> Clerky is awesome. What we're going for here is more of the automated record keeping and management. It seems like most company's legal docs are a mess (and I know from reviewing lots of them when I was an attorney).

The templates we provide can help you automatically keep your company's legal folder in pristine condition - we're not just setting you up with the template, it's the whole process layer from end-to-end.

To be clear though, we don't provide any legal advice whatsoever. We're designed to work with an attorney - so that if you need them to edit Section 2.1 of a document before it gets sent out, you can just have them hop in to the Dropbox folder and make the edits. It's the administrative layer for legal, not the advice layer.

<comment><USER14> Hey Jason, congrats on the great TC writeup! I think we may have mentioned this to you before, but Clerky is definitely all about automated record- keeping and management as well. If it was just about templates, I'd be sitting on a beach ;)

</comment></comment></comment><comment><USER15> Bug: Can't enter input into the enter legal name modal on iOS Safari. Can't close the modal either.

<comment><USER16> Sorry about that, and thanks for reporting it! We'll get that fixed.

</comment></comment><comment><USER17> Your website indicates its for Delaware C-type corporations based in California. Is that the limitation?

<comment><USER5> Correct in terms of default templates. Our default templates, which are used by YC companies typically, are designed by attorneys for Delaware C-Corps in California.

We are designed to be able to take in any type of legal document though, including docs you already have from your attorney. So if you're not using the default templates, or you've customized them yourself, that limitation won't apply.

<comment><USER18> this seems like a very narrow operating space? if i understand correctly.. if you are NOT a DE C-Corp in CA, then everything needs to be reviewed again based on a different structure.

do you plan to offer base templates that better fit companies not following your DE/CA method of incorporation. i would venture to guess most startups don't have the capital nor legal advice to go this route. in fact my CA attorney told me to skip the DE C-Corp in the beginning.

<comment><USER5> If you are a company set up on another structure, we can take the documents you're currently using (from your lawyer for instance) and set them up on the system for you. We're designed to be the infrastructure layer, not necessarily the ones coming up with the templates. But we do have those DE C-Corp templates up since many YC companies are set up that way.

<comment><USER18> makes sense, thanks for the response.

</comment></comment></comment></comment></comment><comment><USER19> Looks like a really great idea guys, best of luck. I'll definitely be a customer.

<comment><USER5> Cool thanks! Would love to hear back from you once you've had a chance to use it and hear what you like and don't like. One thing that's been awesome about going through YC is really learning to take feedback from users. Give us a shout any time at firstname.lastname@example.com

</comment></comment><comment><USER20> I can see this being big, It makes me wonder about the very long term.

Saying that it's a tool meant to be used by lawyers is fine, but it's going to be fairly obvious to any lawyer who thinks about it for a moment that that is basically bullshit.

The play is pretty obvious:

Phase 1: Lawyers use the service as a workflow tool.

Phase 2: The tool gets good enough to mostly not need the lawyers. They enjoy a brief period in which their income is essentially automated.

Phase 3: Companies use the service as a lawyer, lawyers only used in extraordinary circumstances.

A big part of the lawyer's value proposition is about liability/peace of mind. Like, "I'm sure this NDA is solid because if it's not I have someone to sue, the guy who wrote it, my lawyer." That's a valuable service, which is why they will stay in the picture during phase 3--essentially a liability limiting sign off.

Im sure you've thought about that, as your business model sort of hinges on having the lawyer take all the liability. Ie, the documents you provide are just "suggestions" or boilerplate for a professional to base their work off of, and those professionals are the ones who are actually liable for mistakes or oversights. It makes sense.

(Sidenote: I predict some hostility from lawyers here, similar to the hostility in the design profession over stuff like 99designs. I don't think it'll matter though. They will be hostile because they know that the tool, if it becomes widespread, would drastically reduce the number of lawyers who can work in the area, but they will each be incentivized to use the tools individually because it'll save them time in their practice as they all race for the bottom, hoping that they are one of the few left standing in the aftermath.)

Anyway, you'll have access to a very large dataset of those potential mistakes and oversights plus the tactics that work to solve them, and you'll be able to hone the tool so that they become more and more rare (this is phase 2 from above).

But the thing I wonder about is what the second order effects will be. Let's say we're in a world in which Ironclad has won, and millions of businesses use it for the legal needs.

In that world you have drastically fewer lawyers handling more clients because the work is essentially automated and they are sign signing off. Each lawyer probably still makes the same money overall since the revenue per client is much lower.

At some point something will go wrong, and the lawyer will be on the hook for having screwed up. And he'll say "Wait a minute, I'm not the one who screwed up. I used the Microsoft of legal services, the one you can't get fired for choosing, the huge goliath that lowly me could never hope to question because they have the most legal expertise in the world. I used Ironclad. They said this document was right, who am I to say otherwise? I trusted them, and they are the ones who screwed up."

And at first it won't matter. That's not how professional liability works, so that lawyer will get ground up in the gears. Maybe the scrappy ones will sue you, and you'll take your knocks, mostly winning or settling.

But I wonder if maybe when there's an army of rubber stampers who are essentially not doing anything except saying "If Ironclad screwed up this document, then I'll take the fall," then with enough case law the environment will change, and somehow Ironclad actually would be saddled with a greater proportion of the liability? Normally I imagine things like that wouldn't work because no one will fight enough to place the liability where it probably belongs, but in this case you'll be up against LAWYERS, whose profession it is to deal with and fight for/against laws. That might make a difference in the very long term.

Anyway, it'd be a good problem to have since it would mean you won like 20 years ago. Good luck guys, I think it'll be big!

<comment><USER21> As a lawyer, I look forward to that brief period of automated income! But seriously, I think that there will always be a role for advice on novel issues, and good lawyers prefer to be in that niche rather than spending all our time mastering the ins and outs of Word macros. The problem is that people look to corporate lawyers for two very different services -- legal advice, and business process. Legal advice is very difficult, and I would argue, impossible to automate. Business process can and should be automated. It does not make sense to rely on highly trained humans for routine business process.

</comment></comment><comment><USER22> Congrats on the launch Jason & Cai!</comment>


G2 is coming - <AUTHOR> http://g2.t-mobile.com/

<comment><USER2> 4G, looks like it's the HTC EVO(or something using the same platform).

<comment><USER3> I think the reason this is interesting is that it isn't 4G, but gets similar speeds on 3G with the new HSPA+ technology.

Engadget has it pegged as the "MyTouch 3G HD" and has some leaked photos of it's front and rear:

<http://www.engadget.com/tag/myTouch3GHD/>

<comment><USER2> Uh right, hsdpa with a change in modulation (QPSK, that lately is starting to be employed in a lot of other standards/medium) to achieve 14mb/s. The next and last step before LTE will be MIMO.</comment></comment></comment>


Mortgage Crisis Caused By Anti-Racist Activism - <AUTHOR> http://www.nypost.com/seven/02052008/postopinion/opedcolumnists/the_real_scandal_243911.htm

<comment><USER2> I have officially heard it all now.

I knew that a lot of the 'handlers' of corporate bigwigs would have them out angling for a defense at the trials that are looking increasingly likely, but this one just reeks of desperation. The current mortgage crisis was fueled by a myriad of reasons, but believe me, the idea that billionaires were sitting around thinking about ways to get money into the hands of poor black guys was hardly one of them.

I can see now that one of their strategies will be to play the race card. Their aim will be to ensure the jury thinks about something other than the mountain of documents, emails, and other internal and external communications and directives. All of which will point to the inescapable conclusion that their cases are really about garden variety fiduciary negligence on an unprecedented scale. The race card is how many of the wealthy, from OJ to the CEO of HealthSouth manage to escape justice. It behooves us all to hold our wallet and our will a little closer when the wealthy start to talk about racism, or the dangers thereof.

Middle America you are being conned. Just today the CEO of Bear Stearns unloaded what used to be over a USD1 billion stake in Bear for USD60 million, under the terms of the original deal with the government that his stake was only to be USD15 million. Poor him you say? He lost so much money you say? Consider the fact that Bear's stock price is being propped up by a USD30 billion guarantee from the US. Then ask yourself where the money for that guarantee comes from. Even better research it. Did you know several such guarantees are being made?

Consider some news that the government would have us believe is completely unrelated. It just got a whole lot harder for poor and middle class college students to get student loans, because the government has found it necessary to materially decrease the levels of subsidy it provides to student loans. Now a cynic would say that the CEO of Bear just raided the US college fund for USD60 million. An optimist would say the government is simply making financially prudent cut backs in its spending. The truth is somewhere in the middle, but I think we'd all agree that these types of financial machinations are sub optimal. Giving anti-capitalist guarantees of security is how we got here in the first place.

WOW . . . I'm ranting . . . I gotta stop working so late.

At least I caught myself.

The short version is this article insults my intelligence, and assumes that I am uninformed. All of which would trouble me a good deal less if the aim of this article was something other than keeping a scumbag out of Club-Fed.

<comment><USER3> The article doesn't claim that billionaires were "sitting around thinking about ways to get money into the hands of poor black guys was hardly one of them."

It claims that changes to the law, promoted by ACORN, made it legal to write bad loans.

A quick look at Wikipedia suggests that this might be the case:

>The [1995] revisions [to the Community Reinvestment Act] allowed the securitization of CRA loans containing subprime mortgages. The first public securitization of CRA loans started in 1997

[http://en.wikipedia.org/wiki/Community_Reinvestment_Act#Chan...](http://en.wikipedia.org/wiki/Community_Reinvestment_Act#Changes_of_1995)

NY Post or not, it appears correct. I also recommend reading this article (for a different reason):

<http://www.paulgraham.com/disagree.html>

<comment><USER2> That is EXACTLY my point. This article would have me believe that writing bad loans caused the credit crisis.

As a former quant, I can tell you that my belief is that the practice of improperly securing bundled debt is the cause of the credit crisis. When everyone began to realize that their risk analysis was off, they discovered that they held bonds or other more exotic instruments that were improperly hedged. The entire world asked for the same CDS's at the same time. That's when EVERYONE knew the game was up.

BTW, if you are a quant, or if you know your finance, I would be happy to explain why I believe the collapse in the bond market is caused by the asymmetric nature of a lot of the hedging that was going on. Or rather the total lack of hedging, and by implication, proper risk management. CDS's, CDO's and indeed derivatives in general are going to have their problems, but that is BECAUSE of improper securitization practices. We have a USD500 trillion, yes I said TRILLION, house of cards out there because of rampant misuse of these instruments. The mortgage bond market is just the place where the problems cropped up first.

I would be happy to listen to your explanation of how bad loans were the cause, but you will have to have a good explanation for two things. Firstly, explain why the bundles containing these loans were improperly secured in the first place, given that the lenders, according to the article you are citing, freely admit that they knew these to be bad loans? Could it be fiduciary negligence? Secondly, why is there so much trouble in the Jumbo market, (mortgages higher than USD417000), where CRA is not an issue at all, if CRA is the problem they are making it out to be?

I stand by my belief that fiscal negligence, and by implication, a failure to exercise the proper fiduciary duty to the companies, lies behind the collapse of ALL of these enterprises. If you have evidence to the contrary, submit it.

<comment><USER4> Do the owners of forecloses houses have to sell them? Could they hold them indefinitely as investments or even rent them? And why don't they do this?

<comment><USER2> The owner of a foreclosed house becomes the bank, or more precisely, whoever the bank sold the bond to. In answer to your question, yes they can hold it, but there are a lot of very complicated reasons not to. They involve liquidity ratios and the like. So selling makes since in a great many instances. In short, what a bank, or financial institution does with it will depend on their fiscal position. Or it SHOULD. This mess has shown us that they can behave irrationally.

</comment></comment></comment></comment></comment><comment><USER5> Most of these 'junk loans' that were made to borrowers with bad credit were resold on the stock market to third parties. The fact that lenders 1) didn't have to suffer the consequences of making bad loans and 2) financially profited from making those bad loans suggests that they had an interest in seeing relaxed underwriting standards. For this reason, I can't help but think that the author is pointedly ignoring the main contributing factor to the mortgage disaster.

<comment><AUTHOR> It's easier to sell loans that are likely to get paid back, isn't it? And at a higher price.

<comment><USER6> depends on what you mean by sell. But the way I understand it, it's way easier to sell loans without caring if they get paid back. Because then your essentially expanding your market to include 'people who won't pay back'. Bigger market means more sells. Normally you would exclude those people because you eventually want your money back with interest, but the sellers in this particular story didn't care about that. (It wasn't their money)

</comment></comment></comment><comment><USER7> Where does education and personal responsibility come into play? Just because one qualifies for a loan doesn't mean one should enter into a loan, no matter what the means of qualification. It doesn't really matter if one qualifies by some government mandate or by the lender's willingness to accept more risk, responsibility still lies with the borrower to honestly analyze whether or not they will be able to make good. In my mind, the real failure lies with our nation's inability to educate it's citizens on how to manage their own finances effectively.

</comment><comment><USER8> i won't be using the NYPost for economic analysis, thank you very much.

<comment><USER9> I'm not saying this article is right, but can you point to something specific it says that you feel is incorrect?

<comment><USER8> This article uses a classic diversion tactic - focus on a singular issue, which may have contributed, and attribute all of a complex issue to the single issue that fits the agenda.

No mention of how lending agencies, given incentives to close as many mortgages as possible, had no incentive to make sure those lenders could actually pay. The article gives no mention to how the Fed's lax monetary policy dropped interest rates and created a frenzy in housing that blocked a lot of people out unless they used non-traditional instruments.

The author doesn't say that the "anti-racist" policies are one factor (which may be true) but that these policies are the direct cause. As someone who purchased a home two years ago, I became personally aware of how low short- term interest rates combined with a housing frenzy that drove prices up over 20% a year can easily push a lot of people to get low-interest ARM mortgages instead of more stable 30yr mortgages.

I just think this article takes on a straw man because it suits an anti affirmative action agenda.

<comment><AUTHOR> So, which sentences in the article contain mistakes, specifically?

</comment></comment></comment></comment><comment><USER4> I swear that I remember a quote from Greenspan saying that low interest rates would cause a housing bubble but I can't find it anymore. Anyone have any idea what I am thinking of?

<comment><USER10> I don't know if this what you're looking for, as Greenspan was not prognosticating, but speaking in hindsight.

 _"Greenspan said in an interview with Austrian magazine Format that low interest rates in the past 15 years were to blame for the house price bubble, but that central banks were powerless when they tried to bring it under control."_

<http://www.reuters.com/article/ousiv/idUSL2146624120070921>

</comment></comment><comment><USER11> It was those damned shiftless minorities, not our commision only salespeople. A salesperson would NEVER lie to close a sale.

Thanks Sarah Silverman, for making racist humor ok for rich white people.

</comment><comment><USER12> That's just one factor among many, but symptomatic of our underlying belief that money should go to where it is "deserved" rather than where it is effective....

</comment><comment><USER13> and the reason for changing the title was ...?

</comment><comment><USER14> !NH

</comment><comment><USER15> Awesome.</comment>


BuzzFeed: An Open Letter to Ben Horowitz - <AUTHOR> http://www.mondaynote.com/2014/09/07/buzzfeed-an-open-letter-to-ben-horowitz/

<comment><USER2> The author is shorted sighted. I'm surprised so many people on HN following his thought patterns, because what Buzzfeed is doing is nothing short of classic disruption.

In a disruptive startup, you always start with a _worse_ product that appeals to a marginally group of users who'll fervently love you.

The demographic that's on Buzzfeed all the time, is the type who wouldn't be reading news anyways. So what if they look at cats and take quizes, and once in a while eyeball an article about Ferguson / Ukraine / ISIS that they wouldn't have done anyways. Look at [http://www.buzzfeed.com/world](http://www.buzzfeed.com/world), how many of those are linkbaits? How many are quality contents? It's not unimaginable that overtime, the (vegetable news) : (shitty news) ratio can increase.

Hating on Buzzfeed is like hating on Pinterest in early days because it was made for a bunch of old women, or AirBNB because it promotes unsafe and unregulated travel, or Dropbox because it promotes uncontrolled privacy by moving your stuff online. You can't please everyone all the time, so you start with a niche and increase quality overtime to appeal the the mass audience.

Why can't people accept that Buzzfeed, at its current state, isn't meant to appeal to everyone? Those who bash at Buzzfeed sound like the mindless YouTube comments on Justin Bieber's videos saying how shitty his music is. It's not for you. Don't listen to it.

<comment><USER3> the piece relies on "We never saw a down/mass market product morphing into a premium media", so yes, for him it is unimaginable.

I don't know if that is true, but if you argue against the letter you should refute _that_ argument.

<comment><USER4> Rolling Stone.

Cosmopolitan magazine.

Vice has been mentioned.

<comment><USER5> Playboy "read it for the articles" was probably the originator.

</comment></comment></comment></comment><comment><USER6> His main argument is that by funding BuzzFeed he is "contributing to intellectual decrepitude" of young readers. This is an outrageous statement. BuzzFeed started out with socially optimised content and were one of the first to recognize the power of sharing over front page habits. Today they employ many great journalists and are creating high quality content that is much easier to consume and spreads more quickly (admittedly along with some pretty banal stuff). A16Z enter the partnership based on future prospects, nothing else. BuzzFeed may or may not become a good source of enlightened reporting in the future, but at least that is their goal and they have a pretty good chance at it for a generation that mostly consumes through social media.

<comment><USER7> Exactly. Sites like BuzzFeed and Vice have some pretty trashy stuff, so people dismiss their small forays into "real" journalism as irrelevant posturing—but I don't think that's the case. In the past, quality journalists went to quality publications because the only place to find quality journalism was in a quality publication. Now, with people getting their articles from aggregators, social media and cross-linking, it's no longer important what publication a writer writes for. A journalist for BuzzFeed can write (nearly) the same article they would for the New York Times, and (nearly) the same people (within the younger audience, at least) will be able to discover it. The publication is less relevant as an institution and a brand — BuzzFeed, HuffPo and the ilk are just investors and CMS's for the work of individual writers.

Tl;dr: online news has been unbundled.

<comment><USER8> I think you're absolutely correct about the writers having potentially equitable quality, but I would challenge the following statement:

> The publication is less relevant as an institution and a brand

Journalism, and journalists, need to be trusted to deliver researched and verifiable content. This seems to be enforced because of reputation – i.e, the reputation of a publication.

When an organization does what BuzzFeed does to earn eyeballs, dollars and readership, it makes you question what they would do in more serious, "important" topics, such as describing world events to future voters.

I have trouble trusting BuzzFeed as an organization, as with Vice, due to this "trashiness". I think we all should.

</comment></comment></comment><comment><USER9> This is a perfect combination of every short-sighted, angry old media, and old man rant I've ever come across. I mean, to go from hating on BuzzFeed to somehow ending up on the "Africa is one single country and let's help it" trope is quite impressive.

Best article that sums up what Buzzfeed is really about, and why I believe it is incredible for the future of journalism is this piece by Felix Salmon. Basically, he makes the point that Buzzfeed is in effect a massive advertising agency, and their content efforts are all experiments to better understand how to reach younger people. They then make money off of selling that expertise to brands.

That is a much more sustainable, legitimate form of funding a news business vs. the world of doing anything you can to get eyeballs to your page and selling ads around it. It means constant experimentation in the fields of communication and storytelling built on the back of an incredible technology company.

The best part of the entire Filloux piece, it was Chris Dixon who led the investment (someone pointed that out nicely in the comments). Does he not even realize that VC firms almost always have internal dissension and investments aren't unanimous? He has zero way of knowing Ben Horowitz's take on the investment.

[https://medium.com/@felixsalmon/normally-when-some-big- deal-...](https://medium.com/@felixsalmon/normally-when-some-big-deal-is- announced-in-the-business-world-a-rah-rah-press-release-goes-out-236f5ae86ee4)

</comment><comment><USER10> I found this to be overly critical of Buzzfeed's content, and I believe that Buzzfeed's potential and current success comes from the content structure. I personally have faith that people are interested in consuming useful and intelligent information in order to improve their knowledge, so that they may perform better in the future for tasks like voting. With this assumption, it's amazing how much traffic BF generates with the allegedly weak quality of content that it possesses, which essentially is proof that something else must be working. Now that we have a proven structure for content, we simply need to fill in content. Isolated to one region, like the US, the content to be filled in we are all familiar with. But imagine that we expand to all regions. It must be at least an order of magnitude easier to start a news site using BF's strategy in any place, like Africa, which I would guess is at least part of the reason that a16z chose to invest.

</comment><comment><USER11> Is anybody here really convinced that buzzfeed isn't a fad? Its numbers are so badly intertwined with social media platforms that they actually depend on the continued success of the platform themselves. How is that a good business strategy?

<comment><USER12> As long as they can figure out to stay on top new social properties whether is snapchat / instagram / whatsapp / something new, I think they will do fine. Of course not the same hockey stick growth. I was reading an piece on Buzzfeed growth [http://www.inc.com/christine-lagorio/buzzfeed-secret- growth-...](http://www.inc.com/christine-lagorio/buzzfeed-secret-growth- weapon.html) . Seems like they gonna hire people just for that.

</comment></comment><comment><USER13> Wasn't this Chris Dixon's deal? I mean, I'm sure Ben and other partners had to sign off on it, but I think Chris lead this one.

<comment><USER14> Yep. Here's what Chris Dixon wrote about the deal. [http://cdixon.org/2014/08/10/buzzfeed/](http://cdixon.org/2014/08/10/buzzfeed/)

<comment><USER15> He pretends people call Buzzfeed a "toy" (like 3d printers) when in reality they call it "trash" (like tabloids). Head in sand.

</comment></comment></comment><comment><USER16> OMG. WTF. LOL. TRASH. FAIL. WIN.

</comment><comment><USER17> I looked at a16z portfolio [1] and could not find any "real" liquidity event, meaning IPO or big acquisition. There are a number of really high valuation companies, though, which are mostly based on the last round funding, often led by a16z. Now, a natural question is who exactly is benefiting from the high valuation? OK, certainly not the employees as most of them are not vested, and even if they have, they can't sell to anyone, and there is no cash dividend. The founders and top management sometimes can negotiate a better deals financially in these funding rounds [2], and in general can be resume boosters for them, so they do benefit somewhat from the high valuation. The LPs are not exactly getting anything at this time as the gain is not realized yet. That leaves the VCs who have a huge incentives to lead big rounds, as their incomes are proportional to the size of the funds they raise from LPs as detailed in this HBR article [3]. Given this dynamics, I am not surprised to see average startups with average products get funded at a hugely inflated valuation. I just hope that the LPs are investing with their own money, and are not retirement fund managers (specifically, not MY retirement fund).

[1] [http://a16z.com/portfolio/](http://a16z.com/portfolio/)

[2] [http://allthingsd.com/20111001/vcs-unite-chamath- palihapitiy...](http://allthingsd.com/20111001/vcs-unite-chamath-palihapitiya- decries-airbnbs-recent-112m-funding-for-excessive-founder-control-and-cashout- in-email/)

[3] [http://blogs.hbr.org/2014/08/venture-capitalists-get-paid- we...](http://blogs.hbr.org/2014/08/venture-capitalists-get-paid-well-to-lose- money/)

<comment><USER18> The a16z website shows the current portfolio (most recent, un-exited investment) and does not display their entire investment history. If you check out their Crunchbase profile[1], they have already had some big exits with Groupon, Zynga, Skype and Instagram, which is quite impressive since they only started investing 3 years ago. I'm sure there have been some other medium/large M&A liquidity events as well but it usually takes 3-5 years to figure out if your VC portfolio is any good and 7+ years to realize any returns. LPs know this and funds usually have a 10 year life cycle, sometimes with options to extend it a year or two [2].

[1][http://www.crunchbase.com/organization/andreessen- horowitz/i...](http://www.crunchbase.com/organization/andreessen- horowitz/investments) [2][http://www.amazon.com/Venture-Deals-Smarter-Lawyer- Capitalis...](http://www.amazon.com/Venture-Deals-Smarter-Lawyer- Capitalist/dp/1118443616/)</comment></comment>


Apple pays newspaper to intentionally mislead readers - <AUTHOR> http://www.osnews.com/story/29643/Apple_pays_newspaper_to_intentionally_mislead_readers <comment><USER2> Wow...</comment>


South African mining corporations may use weaponized drones to control workers - <AUTHOR> http://www.privacysos.org/node/1430

<comment><AUTHOR> I'm going to be a bit optimistic and say this might not be as bad as it sounds: nearly always large mass actions involve some side-violence, which results in a policeman getting a black eye or something, and is used as an excuse to bring in massive state violence to shut down the action.

A drone, however, is both inaccessible to demonstrators and, even if somehow damaged, doesn't really provide a casus belli for strategic retaliatory violence. Even the surveillance aspects aren't a real change from the status quo: in the States at least, every worker involved in a contentious labor issue has a full dossier on them about their living situation, social media presence, work hours, personal opinions, voter registration, friends and connections, put together independently by both management and unions. Being involved in a strike, of course, would definitely have been recorded.</comment>