Svelte – A UI framework that compiles into tiny standalone JavaScript modules - <AUTHOR> https://svelte.technology/blog/frameworks-without-the-framework/ <comment><USER2> Love it. I think the most discussion-worthy quote I found in the docs is this:

> _It 's currently fashionable to avoid two-way binding on the grounds that it > creates all sorts of hard-to-debug problems and slows your application down, > and that a one-way top-down data flow is 'easier to reason about'. This is > in fact high grade nonsense. It's true that two-way binding done badly has > all sorts of issues, and that very large apps benefit from the discipline of > a not permitting deeply nested components to muck about with state that > might affect distant parts of the app. But when used correctly, two-way > binding simplifies things greatly._

I wonder what the author considers "used correctly" and "done badly" and how Svelte approaches this.

<comment><USER3> My understanding is that there are two issues with two-way binding that are structural, and will be difficult to fix no matter how you approach it.

First is that if you look at the system as a graph of updates, automatically closing all cycles between variable update and widget means that any additional two-way binding links you add become a cycle, which makes it difficult to implement, model, and debug. If the framework only initially links the variable to the widget or the widget to the variable, the graph is a lot less populated to start with and creating a cycle is much harder.

Second is that the developer ends up wanting more and more complicated transforms over time, and having to implement both directions of them at once is much more difficult than having to implement only one direction, because not only are you writing two transforms instead of one, you _also_ really ought to make sure the transforms are able to be roundtripped without data loss, and also that any invalid states on either side of the transform are handled sanely in some manner. Very few developers think this way; it's one of those places in programming where you really need to approach it with a mathematical state of mind, but it's generally being written by the "I don't see how programming is connected to math" types. (Which is something a two-way binding advocate needs to keep in mind when writing their library; you're not going to get your users to deeply understand the way the library works before they can benefit from it, they're going to want to just dive in and get something useful going.)

These are not necessarily insurmountable problems, but they are _fundamental_ problems to having two-way binding. I think these two things are why it has never really taken off despite the fact I've seen at least half-a-dozen attempts over the years. I can imagine programming language tools that could help with both problems, but as what I'm seeing getting sketched up in my head requires a type system at least as strong as Haskell's to be practically usable without so many holes as to be insignificantly different from what we already have, it's not going to take off anytime soon.

<comment><USER4> This is a really helpful way of describing the problem. Concretely describing behavioural coupling in terms of graphs is much less hand-wavy than the normal, "things become tightly coupled and which becomes hard to deal with."

<comment><USER5> That's the core of it - 2 way data binding creates tight coupling.

</comment></comment></comment></comment><comment><USER6> TodoMVC is a useless benchmark for the problem that this claims to be addressing. The limits we're hitting with our applications now are with BIG applications, with many routes, many views, and lots of client side logic. We're talking hundreds of files (in some cases, thousands). Of course a framework, with it's fixed overhead, is going have a bigger payload for a tiny demo app like TodoMVC, than something like this which compiles to some amount of overhead which grows seemingly linearly with application size.

That said, I'm not criticizing the framework here, and I welcome new ideas, but a better choice of benchmark is sorely needed to be persuasive here.

<comment><USER7> Are there any alternatives to TodoMVC out in the wild?

