iLoch

To me, it's the reintroduction of custom templating. I appreciate E4X/JSX syntax because it's just a thin layer of sugar which is compiled to regular JS syntax. It also lacks custom implementations of loops etc, requiring the user to write _Javascript_ not some non-standard templating language.

No one gets fired for using React. Vue isn't even shinier in my opinion. It makes the same templating mistakes that Angular and Backbone did.

The complexity of creating a component in react is identical to Vue.

It's hardly fair to compare the technology in the Oculus to what's in HoloLens. The HoloLens is an x86 PC that fits on your head and has 5 cameras, 4 microphones and a depth sensor and lasts several hours on a single charge (which is important because it doesn't need to be plugged into a $2000 PC.)

I also haven't seen anyone get sick from HoloLens or trip over anything while using one.

I wouldn't be surprised if the price point of HoloLens is absurdly high for a very specific reason: to stop people from thinking it's consumer technology - it isn't - not yet. And if that's Microsoft's strategy then I'd say it's a smart move. As a HoloLens developer you have to focus your efforts on enterprise and practical applications. Not gimmicks, because there's no money in that.

Likewise I believe S02E01 - the Christmas episode - shares the idea a similarly dystopian fate for AR.

Speaking as someone coming from the web, auto-layout is really awful. You're way better off making UI easy to reason about for web developers transitioning to mobile, because that's where most of the talent comes from. By DSL, do you mean something like HTML/CSS? React Native basically has this with JSX and style properties which use Yoga under the hood.

Shortsighted, wouldn't you say? Eventually this will choke out all competition except for companies with the smartest people/deepest pockets. We'll end up creating monopolies around content by refusing to pay for it when there was healthy competition.

Thanks for your reply Dominic. As an end user, what should compel me to use Inferno for any production purposes? Bearing in mind React has the support of multiple billion dollar companies, several targets (web, native mobile/desktop, console) and a community of what is sure to be tens if not hundreds of thousands of developers. I just don't see the benefit of incremental improvements when they're not being integrated into that community. You lose all the benefit. I have no doubt Inferno is faster, but I suspect you're being disingenuous when you say all the same features are available.

The trouble I have is not specific to Inferno, but rather the idea that less and new is better. Eventually, your users will want something that Inferno doesn't offer, and eventually it will be implemented. And this will happen more than once, probably to the point where your library, too, is 45kb. So is all this work and fragmentation and confusion and comparing of benchmarks really worth it? I think not, unless the technology stands to bring something vastly different to the table.

The trouble with competing with React in its own space right now, stems from the vast amount of resources many of companies are putting behind it. You just can't make a Inferno Native, etc. I think we'd be much better off all working together on new ideas, not rehashing innovation in order to win benchmark tests.

All that said, I applaud the effort, as I'm sure this took a lot.

What do you think the extra 38kb of code is for? My point of view is, you've got a company with thousands of employees who work with a library every day and core teams dedicated to its improvement. Their requirements for speed and bandwidth far exceed our own as they reach further into the nth percentile of users, so you know things like speed and bloat are important for them to cut out.

What, if anything, is actually gained from a business perspective by reducing a single library by 38kb? My guess is exactly nothing. And the benefit of sticking to React is not only the community, but the fact that they actually own their virtual DOM implementation and actively work to improve it (the forthcoming fiber rendering engine is a great example of that.)

I'm not hating on new technology, but this isn't actually new. It's a clone that isn't really bringing anything new to the table, and just muddies the water for developers. It's like if every few weeks there was a new take on Git that did practically the same thing but wasn't Git.

We'd be much better off if these people were contributing to React core. Because if it truly has the same capability as React, you should be able to shave the 38k off right?

So basically, as the platform matures beyond a fun experiment, it'll grow in size. Got it. ;)

Cool, so it's React but presumably they've stripped out many of the things that make React enjoyable to use in order to satisfy some arbitrary file size metric. Why isn't this library 1kb, like LatestHotFramework.js?

Do you have a De-bullshifier for existing Java codebases?

Sure, if you know C++! :) I should probably create an issue outlining the things that still need to be done.

Interesting, once I get ThreeJS support working for HolographicJS (https://news.ycombinator.com/item?id=12913052) I'll be sure to get give this a shot with HoloLens!

I just don't understand why people use the git CLI. Git is too powerful a tool, using the CLI limits one of two things: your capabilities, or your productivity.

Often times I see my coworkers screwing around with git trying to review diffs and commit their changes. One of two things happens: they spend longer than they should doing it, or they do it haphazardly. Sometimes they get it wrong.

Just use a GUI.

I use SourceTree and often find myself committing individual lines or chunks in my files instead of the whole file. I'm confident the average git CLI user doesn't even know this is possible. I can do massively complicated commits with ease because I can see every single line that has changed right in front of me.

I just don't understand the fetishization of source control via CLI. In all likelihood it doesn't make you more productive, and it's probably less accurate unless you really know you way around git.

How about a web spec for creating sandboxed native UI? Would go nicely with WASM.

Do you see SkateJS being more beneficial to a React developer than say, Standalone? https://www.npmjs.com/package/react-standalone

Impeachment in all likelihood.

> I'm also wondering why people choose to trust a company to provide the powder for them instead of making it themselves.

Are you really wondering that? The people that buy this stuff are the ones that won't even make themselves a meal. You think they're gonna make the powder themselves?

> Microsoft introduced a 28" desktop PC in an era when nobody uses desktops anymore.

"a 28" desktop PC" is a bit of an understatement. It's a huge low-latency touch display which works like a drafting table.

> nobody uses desktops anymore

There's a desktop on most desks in our office. A Macbook is certainly an alternative option but not if you're looking for a large touchscreen display.

> For the same price as the new Surface Book i7, I can get an MBP 15" with bigger screen and quad-core CPU

If there was really a performance problem I think a lot more people would be upset with what was announced. Last gen means more stability and likely cooler temperature hardware. Also, does the 15" MBP have a detachable/touch screen? Does it come with Windows? These are real considerations for potential Surface adopters.

The Macbook is simply a laptop. There's no problem with that, but Surface is selling more than that, so a direct comparison on cost and performance isn't really fair. Or are you suggesting Apple is the only company capable of putting newer hardware into a computer?

Has Apple announced a holographic computer yet? :)

Sounds like you've got far too much going on there to be classified as boring. :)

There are actually tons of companies that do this, and it's a great business model that works well for everybody.

I'll start by saying this is a really interesting device, and a very impressive technological feat. However, I have some major criticisms too:

The only advantage I see to this vs. something like HoloLens is that it doesn't require a head mounted display. Unfortunately for this project, that's not as big a barrier for serious companies as they need it to be. In time I think this "advantage" will also dwindle due to shrinking component size, etc.

The price is also considerable - it's about a thousand dollars cheaper than a HoloLens (I'm going to keep going back to HoloLens because to me they're directly comparable.) But the thousand saved also comes with some significant drawbacks:

- The notion of collaboration seems to be non-existent with this device - I don't see them showing how that might work based on their promo clips. Seems to be single user driven.

- It has a back-face. How do you render something like text so that it's readable from all perspectives?

- Control appears to be limited with no standard input. HoloLens tracks the users hands, by comparison.

- Does it have a top on it? At that point, what really separates it from a 3D TV? Seems like you'd only get limited perspective translation.

I'm having trouble coming up with really practical applications for such a device, that wouldn't be better suited by a head mounted personal device. I fully support the effort if they find their niche, but coming from a VR/MR point of view, I can't really see any real advantages. Please enlighten me! I don't mean to be a downer!

They will be. :) Nothing wrong with that, it's just evolution.

> anything from 2 to more than 48 nodes in a distributed database

Why specify a range if you're going to leave it open-ended?

But that's because they can already track your identity by correlating purchases and wifi accesses.

You may be interested in this: https://www.sec.gov/news/pressrelease/2015-249.html

Here's a concept: things that don't need to be charged. If Apple removes the headphone jacks from their computers I won't be buying their computers anymore.

The async/await example is much cleaner. I also think it's a great pattern for async code. It allows you to get away from callbacks altogether, and replaces those annoying conventions with "synchronous-like" code, which to me as someone who writes async code daily, is a god-send.

The amount of visual noise in the promise example cannot be understated.