I rather like [https://github.com/staltz/flux- challenge](https://github.com/staltz/flux-challenge) myself, but I wonder if there are any other projects that are focused on more complex examples.

<comment><USER8> The 7-GUIs suite looks better, but so far only one JS framework implements it. The problem with more realistic benchmark apps (or suites) is that they require more effort to implement, so you have a selection bias towards easy- to-implement yet too-small-to-be-useful demonstrations like TodoMVC.

Something like a GmailMVC would be better.

[https://github.com/eugenkiss/7guis/wiki](https://github.com/eugenkiss/7guis/wiki)

</comment></comment></comment><comment><USER9> > You can't write serious applications in vanilla JavaScript without hitting a > complexity wall.

This somewhat annoys me. You _can_ definitely do it.

Sure, it's easier, more comfortable, safer and quicker to use something like React. But you can still do some modularization that scales reasonably well without it.

I've been working on an app and spent a lot of time looking into frameworks to handle its complexity but ended up sticking to vanilla JS to keep more control, especially for detail optimizations.

<comment><USER10> You can if everyone in the team is at least pretty good

<comment><USER11> 'pretty good' sounds like a doable metric for a small team.

</comment></comment></comment><comment><USER12> This looks nice: a Javascript framework for expressing _concepts_ that compiles down to vanilla JS. It looks like it ships a lot less code to the user. From the project's first [blog post]([https://svelte.technology/blog/frameworks-without-the- framew...](https://svelte.technology/blog/frameworks-without-the-framework/)):

> The Svelte implementation of TodoMVC weighs 3.6kb zipped. For comparison, > React plus ReactDOM without any app code weighs about 45kb zipped. It takes > about 10x as long for the browser just to evaluate React as it does for > Svelte to be up and running with an interactive TodoMVC.

<comment><USER13> I didn't study the thing, but the first question that comes to my mind is: if each component is rendered as a self contained piece of vanilla js, isn't the size of an app with lots of components going to increase much faster than with the library approach?

A complete library by itself can be pretty big, but it stays the same size no matter how many components you add.

<comment><USER14> Good point. I tested the demos and found the output (compiled down to ES5 and minified) is around 2-3KB for the minimal demos, and 9KB for the complex SVG clock demo.

The equivalent JSX output for that clock demo is about 1KB. So yes, I would guess that apps with many components would end up bigger (in total JS bundle size) than equivalent React apps.

Possible counterarguments:

\- Bundling and gzipping several Svelte components together might compress well – a lot of their size comes from repetitive substrings like `.parentNode.removeChild` and `.setAttribute` etc.

\- Once downloaded, the Svelte approach would probably be faster than React (at both rendering and updating) and would use less memory (no virtual DOM, no diffing, just fast granular updates).

\- The self-contained nature of Svelte components makes it easier to treat them as atomic downloads and use them as needed. For example, you could get to a working UI extremely fast, and then download more components for below-the- fold or other pages in the background. This could work well with HTTP/2.

<comment><USER15> Storing state in Dom and reading from it could be dangerous. It's very easy to force layouts when you don't need. Frameworks like react and preact essentially do this. Abstract updating the view in a performant manner. Preact is 3kb. Magnitudes smaller than React.

<comment><USER14> I don't think it stores state on the DOM and reads from it. Pretty sure it just stores state in an object, and it updates the DOM granularly when that state changes. (That said, I did notice a bit of DOM traversal (node.parentNode...), which doesn't count as reading state from the DOM, but does rely on the structure of the DOM not having been altered by someone else since the last render – not sure why it needs to do this.)

</comment></comment></comment></comment></comment><comment><USER16> Love the ideas.

I think now the community has settled on the Component based development, especially with JSX templates.

What we need are multiple _react-kernels_ implementations. I see React community providing component API specs. Similar to Linux distros, we should have API compatible implementations, where application code can run on multiple kernels without any changes. We are now seeing multiple react-shim layer implementation - Preact [0], Inferno [1].

[0] [https://preactjs.com](https://preactjs.com)

[1] [https://github.com/trueadm/inferno](https://github.com/trueadm/inferno)

<comment><USER17> Totally agree. I just can't see myself going back to templates with special DSL. I rather just use JS :)

</comment></comment><comment><USER18> The precompilation is a nice idea, but I'm not buying the "vanilla JS" argument. The reason why React and other frameworks have a runtime is also because they optimize rendering.

The Svelte doc says: every call to `component.set()` produces a synchronous DOM update. I can already see how this leads to very poor rendering performance in applications with a large number of nested components.

React and the Virtual DOM solved this problem, and that's why web apps today use a lot of components. So until Svelte can demonstrate fitness and speed comparable to React on large apps, it just looks like Yet Another JS Framework.

<comment><USER19> Haven't studied the SvelteJS documentation but as far as I can reason there is nothing in their idea that prevents them from shielding the DOM behind a lightweight, virtual DOM, ReactJS style. In fact, I'd be slightly disappointed if they don't shield the DOM somehow. It's the #1 bottleneck, after all.

<comment><USER20> The virtual DOM isn't a replacement for the DOM, it's just a string diffing algorithm. It is only needed because of React's "render everywhere" approach, which is a tradeoff sacrificing efficiency for simplicity. If you don't re- render the entire page any time the model changes, you don't need a virtual DOM.

<comment><USER21> I'd say your mostly right with the one caveat that a virtual DOM also helps out with batching changes to the DOM, but I suppose there are other ways to make that happen.

</comment></comment></comment></comment><comment><USER22> [https://svelte.technology/guide](https://svelte.technology/guide)

For how it actually looks.

Interestingly, it shares most similarities to vue. I guess vue is winning mindshare.

<comment><USER23> It's based heavily on Ractive ([http://ractivejs.org](http://ractivejs.org)), which Vue is very similar to.

<comment><USER24> Should users evaluate both Svelt and Ractive, or should Ractive be considered deprecated in favor of Svelte?

</comment></comment></comment><comment><USER25> Precompilation is cool, but please don't imply that your framework is the first to do it. Precompiled templates significantly predate HTML, they were common in the mainframe world. In the HTML world there are tons of other templaters that allow precompilation. Handlebars is a common one: [http://handlebarsjs.com/precompilation.html](http://handlebarsjs.com/precompilation.html)

This is a huge part of Javascript fatigue for me. I love the fact that we're recycling old concepts and mashing them up to get constant improvements and better tooling. It's the relentless hype and pretending that everything is new that really gets to me.

<comment><USER14> Handlebars templates have a runtime dependency (even when precompiled). Svelte does not.

Also, a precompiled Handlebars template is just a function for outputting an HTML string (with a runtime dependency). By comparison, the compiled Svelte output is a dependency-free JavaScript module for a dynamic view, which knows how (and when) to granularly update the browser DOM in response to state changes. It's unprecedented.

Check out the output from this SVG Clock demo: [https://svelte.technology/repl/?gist=44e20b4e0224617d228e3c3...](https://svelte.technology/repl/?gist=44e20b4e0224617d228e3c38c119ee76)

<comment><USER25> Svelte has a runtime dependency too, it's just bundled into the output. Everytime I've used handlebars I've bundled the runtime into my final application file. But I do it myself so it only gets bundled once rather than N times like it would be for svelte.

<comment><USER26> See the `update` method in the output of the Hello World example:

        update () {
            text1.data = root.name
        }

This is _the entire DOM manipulation code for this component_.

There is no runtime library. The trick here is that the generated code is aware of exactly _what_ DOM updates are needed. Instead of a large, general- purpose reconciliator like React's, you have specialized code for changing the DOM, generated from your templates.

</comment></comment></comment></comment><comment><USER27> > It's basically as fast as vanilla JS, which makes sense because it is > vanilla JS – just vanilla JS that you didn't have to write.

What kind of logic are they using here? Isn't any javascript just vanilla JS?

<comment><USER28> The way I see it is Svelte treating the browser JS implementation as "machine code": while frameworks such as React or Vue are by definition a (runtime) layer on top of vanilla JS, Svelte _compiles_ your code to vanilla JS.

It's a very slight but interesting distinction.

</comment></comment><comment><USER29> React fanboy chiming in to say... an interesting approach to what is probably a problem.

i wonder, though, if compilation is really better than creating a library? if we look at the REPL output [0], we can see what comprises the bones of a Svelte component, and how much generated code will be replicated.

it also shows that the more interesting part here is it's method for rendering. it's use of data binding and compilation means we don't really need something like VDOM to stay efficient (at least, not a VDOM running in the browser).

[0] [https://svelte.technology/repl/?gist=0ed5146aa22c28410dfcff2...](https://svelte.technology/repl/?gist=0ed5146aa22c28410dfcff2050f3d2f8)

</comment><comment><USER30> Why didn't we think of this sooner?

Because we did! For instance, this is exactly the approach that we have released back in 2009 with [http://opalang.org](http://opalang.org)

Naturally, there are things we would implement differently today, but the OCaml codebase of the compiler is still, in my humble and biased opinion, pretty valid.

<comment><USER31> is opa still alive and being used? i was pretty excited about it when it was released (especially when it still had the ML syntax), but it never seemed to gain any traction.

<comment><USER30> Thanks zem! Yes, Opa is still used in several projects and pretty stable. But the project is asleep and not very active as of now.

</comment></comment></comment><comment><USER32> I like how they solved scoped css. Looks way more elegant than most css-in-js solutions I've seen. I could give it a shot for this reason alone.

<comment><USER33> Always one of my favorite features of riotjs

</comment></comment><comment><USER34> The 'Mustaches' bit killed it for me, but up until then I was enjoying the simplicity of the API. I like React (and React-like implementations) because of being able to use JS to build up a view

<comment><USER10> Yeah, same. Can't give up JS/TS templating and typesafety. simply for a smaller size, I already use something that is way, way smaller than react.

<comment><USER34> I'm curious, what do you use?

<comment><USER10> In the past, I used virtual-dom. It works fine, but it's discontinued and doesn't address the problem of encapsulated component state. Now using this: [https://github.com/AlexGalays/kaiju/](https://github.com/AlexGalays/kaiju/)

</comment></comment></comment></comment><comment><USER35> Looks neat, but also like a non-standard implementation of Web Components, which, though slow coming, already have universal browser support with a small shim.

What's the advantage of this over something like Google's Polymer library, which is a toolkit for rapidly creating reactive web components?

<comment><USER10> Polymer is an enormous library.

<comment><USER35> Polymer offers a lot of UI widgets, which are enormous when you glob them together, but the base polymer library is actually incredibly small due to the fact that's it's leveraging the browser's native custom element functionality.

Can't reply to your comment so editing here:

Works natively on IE11+, Edge, Safari 9+, Chrome, Opera, Firefox, and mobile browsers. The polyfill for everyone else (webcomponents-lite.js) is 41kb.

<comment><USER10> Ok, it has been some time since I checked. Don't you need lots of big polyfills ?

<comment><USER36> No - 95% of time you need that webcomponents-lite to get things working.

</comment></comment></comment></comment></comment><comment><USER37> Isn't the problem of including only the code the component actually needs already solved with dead code elimination? So the framework authors can include new features but as long as your component doesn't use them the code for those feature does not end up in the final bundle you serve to the user.

I sure am missing something here because the author of Svelte is actually also the author of rollup.js [1] which does exactly that, it eliminates dead code via its tree-shaking mechanism.

[1]: [http://rollupjs.org](http://rollupjs.org)

<comment><USER19> As far as I understand, ReactJS is a tightly weaved 40kB chunk of code which will be delivered to the browser no matter how ferociously you shake the tree.

</comment></comment><comment><USER38> Pretty neat demo of Svelte for the home assistant project:

[https://twitter.com/balloob/status/803882259719696384](https://twitter.com/balloob/status/803882259719696384)

And the actual code:

[https://github.com/balloob/home-assistant-svelte- prototype](https://github.com/balloob/home-assistant-svelte-prototype)

</comment><comment><USER39> Vue.js has single file components [1] and template precompilation [2] (or optionally JSX support, which is basically a precompiled template).

I don't see the point of yet another framework here.

The "no dependencies" argument seems to fall down for me, since it would seem to me that they would need to duplicate a lot of code for state management and rendering, bloating the code for anything more complex.

And if there's some clever tree shaking or whatever going on, than I don't see the point as opposed to just including another JS file...

I couldn't find any explanation of what's so different here, worthy of creating another framework for it. Would love to be enlightened!

[1] [https://vuejs.org/v2/guide/single-file- components.html](https://vuejs.org/v2/guide/single-file-components.html)

[2] [https://www.npmjs.com/package/vue-template- compiler](https://www.npmjs.com/package/vue-template-compiler)

<comment><USER23> As well as generating smaller apps and being quicker to load, Svelte is significantly faster than Vue. We'll be publishing benchmarks soon.

<comment><USER39> I'd love to see code size and performance comparison for a relatively simple but non trivial component, like a DateTime picker.

<comment><USER23> Yep, we'll be adding more examples soon – definitely on the TODO list. In the meantime you can take a look at our TodoMVC implementation – it's 3.6kb zipped (Vue is 17.2kb without any app code. Not a criticism, just context)

[https://svelte-todomvc.surge.sh](https://svelte-todomvc.surge.sh)

</comment></comment></comment></comment><comment><USER40> I like the idea of abstractions that exist only in the source code and at compile time, and have zero runtime footprint.

How does this compare to Google's Closure compiler and library? Does Svelte's compiler do anything that the Closure compiler cannot? Or how about running the source through a hygienic macro system like sweet.js and feeding the output of that to the Closure compiler?

I ask because I'm skeptical of a new, unproven compiler. Google has been using the Closure compiler on production code for years, and its optimizations are pretty awesome.

<comment><USER10> But the google closure compiler have no concept of a tree of components and their lifecycle. The library is old, java-like and I never heard about someone using it :p

<comment><USER41> Don't quote me on this but I'm pretty sure gmail uses it. I'd say that's a pretty big endorsement.

<comment><USER42> From what I've read, also Docs/Drive and Maps.

It IS old (well, 2009 counts as old I guess), but it's still maintained, and still doing what it says on the tin. That's quite an achievement in and of itself.

<comment><USER41> Yeah I think I read it here: [http://shop.oreilly.com/product/0636920001416.do](http://shop.oreilly.com/product/0636920001416.do)

</comment></comment></comment></comment></comment><comment><USER43> This looks interesting. For the past 3 years I've been using ractivejs and really enjoy it.

I'm wondering if Svelte will take away development efforts from ractivejs?

OT >The web's obesity crisis, solved. Svelte turns your templates into tiny, framework-less vanilla JavaScript.

Made me think of [idlewords][1] website obesity presentation...

[1]:[http://idlewords.com/talks/website_obesity.htm](http://idlewords.com/talks/website_obesity.htm)

<comment><USER44> I think Rollup already took time away from Ractive. It's really too bad, I think Ractive has some great ideas and I really enjoyed working with it. It was the best way to build web UIs I've come across. But I feel its future is uncertain so it's hard to recommend others begin using it.

<comment><USER45> > _I feel its future is uncertain so it 's hard to recommend others begin > using it._

Self-fulfilling prophecy unfortunately.

<comment><USER44> Perhaps, but at least to the team I was working with at the time, Rollup indicated we shouldn't expect much to change or improve in Ractive. I think Ractive was partially a victim of timing; as Harris himself has said, it has many of the same ideas as React and he may well not have made it if React existed when he began. And it never really seemed to gain much popularity which you kind of need for a project to grow beyond just its creator. I still haven't investigated this new thing, but if it was indeed inspired by Ractive that gives me hope.

<comment><USER43> >but if it was indeed inspired by Ractive that gives me hope

Actually, I would like to see the author's thoughts on ractive vs svelte. From the outside svelte is very reminiscent of ractive.

[EDIT] +\n

</comment></comment></comment></comment></comment><comment><USER46> Out of topic, is low contrast and small fonts become a thing? I can barely read anything from my 13-inch notebook with 45cm distance between my eyes.

</comment><comment><USER47> Why are there complex MVC frameworks that run in the browser in the first place? I might get some flack for this, and I'm prepared for it, but why can't we use JS as just a view manipulator? Leave data processing and business logic to the back-end, on the server, and that can take care of needing a front-end framework and large app.

<comment><USER48> "Why waste energy doing stuff on your machines what you can get your users to do for you?"

...is the general reasoning. However, personally, I find that unless you're _very_ well organised, you're not saving yourself much, if anything, in the long run.

<comment><USER49> That reasoning quickly falls apart when you throw a cache in front of your backend.

</comment></comment></comment><comment><USER36> Why would I use this vs established and polished project like Polymer that already has a big ecosystem of components for reuse?

<comment><USER50> If that's your requirement, you wouldn't. But every project has to start somewhere.

</comment></comment><comment><USER51> So this is like GWT, minus Java? GWT's treeshaker removes dead code and outputs fat-free plain JS.

<comment><USER10> GWT was backend oriented and sucked at delivering a nice UX in a decent timeframe. So it's actually extremely different. You could compare this to vue, ractive + a strong compilation step.

</comment></comment><comment><USER52> So apparently Svelte JS framework already exists. So many frameworks, you need to start asking which one.. :)

[https://github.com/mattbegent/svelte](https://github.com/mattbegent/svelte)

</comment><comment><USER53> Rich Harris created RactiveJs, which is an awesome UI framework on its own right.

<comment><USER54> Rich Harris also created rollup and buble.

He's an inventing and implementing machine.

</comment></comment><comment><USER55> This looks a lot like another JS library that was posted here previously: [http://monkberry.js.org/](http://monkberry.js.org/)

Both compile templates to DOM manipulation code.

</comment><comment><USER56> That seems quite amazing, especially the todo example being over 10 times smaller than the React one. Are there any drawbacks to this approach?

<comment><USER10> To be fair, there are today numerous frameworks that are 10 times smaller than react and can do roughly the same things.

Drawbacks would be maturity, community size, template closed expresiveness and not typescript friendly. Nothing too major.

</comment></comment><comment><USER57> Mores like Sass for JS. exactly what we need!

</comment><comment><USER58> This compiler sounds similar to me as the Ahead-of-Time (AoT) compiler currently shipped in Angular 2.

</comment><comment><USER59> We move React to Svelte at work. We saw a huge file size decrease. almost 50%.

<comment><USER60> Why exactly did you choose to move to a framework that, according to it's commit history, had its first commit 15 days ago?

Why are people porting apps to a framework that is a few days old?

I find it very difficult to believe that your app, with it's 50% size decrease, has any more complexity than a todo app.

Just, why?

<comment><USER59> We want cleaner approach in writing code. We like inferno and riot, but we choose Svelte. Results have been amazing.

<comment><USER61> When did you find out about the framework? How did you find out about it?

</comment></comment></comment></comment><comment><USER62> This looks like a very stripped down Ember.js - it also looks pretty awesome.

</comment><comment><USER63> Where is this being used right now in production?

<comment><USER64> Likely nowhere yet, seeing as Svelte is four days old (give or take a few hours).

</comment></comment><comment><USER65> how about porting this to scalaJS? would be awesome to use scala's typechecking on this (especially on template strings)

</comment><comment><USER66> [http://dayssincelastjavascriptframework.com/](http://dayssincelastjavascriptframework.com/)

<comment><USER67> does it ever goes higher than 0?

</comment></comment><comment><USER68> How is this substantially different from Backbone/Marionette? I feel like we're regressing.

<comment><USER10> Because it has data binding.

You only write your template once, you don't have to think about two separate paths: creation and update. With backbone, you either did that and had performance issues or did updates separately, which is a pain to maintain.

Also, in backbone, parent<->child communication is a complete after thought.

</comment></comment><comment><USER69> Is it possible to filter out all JS/Framework stuff from the hn feed?

Asking for a friend.

<comment><USER70> Write a some JS for a userscript?

</comment></comment><comment><USER71> Are there any apps currently made with this?

</comment><comment><USER72> A side note about that website. Thin and Extra-Thin fonts have no place in web design (there are some exceptions in huge title text). They are an unnecessary burden for people with limited eyesight and elderly people[1]. Even for me, on my 1366x768 screen (which is still the single most common resolution for cheap notebooks, dear HiDPI web designers[2]), the bullet text is hardly readable, the copyright line is completely unreadable. This effect is made even worse by choosing inadequate contrasts[3]. One can use subtle colors for increased contrast.[4]

[1] [http://www.aiga.org/typography-and-the-aging- eye](http://www.aiga.org/typography-and-the-aging-eye)

[2] [http://blog.typekit.com/2013/05/01/hi-dpi- typography/](http://blog.typekit.com/2013/05/01/hi-dpi-typography/)

[3] [https://www.nngroup.com/articles/low- contrast/](https://www.nngroup.com/articles/low-contrast/)

[4] [https://www.viget.com/articles/color- contrast](https://www.viget.com/articles/color-contrast)

<comment><USER73> Create an issue here: [https://github.com/sveltejs/svelte.technology](https://github.com/sveltejs/svelte.technology)

or submit a pull request

<comment><USER74> Not sure why you were downvoted, I think it's entirely reasonable to bring up his concerns in an issue regardless of whether they are eventually implemented.

</comment></comment></comment><comment><USER75> I love the ideas.

The only other thing I like is CSS scoping, though. I think that CSS scoping is a problem in React, and current ideas on how to implement that in React are absolutely horrible IMHO.

Two-way binding is a step back I think, I don't love the name (lots of people will judge a new technology by its name), and the thought of introducing yet another framework is a nightmare.

I'd personally go with Polymer if you like scoped CSS, since it's already established and it's a good project.

I wonder if these ideas can be somehow applied to React, doing precompiling on React components, so that one can continue taking advantage of all freely available React components out there, and keep using Redux.

<comment><USER23> > Two-way binding is a step back I think

You don't have to use it – its effects are restricted to the subtree where you've explicitly opted in to it. I've personally found it to be a huge timesaver, and would never go back to a world where I didn't have the option of using it. But you're in no way forced into it.

> I wonder if these ideas can be somehow applied to React

A lot of people have wondered that, including me. Unfortunately, a compiler wouldn't be able to generate a good picture of the _structure_ of a JSX component – because it's 'just JS' it resists the kind of meaningful static analysis that Svelte can take advantage of. I'd love to be proven wrong, but sadly I just don't think any JSX-based framework will ever be able to fully embrace these techniques.

<comment><USER75> Got it. I've been reading the guide, it looks good.

You did an awesome job.

I'm really scared about trying out yet another framework since I've tried pretty much all of them before settling on React, (and I guess a lot of people will be, too, since there's a new one every couple of months) but I'll try this weekend.

Thanks!

</comment></comment></comment><comment><USER76> So I've just wrapped up using React + Redux and just begun to uneasily accept JSX.

It makes me uneasy because React wraps up existing HTML with Javascript. Because it violates using existing, established standards that have truly stood the test of time and wasn't broken at all.

Svelte really hits that sweet spot.

<comment><USER77> I believe most of the brokenness of current day frameworks comes from templates. Here is what you get by JSX being JavaScript:

1\. Easy to write typechecking for the templates.

The compiled template is just function calls (or well, factory function calls) and the typechecker can work with that.

How many template language authors will write a typechecker for the template language?

2\. Sane scope sharing - you can take advantage of all existing encapsulation and modularization tools of JavaScript. How do I expose functions to JSX? I simply bring them in scope e.g. by importing them or defining them. How do I expose functions to the template? Well... it depends. There is this $scope object (Angular)... Or there is this components property which informs the template whats in scope (Vue: [https://vuejs.org/v2/guide/components.html#Local- Registratio...](https://vuejs.org/v2/guide/components.html#Local- Registration)). I guess there are worse options, like having to register your helper functions or components into some sort of global registry and pray that there wont be a conflict.

3\. First class components - want to write a list component that takes an item component as a parameter in props? Tough luck, its likely that the template language of your average framework doesn't support this. JSX gets this for free because its just JavaScript, and JavaScript is a proper language with first-class support for passing around functions and classes.

Its not that its impossible to do this... its just that most template languages aren't advanced enough, and somehow we think thats a good thing.

4\. The sandboxing fallacy

From [https://angularjs.blogspot.co.uk/2016/09/angular-16-expressi...](https://angularjs.blogspot.co.uk/2016/09/angular-16-expression- sandbox-removal.html)

      Angular template, and expressions, should be treated
      similarly to code and user-provided input should not be
      used to generate templates, or expressions

If you are distributing the compiler with your framework, there is this urge to expose it to the developers. If you expose it to the developers, there is the chance that it will end up compiling user input. And then you spend ungodly amount of time building a sandbox, unsuccessfully.

-

svelte seems to be built by people with deep interest and expertise in compilers, so I'm somewhat hopeful that its template language will not suffer from the usual template language problems. On the other hand, the task is much harder (compiling to code without runtime), so that seems like a driving force in the opposite direction (less powerful template language). I guess we'll see how it goes.

IMHO the next step in frameworks isn't this (compilers are hammers, and everything else is nails). The next step is, after current frameworks fight things out, we take the common subset of the "infrastructure code" that the most popular ones use (DOM diffing? events that are the same across browsers to remove the need for synthetic events? PropTypes? Maybe someone at whatwg should start thinking about this list) and include it in the browser API, then let frameworks build on top of that and be 10 times smaller on average.

<comment><USER76> Thank you for the detailed answer, I have a few questions here but I think you've nailed it for the most part, I'm just trying to gauge how well I understood what you wrote.

1) what is meant by type checking in this context? do you mean that now that HTML is converted to JSX in JS context, you can test HTML as if they were Javascript Objects?

2) so the ease of importing functions to JSX + use of existing "encapsulation and modularization" (I'm not sure what this menas) libraries.

3) what makes it difficult to support it from templates point of view? JSX is easier because?

4) why is sandboxing harmful? how does giving developers compilers create sandbox fallacy?

With the last paragraph, you are saying that the lowest common denominators such as DOM diffing will become a common cross platform feature in all browsers?

<comment><USER77> By type checking I mean something like typescript which is able to statically verify whether the right types of attributes are passed to the right component, or whether expressions embedded in the template are of the right type.

Re encapsulation, the way that JS provides it is scope. JavaScript's lexical scope ensures that things you define in a function are only visible in that function, or that things you define in an ES6 module are only visible in that module. Even with the tiny quirks of function based lexical scope, its natural and intuitive: if you can see the definition (or import) in the (function/module) parent(s) of the code you're looking at, its available. Its a tried and true solution.

Template languages don't always bother to add something like "import" or the concept of lexical scope, so when you want to share something from JS (or other templates) with them (like data, or processing functions, or components) you need to somehow put it in their own custom scope. Many template based frameworks make the mistake of working around this not by adding import mechanisms to the template language, but by registering things globally - e.g. when you register a component in Angular or Vue it becomes globally available. This has the same problem any other global variables have. (I suspect this in Angular 1 is what led to the totally parallel "module system" with dependency injection, although maybe they just didn't like the existing ones)

Regarding supporting first class components in template languages, its not really that difficult. Its just that we believe the fallacy that we need the template language to be underpowered. Also, once you add support for first class components and JS scope sharing (or at least import/export) mechanisms to a template language, you've basically reinvented JSX (perhaps with a different syntax)

Sandboxing isn't harmful, its just extremely hard. Angular spent years trying to write a proper expression sandbox and every new version of it was broken successfully - thats why 1.6 removed the sandbox.

What I'm hoping for is that someone works out what contributes the most to popular framework's size, takes the common parts and provides them as built in API in the browser in such a way that the frameworks can take advantage of that instead of writing their own implementations.

</comment></comment></comment></comment><comment><USER78> i wonder if it would be faster if it compiled all the html down into a kitchen sink file.

does it try and do as much as it can without javascript?

</comment><comment><USER79> > You can't write serious applications in vanilla JavaScript without hitting a > complexity wall.

 _closes tab_

</comment><comment><USER80> Oh.. and another one.

</comment><comment><USER81> [https://xkcd.com/927/](https://xkcd.com/927/)

</comment><comment><USER82> I can not keep up with all the new X flavored js frameworks, where X is [React, Angular, Vue, Mithril, Redux, Mobx,...]. This is exactly why I chose Clojurescript for my pet stuff and with hopes, that I will be able to use it for making money too. Learning curve can be steep for someone not used to functional way and/or lisp, but at the end you get a very mature, simpler and consistent language with great tooling. Figwheel workflow is just awesome. Well worth the time.

<comment><USER83> I cannot keep up with random javasscript frameworks... therefore I use [random framework in some other language]...

<comment><USER82> It's not that I cant, I don't want to do it anymore, sorry I didn't express myself correctly above. And there aren't that many client side framework choices in Clojurescript, which I see as an advantage. But not everyone will see it that way, I can understand. Whatever makes you happy.</comment></comment></comment>


Fantasy Cricket Anyone? - <AUTHOR> http://blog.howzatnow.com/2013/06/fantasy-cricket-anyone.html

<comment><USER2> We've tried to take a fresh perspective on fantasy cricket. Encouraging you all to take a look and provide your feedback and suggestions. Its been a fun journey trying to do this while having a full time job. Reply back if you are interested in finding out about our technology stack or anything interesting like that.</comment>


Ask HN: Where does the liability for actions by an AWS server lie? - <AUTHOR>

If a user misuses a AWS provisioned EC2 instance (such as hosting copyrighted material without permissions), does Amazon have a liability here? What if a user on an app/infrastructure (Heroku) using AWS misuses his/her instance? Is there any liability faced by Heroku/AWS? <comment><USER2> They provide infrastructure, so they're no more liable than a phone company when you commit fraud over the phone.</comment>


9 things to know about CAR T-cell therapy - <AUTHOR> https://www.mdanderson.org/publications/cancerwise/2018/02/car-t-cell-therapy--9-things-to-know.html?invsrc=display&cmpid=BRD_CW_GEN_EMAIL_WEBMD_TRG_CC_CUS#.WyDJwtxPawM.hackernews <comment><USER2> >>> The data is still evolving, but after 15 months, 42% of adult lymphoma patients who received CD19 CAR T-cell therapy were still in remission.

Is it me or this means we're pretty far from having "cured" a cancer ? (even if 42% may be super good news in contrast to what we had before, I'm no specialist)</comment>


Weapons made with 3-D printers could test gun-control efforts - <AUTHOR> http://www.washingtonpost.com/local/weapons-made-with-3-d-printers-could-test-gun-control-efforts/2013/02/18/9ad8b45e-779b-11e2-95e4-6148e45d7adb_print.html <comment><USER3> We've had a problem over the last decade or so: how do governments deal with populations where the individuals have more and more power?

America has traditionally been more libertarian than most countries, so the crisis isn't as bad here, but we still see the signs. We're outlawing doing certain kinds of reverse engineering, we're making copyright violations a criminal offense, and so forth. (Most of our government reaction has been in the form of protecting large industries).

Some other countries are seeing crackdowns on where you can go on the internet, who you can talk to. To those countries, individuals simply having the power to gather information is too much for them.

I hate to make cataclysmic predictions, but I think the U.S. is going to get pulled more and more into your house and head. Where you surf, what you consume, what kinds of things you print on your 3-D printers. 3-D printing is the thing that is going to change everything, because now we can _make_ whatever we need without having to rely on established patterns of commerce (which the government can control).

If it helps any, I don't think this is some sort of deliberate power grab. Quite frankly I don't think the people we have running things are anywhere near qualified enough to be making the decisions they are, On top of that, we have no examples throughout history of a government with the ability to control and monitor so much of each person's life. There's no precedent.

3-D printing, to me, is the one tech that over the next 50 years or so will dramatically change everything. Robots are a close second. Fun times to be alive! (Or perhaps a more accurate word than "fun" would be "interesting")

<comment><USER4> It'll be even more fun when argiculture and currency become distributed. I know that we already have bitcoin but imagine if it entered the mainstream. The powers that be would be reeling since they would effectively no longer be relevant and would have very little influence left.

Personally, I think that this is all going to cause today's authorities to become increasingly violent until they collapse as a result of the new ways making them obsolete. Then we just might see another golden age for humanity. My forecast is thunderstorms followed by bright sunshine.

<comment><USER5> I think you're right, particularly when it comes to currency. Currency is the absolutely pinnacle of power of modern governments. Loss of that power means weaker governments. Most people don't realize that for much of the USA's early existence, currency was essentially outsourced to the Spanish Empire in the form of silver coins.

</comment></comment></comment><comment><USER6> More sensationalism about 3D printed guns. People, please - nobody is going to be printing a functioning gun purely out of ABS plastic on a <$1k hobby printer for a long time(if ever).

The only people who might be printing guns(requiring pretty rigorous touchup after the printing process) are those with access with extremely expensive printers that can print metal.

I sincerely hope this doesn't lead to regulating 3d printing into oblivion. Just like the entertainment industry wishes it got the jump on filesharing, I'm sure big manufacturing is prepping its lobbying efforts.

<comment><USER7> Yes, the fact the article refers to > than 1k (but still not terribly expensive) printers using 'advanced polymer' instead of ABS makes it yet another article about using pure ABS plastic on a sub-1k printer...

I'll agree that metal is probably a requirement for a barrel. But barrels are not controlled or restricted. Neither are magazines, which we know can be printed already with some success.

<comment><USER6> I'd love to see some 'advanced polymers' that can handle the stress of a caliber greater than .22LR(which is what Defense Distributed tested with), while simultaneously being printed with the precision necessary from a printer costing <$10k.

It's also worth pointing out you can already buy all of the components necessary to assemble your own firearm, all without a serial number. I think the deeper issue here is, as another comment pointed out, there are entrenched interests promoting this hysteria to garner public sentiment for regulation by making the scary applications glaringly obvious and overshadowing the beneficial implications of the technology.

<comment><USER8> _It's also worth pointing out you can already buy all of the components necessary to assemble your own firearm, all without a serial number_

Not exactly true. Every legal gun has one part with a serial number that defines the gun legally. Usually (always?) it's the receiver. There are some grey areas where you can get an almost finished receiver free of regulation.

<comment><USER7> The comment was referencing the fact that you can make a gun for yourself without a serial number as long as you don't sell it or do anything with it that is defined as 'transfer.'

</comment></comment></comment></comment></comment><comment><USER9> It's almost a year old, but Scott Locklin's comments are still pertinent, especially since it discusses the AR-15 which the Washington Post article discusses.

[https://scottlocklin.wordpress.com/2012/08/11/bad- engineerin...](https://scottlocklin.wordpress.com/2012/08/11/bad-engineering- journalism-reporting-on-3-d-printing-of-guns/)

<comment><USER6> Thanks for posting this, very insightful comments on there.

</comment></comment><comment><USER10> Why is 3D printing a gun any different to making one with machining tools? Surely the same laws should apply, and this is just an advancement of home- manufacturing technology that has no real involvement with gun laws.

<comment><USER11> It's relatively easy to manufacture most of an AK-47 using machines that are affordable and that fit in a garage (the exception being rifled barrels, but those are relatively easy to find). In the US, it's also perfectly legal, as long as the firearm is not capable of automatic fire. If you have a CNC mill, you can make your own AR-15 (again, you'll probably have to buy a barrel).

The "OMG people will print guns" stuff is just hysteria and grandstanding.

<comment><USER8> You're overstating the ease with which you can create a rifle with machine tools. While it can be done, it is both time consuming and very difficult to do in a home shop, or even a proper shop.

 _If_ 3D printers could print materials with the appropriate structural characteristics (a huge if), it would be much easier.

I have serious doubts about that happening in my lifetime. It's quite a trick to go from printing ABS to printing hardened steel.

<comment><USER12> You seem to be assuming that the term rifle always implies something complicated like an AR-15 or AK.

The most likely reason someone would go about creating a rifle in their garage due to an oppressive government is because most likely all guns have been banned and confiscated. In that situation, the ability to create a simple bolt-action rifle would be of immense value to anyone fighting the oppressive government. For that matter, a good shotgun that doesn't require rifling is better than nothing. Another option is to make smooth-bore musket types, in the past they were accurate up to 100 yards or so.

Considering that in the past rifles were created by hand with simple tools, as compared to today's technology, I don't find it hard to believe that a small group of dedicated people can figure out how to make somewhat quality firearms in their garage with modern tools.

This talk of people making something like an AR-15 from a printer anytime soon is just someone that's looking for something political out of it, a scare the populace tactic.

<comment><USER8> It is harder to make a bolt action rifle than an AR-15. The skill and time involved are substantial in both cases, but creating a heat treated bolt gun receiver that works is no joke.

But what is much more interesting to me is the interplay between technology and the law. The lower receiver, the regulated part, will be printable (usefully so) within a decade in my view. That makes it possible for someone with basic skills to own a proper semiautomatic rifle without the government even knowing about it. Would that cause regulation of other parts like barrels? Maybe, but barrels are expendable parts...I'm pretty sure the NRA would blow a gasket over that for more than one reason. Triggers? How? What's a "trigger?" Guns, like information, want to be free.

It all puts gun control advocates in a bit of a pickle. In fact, it puts prohibitionists of all kinds in a pickle. And that is a good thing.

<comment><USER12> Well, I was speaking more in terms of functionality, not materials. I didn't mean to imply that making a bolt action rifle was easy, but I find it hard to believe it is harder to make a bolt action rifle versus a semi-automatic AR-15. I'm not a gunsmith, so I could be wrong but the difference in complexity between the two seems to suggest this. I would have to assume that making a single action revolver would be easier than a semi-automatic handgun.

Discussions of quality of the resulting weapon is a different matter though.

If we had printers capable of making a functional gun, then the government can try to regulate individual parts all they wanted. It would make no difference. It's only a matter of time before there's a simple way of making a high quality rifled barrel of your choice of caliber. They would have to look into controlling the materials required; metals, gunpowder, and so on. Even then that's a losing endeavor, simply because how can you tell the intentions of the person buying the materials? You can't.

This goes beyond weapons, the ability to create nearly anything you want in your home with no one knowing opens up a huge can of worms that I feel that most people simply cannot comprehend.

<comment><USER8> The difference is in the complexity of the parts. A bolt gun receiver is much more complex to build than any part on an AR-15, which is the closest thing out there to a gun you can just bolt together.

But yeah, this genie is not going back in the bottle.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> >He suggests one way to prevent dangerous, illegal usage of 3-D printers is to better control gunpowder, an idea that has come up in gun control in the past.

Isn't gunpowder pretty easy to manufacture too? Not with a 3D printer, obviously, but with common materials and a cursory knowledge of chemistry.

>When I tell them the law that would stop these plastic guns from getting onto planes is expiring in just a few months, people are appalled.

This is the essence of missing the point. The issue with 3D printed weapons is that you _can't_ ban them. I have to imagine that it's already illegal to bring a gun onto a plane, so he has to be talking about banning their manufacture, which is the exact thing 3D printing will make moot.

Can we please at some point graduate from trying to prohibit anything with a sharp edge and instead try to address crime and terrorism at the root? I realize that isn't as profitable with campaign contributors or as rhetorically effective in frightening the voters, but the point of a representative rather than direct democracy is that legislators are supposed to make hard or unpopular decisions when it's necessary.

<comment><USER12> Today's politics and laws are about emotion. A group has an emotional crisis so a law must be written to address it. Most bad things in life are already illegal, but there seems to be the desire to add more laws to address that specific thing that bothers that specific group. Even though it is already covered by a number of other laws. Politicians take advantage of this with the typical "we must do something!" or "we must do this for the 'whatever'" (typically children) rhetoric that addresses the emotion but tosses out all logic. It's similar to the perpetual war concept by always pointing over the border at "the enemy".

The problem is that your average person doesn't know enough of what's going on in the world and probably cannot do so anyway, that's the point of a representative government. That's another thing that politician's take advantage of, a person's willingness to believe whatever an "expert" states. Of course it's illegal to carry a firearm onto a plane, except for certain situations (police and so forth), but when someone of authority says that laws that prevent plastic guns from going on planes are expiring the average people assume the politician means that it will suddenly be legal to do so. That's not necessarily true, there are several other laws to prevent such a thing from happening. But the authority figure in his rhetoric chooses not to mention that.

As for almost all gun ban laws in place or have ever been proposed, if you take a hard look, do nothing in terms of preventing any other laws from being broken. Most mass shootings happen in areas where it is known the likelihood of another gun being on the premises is low because the law makes it a "gun- free zone". Gun ban laws tend to lean towards banning guns based on cosmetic features, not the actual functionality of the weapons involved.

</comment></comment><comment><AUTHOR> There are just so many interesting angles to this story. I'll start with just one...

The government is always behind the curve when it comes to regulating technology. The rise of text messaging has forced local and state governments to create new laws to discourage/punish distracted driving. Airbnb and Uber have disrupted the traditional hotel and taxicab industries respectively, and have caused lawmakers to rethink how best to regulate those industries.

3-D printing is on the verge of becoming a mainstream technology and we'll continue to see more issues like the one highlighted in this story.

The Second Amendment to the US Constitution protects the right of the people to keep and bear arms. Does it also allow us to print our own weapons? Does the First Amendment to the US Constitution protect websites that provide instructions and blueprints on how to print your own weapons (or parts of weapons)?

<comment><USER8> _Does it also allow us to print our own weapons?..._

The bill of rights restricts government, not the people. It is an important distinction missed by many.

<comment><USER12> Hear, hear!

</comment></comment></comment><comment><USER14> I guess in the 90's someone could have written an article by the title «Digital copies made with computers could test copyright control efforts».

</comment><comment><USER15> 3d printing guns might be bad news for opressive regimes. I grew up under one, remember all the measures to regulate the use of xerox copy machines. A book was an enemy of the regime. Imagine guns instead. Now, where to get enough amunition?

</comment><comment><USER16> You don't need 3-D printers to make guns. They can be quite easily made in any machine shop - albeit with varying degrees of success.

Zipguns / improvised firearms have been a thing for a long time -> <http://en.wikipedia.org/wiki/Improvised_firearm>

Gunpowder is pretty easy to make as well.

Stop whining about 3-D printers it's not that big of a deal in regards to guns.

</comment><comment><USER17> They're probably not going to test gun control as much as the press thinks. Calibrating cheap 3D printers is hard, and chances are it's going to take quite a bit of tweaking to print off a reliable magazine or other part on a new printer. I can easily see would-be spree killers getting stopped mid- massacre because their misprinted magazine jammed.

<comment><USER18> Calibrating cheap 3D printers is hard _right now_. That doesn't mean it always will be. The good ones will get cheaper and the cheap ones will get better.

It used to be hard to get a computer to use a new paper printer at all. Now it's almost always plug-and-play.

You could imagine a 3D printer that prints test objects, scans them in great detail to find defects, and calibrates itself accordingly.

<comment><USER12> Exactly right. Computers used to be hard to build by hand years ago, you had to solder your own boards for gosh sakes. These days you buy the components off the shelf and stick them together correctly.

What is hard today will most likely be easy tomorrow.

</comment></comment></comment><comment><USER19> Gun control or the lack of it in the U.S. is ultimately due to regulatory capture by the gun industry. I'm sure legislators will draft into laws provisions that would make sure the legal gun industry retains its commercial upsides over 3D printing.

<comment><USER5> I'm sure it has nothing to do with the tens of millions of people who lawfully own guns...

<comment><USER19> Let's briefly talk about gun ownership issues. There are two classes of people who use guns. Those who have a practical need for it, and those who use guns recreationally.

The second group are not dissimilar to people who drive Dodge because they want to honor the "farmer in themselves", or people who'd never take their 4WD off-road. It is the same people who buys Harleys and tattoo Harley Davidson's logo. These are "aspirationals".

These aspirations don't come out of no where. There's marketing dollars at work.

Harley Davidson's may be a way of life for many, and represents an important social outlet. It doesn't take away the fact the Harley Davidson is a commercial endeavour.

Private gun ownership is a billion dollar per year industry in the U.S. This is not a niche market. (Harley Davidson's motorcycle sales was $771m per quarter).

My thesis is that the NRA, being driven by commercial interests rather than 2nd amendment ideals, will come out in opposition to 3D printing of arms.

</comment></comment></comment><comment><USER20> Can we stop calling the process 3D printing?

print·ing /ˈprintiNG/ Noun

1\. The production of books, newspapers, or other printed material.

2\. A single impression of a book.

Synonyms print - press - impression - <USER2>

<comment><USER21> No, because it is a good name.

With 3d printers you are printing layers, like a conventional printer, but one over the others. In fact you could even use the same heads, I could 3d print wax with my printer and an Epson Inkjet head.

</comment></comment><comment><USER8> Link to the mentioned site, Defense Distributed: <http://defensedistributed.com/>

</comment><comment><USER22> Drunks often don't obey anti-drunk driving laws.

But we still have those laws for darn good reasons.

There is nothing wrong with having gun control laws.

<comment><USER13> It seems like a different sort of a thing. The trouble with drunk driving is that someone is doing something dangerous that could cause someone to get hurt unintentionally. The trouble with guns is that bad people intentionally use them to do bad things.

Stopping the drunk on the seventeenth instance of driving drunk makes good sense, because it stops someone getting hurt on the ninety fourth instance.

Stopping someone intent on committing murder on the seventeenth instance is too little too late. You have to stop them the first time, or make it so that they don't find murder to be an acceptable course of conduct regardless of the legality of the tools.

>There is nothing wrong with having gun control laws.

There is something seriously wrong with having laws you can't enforce. It erodes respect for the law in general and it promotes demagoguery and a dangerous trend of expansion in police powers as the law inevitably proves to be unenforceable, law enforcement demands dangerous powers that still don't allow the law to be enforced, and the new powers fail to resolve the issue that the law is unenforceable generating a renewed call for more new and dangerous police powers.

<comment><USER12> Another example following your unenforceable laws logic, drug laws. Look at how many civil liberties have been tossed to the side in the ever expanding drug war, even though most applications of these laws these days having nothing to do with drugs. No-knock raids are pretty much the standard on serving a search warrant now.</comment></comment></comment>


Talk With Other Programmers - <AUTHOR> http://www.killerstartups.com/Web20/tagmask-com-talk-with-other-programmers

<comment><USER2> Lol, what? Wait a minute? "the notion that programmers have few online spots for conversing and exchanging tips and hints"?

Does anyone entertain such an absurd notion? If anyone has online spots to "talk about how to code, program and develop just any old application or tool", it must be programmers. From the ancient age of Usenet to the more modern era of StackOverflow and, dare I say it, Hacker News, programmers have _always_ had _many_ spots to connect with other programmers online.

So how did this story get 6 points?

<comment><USER3> I built Tagmask. Actually, I don't like what is written on Killerstartups. The main feature of Tagmask is tag-based approach to filtering posts, some people find it useful. But I never told that Tagmask is a revolutionary community for programmers. And I am very upset and frustrated about Killerstartups article.

Btw, I sent an email to you about Tagmask, did you miss it?

<comment><USER2> _Btw, I sent an email to you about Tagmask, did you miss it?_

Sure seems so! Try daniel at tenner dot org.</comment></comment></comment>


Too many indexes (apple+Google+yahoo+bing) time for mobile deeplinking standard? - <AUTHOR> http://www.quora.com/Now-that-we-have-Google%E2%80%99s-App-Indexing-Bing%E2%80%99s-App-Linking-Facebook%E2%80%99s-App-Links-and-the-newly-announced-Apple%E2%80%99s-Deep-Links-do-we-need-some-kind-of-standardization-here/answer/Alex-Austin?share=1

<comment><USER2> That's interesting, an advertisement in the form of a Quora post...

Anyway, relevant response:

[https://xkcd.com/927/](https://xkcd.com/927/)</comment>


Ask HN: Are Effective People Usually Impatient? - <AUTHOR>

Just a question based on my limited observation. Recently I met up with a coder who has achieved a lot in the past year, and he mentioned to me: "actually I dont have much patience". It kind of triggered the question in me - are effective people usually impatient ? Of course you can find examples in the tech industry easily: Bezos, Jobs, and many more come to mind - so, is it a general trait, or just perception bias ? What is your take on that ? <comment><USER2> I really hate when people justify being impatient and demaning by using examples like Bezos or Jobs.

Nobody gets to the level of success as Jeff Bezos or Steve Jobs without learning some level of patience. Amazing technologies like the iPhone and the Kindle wouldn't happen under the duress that I've witnessed at startups where a micro-managing founder is barking orders at people and expecting everything to be done yesterday.

People (and the press) tend to focus and sensationalize an individual's spectacular moments of impatience much more than their more regular day to day patience.

So the bottom line is, learn to be patient and expect to spend 80-90% of your time being patient. Impatience and being demanding can be a powerful weapon in helping get things done, but they should be used sparingly and in short bursts.

And expect that people will remember that one time you lost it in a meeting for a lot longer than the 100 meetings where you were attentive, supportive, and helped get things done without losing your cool.

</comment><comment><USER3> I think its a trait that you can find in successful people, but I've met tons of effective people who were very very patient.

In my experience impatience doesn't scale, unless you have the kind of pull that people like Bezos or Jobs did, and they could only accomplish that because they're founders, not just founders, but brilliant founders at that. If you work in an organization of any sort of size, you will quickly run into problems with people because of your "attitude", if you adopt this tack, even if you're brilliant (thought you'll get much further before running into trouble).

What I think you'll find is that being firm and constant but pleasant will get you far. Something is due next week? check in the week before, then check in 3 days before, then check in the day before. When you check in, ask about their day, ask about their kid's recital, ask about their sick dog. Its might feel weird, but it works.

Want something done? keep tabs on all the moving pieces and make sure you're doing everything in your power to make sure people you need to accomplish your goal have what they need to finish what they're doing.

I went into an organization thinking I could pull the Steve Jobs act and "get shit done", I almost got fired. I found that asking about someone's day and listening attentively for a few minutes is more likely to get them to help you accomplish big things, than telling people their ideas are "shit" and that they should listen to your brilliant idea :)

Just my 2c. PS: Read Dale Carnegie's 'How to win friends and influence people", its a bit corny now, but the central ideas still hold very true

</comment><comment><USER4> Making a statement does not necessarily means speaking the truth, more likely just to make an impression.

Impatience (unless it's only for a short moment) comes from emotional imbalance and that, in turn, will be detrimental to continuous success.

</comment><comment><USER5> I'd say it's perception bias. If the Google founders had been less patient, they would have sold out to Microsoft for five million, instead of waiting a decade. Similarly, Zuckerberg had the option for a much earlier payout, but he decided to wait. Amazon would have been more profitable earlier if Bezos had put the revenue into profit, instead of expanding, but he decided to wait. Even Jobs could have launched most of his products much earlier, but he had the patience to wait for them to be done.

One of the most successful indicators of success later in life is the ability to defer gratification.

</comment><comment><USER6> What you mean by "Effective"?</comment>


Facebook's New Spam-Killer Hints at the Future of Coding - <AUTHOR> http://www.wired.com/2015/09/facebooks-new-anti-spam-system-hints-future-coding/ <comment><USER2> Even as someone who knows Haskell, it isn't actually possible to read this article and figure out what specifically about Haskell is helping.

My suspicion is that it is Haskell's great support for domain-specific languages. This is both in the sense of languages that are really "just" Haskell APIs but work in such an different manner that they are quite different, and in the sense of writing a full compiler [1] (or any subset of a compiler) for a new language.

For an example of the former, one of my favorite demonstrations is the "probability monad", in which one ends up with a sort of sublanguage inside of Haskell that is probability aware: [http://www.randomhacks.net/2007/02/22/bayes-rule-and-drug- te...](http://www.randomhacks.net/2007/02/22/bayes-rule-and-drug-tests/) [2] If you want to start to really grasp the power of Haskell, you could do worse than meditate on how you'd implement that in your $FAVORITE_LANGUAGE... and then, most likely, burst into tears when someone shows you just how much of Haskell still works, unchanged, even in that environment (e.g., everything in Control.Monad), rather than having to be implemented in a parallel type hierarchy (or, put another way, producing a new "color" of functions [3]).

While I doubt they use something exactly like that, it's not hard to see how that sort of thing could make it fairly easy to write spam classification code with a lot of the basic plumbing abstracted away entirely.

There's a lot of examples of the latter, but I'm not sure of a really solid open source example to point at. I know it's a common move in industry, though.

For bonus points, these things compose together just fine; you could easily take the probability monad and build a new language on top of it.

[1]: And I do mean real compiler, by anybody's definition, all the way down to assembler if you like. Haskell's a pretty good base language for that sort thing.

[2]: Or see [http://blog.plover.com/prog/haskell/probmonad- refs.html](http://blog.plover.com/prog/haskell/probmonad-refs.html)

[3]: [http://journal.stuffwithstuff.com/2015/02/01/what-color- is-y...](http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your- function/)

</comment><comment><USER3> This is such a strange article. It starts out describing how Haskell was well- suited to their problem (or at least tries to) and then suddenly says:

 _The thing is: Biilmann no longer uses Haskell. It's not entirely practical. Not enough people know how to use it, and this is unlikely to change. "Haskell is like a programming language from an alternate future that is never going to happen," he says. "It solves all these problems it promises to solve. But it's so different that there is no chance it will become common."_

<comment><USER4> Yeah it seems like they are just writing an article for the sake of writing an article.

<comment><USER5> And based on the number of grammatical errors, quickly, at that.

</comment></comment></comment><comment><USER6> tldr: use Haskell because it solves all problems, but actually don't use Haskell use Go/Rust instead because they are more suited to the mainstream programmer, but Haskell is more powerful.

What.

<comment><USER7> tldr: functional languages may be the future. Or maybe not.

<comment><USER8> Hm, I took away this:

tldr: functional languages were the future for Facebook's new spam fighting tool, they weren't for a startup owner who has previous professional Haskell experience. Consider for your next project and possibly live the future now.

</comment></comment></comment><comment><USER9> Saying Haskell is ideal to the problem but not what they use is not a non sequitur. Just because a language's intrinsic characteristics make it ideal does not make it the best tool for a large project with an evolving programmer base. The point stands that Haskell represents an almost platonic ideal that other languages and libraries are striving for.

</comment><comment><USER10> I think the real key is to accept that with well-defined interfaces, polyglot environments really do have an advantage, because different languages really do have sweet spots.

And fortunately, POSIX gives us those well-defined interfaces. POSIX process boundaries, pipes and Unix & TCP sockets are excellent interfaces to separate tools written in different languages. A well-written RESTful service listening on a Unix socket can work wonders.

If one's using POSIX, then one's team can work on each tool in the language which best suits it and in which the primary lead is most product. If someone moves on, then the rest of the team can support it because a) good programmers can pick up good languages quickly (I don't want to hire or work with mediocre programmers) and b) each service is small enough that anyone can understand what it does by looking at a small amount of code.

</comment><comment><USER11> At work we use a Haskell DLL loaded into Matlab. Haskell's type system allows us to have a fast, formal core to depend on, and Matlab allows us to do ad-hoc things at run-time with a fairly powerful REPL.

I mention this because there are ways to benefit from Haskell while still maintaining the sorts of "practical benefits" that are cited here.

</comment><comment><USER12> I love the idea of old languages coming back in fashion. I secretly love MUMPS.

<comment><USER13> I am with you. I am so hooked on the built-in persistent storage support. I have never seen a language as cool in that regard.

</comment></comment><comment><USER14> From Haxl paper:

"We present an Applicative abstraction that allows implicit concurrency to be extracted from computations written with a combination of Monad and Applicative."

The more your code is Applicative the more concurrency you can extract. It's a matter of good abstractions rather than the language. I'm sure Rust can handle Applicative and Monad just fine.

<comment><USER15> Rust does not yet have Higher Kindded Types, and so cannot yet. We do want to add them eventually.

</comment></comment><comment><USER16> My jaw actually dropped when they said "they used a programming language called Haskell."

Were all my prejudices against the business practicality of functional languages wrong?

Nope.

"Biilmann no longer uses Haskell. It's not entirely practical."

EDIT: ... and to say, if Facebook can't attract superstar Haskell programmers, then what chance any other startup?

<comment><USER17> Biilmann isn't at Facebook; he's just some random developer at a startup with experience in different languages who once used Haskell for a work project. He may as well be yet another HN commenter, and it isn't surprising that not everyone who has tried Haskell is using it! The reporter probably just found him easier to interview than the people actively using Haskell, for whatever reason.

Haskell at Facebook is still going strong with, I believe, two teams using it and actively recruiting. (I've been contacted by a recruiter myself, even.) And they've hired Simon Marlowe and Bryan O'Sullivan who are pretty much as superstar as they come. Recruiting woes are greatly exaggerated if not inverted for startups seeking a handful of engineers—Haskell actively attracts interesting candidates.

<comment><USER18> Biilmann here, I'm definitively not at Facebook no :)

I've run Haskell services in production for more than 4 years and still operate 4 of them to this date. I also contributed the wai-eventsource module to the Yesod project and build a Haskell powered eventsource addon for Heroku.

It's not my impression that there are tons of other people in the bay area with as much experience in actually using Haskell for real world production stuff. Most of them are probably at Facebook now and the journalist behind the article did interview them...

That said, it's absolutely true that for Netlify I now use Go for the tasks I would have used Haskell for earlier.

Haskell is an awesome, mindblowing language, and when I started using it for production tasks it was by far the best tool for the job at the time. By now, however, Go is a far more pragmatic choice for most of the tasks I used Haskell for before.

Unless your whole stack is Haskell based, the context switching involved in going back and forth between more traditional languages and Haskell are really brutal. Apart from that, it's very easy to bring someone new onto a team and teach them enough Go to be productive in a day or two. You just can't do that with Haskell.

That said, it looks like a really, really good fit for what they're doing at Facebook with regards to spam filtering. I can totally see how you can make a safe DSL for rules that will be statically type checked and handle concurrency without any need for developers to think about it, and the Haskell runtime is incredible for these kind of things.

</comment></comment></comment><comment><USER19> I've read over and over that 'haskell is difficult', but why exactly is that?

Its mathy syntax? Its unique concepts? The practical side (installing, configuring and libraries can still be troublesome)?

<comment><USER20> I think it's mostly the immutability. That can be quite frustrating sometimes.

</comment></comment><comment><USER21> Amazed that the article compares Haskell with Go and Rust but failed to draw comparisons with Scala (with some learning curve but not as great as the ones in question).

</comment><comment><USER22> tl;dr they rewrote facebook software in haskell, so haskell might be good. It definitely changed the pace enough to make a boring rewrite more engaging. Never admit that publicly.

</comment><comment><USER23> pretty dumb article. An editor could save it by shifting the take away towards the concepts polygot and the concurency requirement and it might make a bit of sense.</comment>


Yahoo CEO will get no severance but keeps $7 million of cash - <AUTHOR> http://money.cnn.com/2012/05/14/technology/yahoo-ceo-no-severance/index.htm

<comment><USER2> Where's the news about the idiot VP of HR, the one who didn't vet him properly, being fired? Yahoo! is a doomed company, much like AOL was.</comment>


Diaspora website redesign, now with more info about the project - <AUTHOR> http://www.joindiaspora.com/

<comment><USER2> Here's the question I'm left with which has no answer on the site: how will a distributed social network keep my private data private?

I understand how one can build secure communications. That part is easy. So, I have a Diaspora account with "Awesomea" and you have a Diaspora account with "Crapula". It's easy to have communications between Awesomea and Crapula be secure. However, when you visit your Crapula page, you want to see my updates which means that Crapula needs to be able to decrypt my updates. Even if you have a different key for each user (ala public key encryption), for wide adoption the service providers (in this case, Awesomea and Crapula) need to be able to encrypt and decrypt that information (which means they hold the keys).

So, if I friend you and you're using Crapula, I need to trust both you and Crapula that you won't do bad things with my data.

Part of this is that the Diaspora project doesn't seem to have any technical information. They have lofty goals like, "you own your social graph, you have access to your information however you want, whenever you want, and you have full control of your online identity." However, they have scant information on how they plan to accomplish that. They say they're using GPG, but are they going to have a browser plugin with locally stored keys to decrypt the information? That's the only way I can see this being secure. If you're storing your key with Crapula and it's decrypting my information, it can store is as well as show it to you.

Even if the design is to use locally stored keys, what's to stop a provider from offering a "better" (better, in this case, means easier for non-tech- inclined users) Diaspora-compatible server which stores them on the server? And then I have to audit my friend requests to see how their server has set up security?

It's kinda like handing a friend a classified document and a photocopier. You tell them "please don't copy this" and they probably won't. But in this case you're handing that classified document to Crapula and saying "pass this along to my friend and don't copy it along the way". Yes, Facebook has that ability too, but it's one company that has a reputation to defend (to an extent) as well as a legal presence in the United States (which is good for me as a US citizen) and by posting in the first place I'm trusting them with that data. With Diaspora, I could start getting friend requests from all sorts of services run by people a lot shadier than the Facebook folk and I now have to deal with dozens of privacy policies rather than one.

BTW, this is probably the comment that I would most like to be proved wrong on. I want distributed, secure social networking that puts me in control of my data. It's just that I don't see how it works and the Diaspora website doesn't have any information on it either. If someone here knows how this will work, I'd love it! It's an exciting prospect, but I feel like it's the same as DRM: if people can read it/see it/hear it, it can be copied. Likewise, if a service provider is printing it on screen for one of their users, they can store it. If anyone has technical information on how this works, it would be really awesome!

<comment><USER3> Security is only one issue that is un-documented, from my viewpoint.

I've found it bizarre that there is so much support without any logical outline of what Diaspora is. We have their reasoning ( <http://www.joindiaspora.com/project.html> ) and their FAQ ( <http://www.joindiaspora.com/faq.html> ) .

I don't think this is sufficient to begin a successful project.

Possibly they have not documented their logic to the extent that it exists?

Or possibly I'm the exception and this is not an actual concern for the project's success?

<comment><USER4> _We have ... their FAQ_

And it's a pretty useless FAQ, at that. Most of the questions are about Kickstarter. (They sure do like raising more and more money, don't they?)

<comment> loup-vaillant Seconded. Also, the answer to the second question ("is Diaspora portable") dodges the actual question, and makes me wonder what the Diaspora team actually want to accomplish. An answer like "portability is not an issue, we plan to sell you fully configured plug computers anyway" would be much more reassuring.

I suspect they don't plan to sell such devices. And I totally don't understand why not.

</comment></comment></comment></comment><comment><USER5> Let's just focus on one thing that many people are used to: the news feed.

Say I want to find out what all my friends are up to lately. Since this information doesn't live in a (more or less) central place any more like it used to on Facebook, I need to go out and contact each node (in an encrypted, secure way) that my friends run/pay to host on an ISP and ask them, what they're up to lately. That information then gets merged by my local node (that I presumably access to view a news stream) and displayed to me.

Isn't that more than a bit inefficient? Hundreds of friends, means hundreds of connections going out, to grab friend updates, each with encryption overhead. And all those nodes have to be up and running of course.

OK, so let's assume your own node is smart enough to cache these updates. Maybe it even gets updates pushed to it when my friends update, so it's not constantly polling all of them in search for updates. That means if my friend withdraws permission to see their updates, I still have access to their cached info local to my own node.

So perhaps there's also a push update system that handles revocation. You remove permissions and send another message to those affected to forget your info. But what if I run a modified node that chooses to ignore this information? The whole thing is open source and anyone can tinker with their node code. Say I friend a malicious entity, decide I don't like them anymore, and take back their access. It could be too late.

See, this is the kind of technical detail I was hoping for. Real life examples and a vague outline of how they're going to tackle them.

<comment><USER6> Well, that's the problem with having friends. Whenever you let someone get near to you, they could be carrying a hidden microphone and a video camera. And, even if you explicitly tell them that you don't want to be friends with them any more, they'll still remember everything you've told them.

The same issue crops up with email, letters ... hell, every way we've communicated for hundreds or thousands of years: there is no way to revoke access to information once granted, even if access to new information is withheld.

You might as well complain that someone could take screenshots of everything you say that shows up in their news feed.

</comment></comment><comment><USER7> I've been particularly impressed with their amazing ability to avoid mentioning any details about the projects implementation.

The following is a list of features the future might bring (if I understand the project page correctly: <http://www.joindiaspora.com/project.html>)

 _OpenID_

I assume this is the standard they will use for authentication? What about this encryption business? Do they intend to modify the OpenID protocol to do some sort of challenge/reponse step and exchange keys?

 _Voice-over IP_

I'm at a loss for what this means or how it is important to the project. Are they implementing a specific protocol, using a particular libary, or are they going to attempt rolling their own system?

 _Distributed Encrypted Backups_

Backups of what? Distributed why? How?

 _Instant Messaging protocol_

There are a plethora of existing protocols they could use. Since they haven't specified a particular one, does it mean they haven't decided which one to use yet? Are they planning to build their own "encrypted" protocol? Magic?

 _UDP integration_

Whoa. Integration. With UDP? Mind-blowing. I'm assuming that they'll be building the broad-casting bits of the P2P architecture on UDP. It's what most distributed, encrypted P2P networks do.

Oh right, there are already dozens of them and have been for years. I guess these kids are just too young to remember:

\- <http://en.wikipedia.org/wiki/WASTE> \- \- <http://office.microsoft.com/en- us/groove/default.aspx> (before it got bought by MS and turned into corporate turf) \- soulseek, gnutella, freenet, etc.

Wonder how they're planning to break that extra 10x

<comment><USER4> I think that's an example of things on "the list". (Things to do in the far future after they finish other things that they have to do)

</comment></comment><comment><USER8> _We are 140-character ideas. We are the pictures of your cat. We are blog posts about the economy. We are the collective knowledge that is Wikipedia. The internet is a canvas – of which, we paint broad and fine strokes of our lives with. It is a forward extension of our physical lives; a meta-self comprised of ones and zeros. We are all that is digital: If we weren't, the internet wouldn't either._

sounds like pr-speak.

<comment><USER9> That would literally be the worst PR writing I'd ever seen.

It's more like a throwaway line from a draft script for the Matrix.

</comment></comment><comment><USER10> What people here might really wanna know it's that the _source code_ will be released _under AGPL_ (you must let your users download the source of the program they're running).

In my opinion for boosting commercial adoption, a MIT license is truly needed. I know it's not in their interest to do so (they plan to build a wordpress.com-like hosting).

<comment><USER11> I doubt the AGPL would stop people from providing Diaspora servers. It would just remove some of the incentive to improve the software.

<comment> loup-vaillant With the AGPL, you have some guarantee that improvements will be given back to the community. So while you're right ( _some_ of the incentives are removed), you're wrong (other incentives are _added_ ). I bet the net effect will be positive.

</comment></comment></comment><comment><USER12> The Diaspora guys have missed the problem completely: the issues are not technical ones - the major problems here have been solved.

The issue is UX: Nobody - and certainly not Facebook - has come up with an effective interface that allows us to manage our interactions online with the fidelity that we want. And I doubt that these four kids are going to come up with a spell-binding piece of design that does this. They seem to be Ruby programmers, and certainly not designers - graphical, UX or otherwise if one is to judge by their website.

Far deeper analysis of the problem is needed that the reactionary "Facebook are arseholes, they're acting like a big corporation". The details of how we create multiple online publics[1] for ourselves, how we relate to them, and understand them is key to building any sort of infrastructure to manage those publics. The Diaspora guys seem to be treating this as purely a technical problem, when it most certainly is not.

[1] It's the other side of the coin to having multiple online identities, but to me, makes a bit more sense as a conceptual model for what we're dealing with.

</comment><comment><USER13> Wouldn't it suck if you were some kid with a lot of ambition, and some huge ideas, who tried to bite off more than he or she could handle, all while the world watched and encouraged you? Wouldn't it suck if you felt a real obligation to see through to some half-baked idea you came up with in your early 20s?

I have sympathy for the Diaspora guys, I think if it went unnoticed and unfunded it could be a great learning project for some young coders, even if it didn't achieve practical success. Instead, it'll likely be (already is) a public embarrassment.

If I could give the Diaspora guys one bit of advice, I'd say this, don't take this too seriously; treat it like a fun summer project. The last thing you want to be is the next freenet (no offense Freenet guys, awesome concept, but it never really caught on).

</comment><comment><USER14> The complete lack of technical information is dumbfounding.

</comment><comment><USER15> Your $200,000 at work.

<comment><USER16> I realize you're being sarcastic and this doesn't apply to you directly, but this has been bugging me for a while:

Everyone needs to stop saying these guys are "well funded." $200k is nothing especially for a team of 4 people. It's certainly not enough for them to hire anyone else full time to join them. Yes, they didn't have to do much to get this money and I realize it's infuriating if you're really struggling to get your business off the ground when 4 nobodies get a chunk of money out of nowhere, but please recognize that the amount is so small that it doesn't warrant outrage.

Furthermore, they didn't even ask for that much. It got a big network effect in light of the recent facebook privacy issues, but it's a one time thing and most likely the last money they'll ever see for this project. I don't think their situation is repeatable in any sort of predictable way, so it probably doesn't warrant studying (please correct me if someone's figured out a way to do this, cause I think most of us would like to figure out how to get free funding). We should wish them the best of luck and only care when they make something people want to use.

I can already see the headlines of outrage when they don't produce something that destroys facebook overnight, or maybe don't release on time, or their code is really bad. Anyone who contributed to them only expected to give facebook a little jab. There are reasons to question their abilities, but jealousy over their gimmicky funding really needs to stop.

<comment><USER17> I don't think it's jealously over gimmicky funding, I think it's more along the lines of all this hype was raised, all this money was raised and we're still sitting here, sucking our thumbs to see what's supposed to happen.

The launch date is in September, and so far the last update since the NY Times article was a redesign. The only technical information is that it's using Ruby, "a little bit of rails" and some "other" frameworks.

This feels to me like giving a kid $0.25 for a glass of lemonade, and him telling me he'll bring it to my house after he's built his lemonade stand, bought the ingredients and actually produced a beverage.

<comment><USER3> _This feels to me like giving a kid $0.25 for a glass of lemonade, and him telling me he'll bring it to my house after he's built his lemonade stand, bought the ingredients and actually produced a beverage._

This is exactly the state of the project unless there is a whole lot that the Diaspora team has not publicly documented.

But, as far as I know, they have never stated that this was not the case. Their video made it pretty apparent they had yet to build the lemonade stand and buy the ingredients.

</comment></comment></comment></comment><comment><USER18> seems like they're already slipping on their promises and they haven't even started development yet: <http://twitter.com/joindiaspora/status/14146589639>

what are they spending all their time doing?

<comment><USER19> Which is hilarious, because their site claims they are almost done.

</comment></comment><comment><USER20> Doesn't render well on iPhone. And do they not own the -join.com?

<comment><AUTHOR> It seems like they do not own diaspora.com no, some guy in Las Vegas does and I'm sure he's gotten quite a lot of traffic to his ad-parked site.

</comment></comment><comment><USER21> how did they go from having a nice visual & simple logo [http://www.facebook.com/album.php?profile=1&id=118635234...](http://www.facebook.com/album.php?profile=1&id=118635234836351#!/photo.php?pid=147415&id=118635234836351)

to having this horribly designed website?

They likely didn't even need to use the money they have to get a half decent design.

This is not instilling much confidence in these guys.

</comment><comment><USER22> The typography is pretty bizarre.

<comment><USER23> Especially in the navigation area.

</comment></comment><comment><USER9> I'm perfectly okay with them being fairly scarce with information until they have something built.

They surely have high caliber advisers at this point. The peanut gallery probably wouldn't be all that helpful as they try to lay the first foundations.

Once there's something complete to react to and build on, they'll release the code.

</comment><comment><USER24> If the project takes off and has mainstream adoption I couldn't wait to see a MIT licensed django clone.

</comment><comment><USER25> As if they needed another blow to their already tenuous credibility, the site doesn't even validate.

[http://validator.w3.org/check?uri=http%3A%2F%2Fwww.joindiasp...](http://validator.w3.org/check?uri=http%3A%2F%2Fwww.joindiaspora.com)

I have zero confidence in this group.

<comment><USER26> [http://validator.w3.org/check?uri=http://news.ycombinator.co...](http://validator.w3.org/check?uri=http://news.ycombinator.com&charset=\(detect+automatically\)&doctype=Inline&group=0&user- agent=W3C_Validator/1.767)

EDIT: [http://validator.w3.org/check?uri=http://www.google.com&...](http://validator.w3.org/check?uri=http://www.google.com&charset=\(detect+automatically\)&doctype=Inline&group=0&user- agent=W3C_Validator/1.767)

I suppose we should by this logic be 4 times more confident in Diaspora than Google, and 15 times more confident than HN.

<comment><USER4> Google doesn't validate because they need to serve the page millions of times a day. Hacker News is not a startup, it wasn't funded with $200,000, and its goal is not to create a web application (Diaspora's is.)

<comment><USER27> > _Hacker News is not a startup, it wasn't funded with $200,000, and its goal > is not to create a web application (Diaspora's is.)_

I'm confused. So does anything that is not a start-up, and/or web application get a free pass on standards compliance? I was under the impression that the standards were meant to apply to all web pages.

</comment></comment></comment></comment><comment><USER28> It took me a few seconds to realize the CSS had completely loaded.

</comment><comment><USER29> well at least we know they have 200k to spend on a good designer now :)</comment>


List of "Ask HN" posts? - <AUTHOR>

Does anybody know where there's a list of "Ask HN" posts? I've seen it posted before on the site but my Google fu is weak. <comment><USER2> <http://ask.searchyc.com/>

<comment><AUTHOR> Thanks.</comment></comment>


New Google Doodle - <AUTHOR> http://www.google.co.nz

<comment><USER2> The source for those interested: [https://gist.github.com/mikeroher/5743860](https://gist.github.com/mikeroher/5743860)

</comment><comment><USER3> Pierre, who didn't care:

[http://www.youtube.com/watch?v=oWnuGcI8QwU](http://www.youtube.com/watch?v=oWnuGcI8QwU)</comment>


Send email asynchronously with Rails and Sidekiq - <AUTHOR> http://www.okalex.io/send-email-asynchronously-with-rails-and-sidekiq/

<comment><USER2> Curious as to why you didn't use the ActionMailer delayed extension? [https://github.com/mperham/sidekiq/wiki/Delayed- Extensions#a...](https://github.com/mperham/sidekiq/wiki/Delayed- Extensions#actionmailer)

Also isn't it dangerous to override `EmailDeliverer.send` like that?

<comment><AUTHOR> Well that would be because I didn't know about the delayed extensions :) Will update the post accordingly.

And regarding .send… d'oh! I'm actually using .deliver in my code and changed it just before pressing publish. What can I say? It was 4am and I wasn't thinking properly.</comment></comment>