Ask HN: Do all VPNs suck? - <AUTHOR> It seems like every VPN's relies on me relying on them telling the truth which to me defeats the purpose. Am I missing something?<p>Any security researchers have any recommendations if I am? <comment><USER2> VPN providers trade a local threat actor who is probably ignoring you for a foreign one who is probably watching and analyzing everything. Best advice on this thread was doing a VPN back to your home router.

Typically, you'd use one for default internet browsing on public wifi, with the expectation that your endpoint ends up on the list of a foreign intelligence agency who ostensibly doesn't care about you or what you are interested in.

The other best advice used to be, "don't be a terrorist," but these days, it's more, "don't be a political actor," given whatever you type will be found and used as leverage if you achieve any prominence. I'd posit that security tech is sufficient for business, but not for politics.

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

<comment><USER3> Well, your ISP is probably selling your browser history, so there is that.

</comment></comment><comment><USER4> My personal go-to is Mullvad, but yes, it still relies on trust.

It should be possible and even probably usable to chain multiple Wireguard connections together, and therefore no VPN provider would have both your identity and knowledge of your traffic, provided you pay with properly clean cryptocurrency. But if you are paranoid that all VPN providers are bugged, you'll need even more defenses, such as never using your own internet connection and, on the more nefarious side, using compromised servers as relays.

That said, a VPN plus DNS over HTTPS plus HTTPS everywhere should be good enough for dealing with threats when your adversary isn't a nation-state.

<comment><USER5> I can second Mullvad.

The only person I trust in the VPN ecosystem is the guy who runs this site: [https://thatoneprivacysite.net](https://thatoneprivacysite.net)

He writes reviews, and doesn't have anything to sell. It's through that site that I found out about Mullvad.

<comment><USER6> Mullvad is what I use. I started using it after I saw the Manjaro folks discussing it, and it's all I use for VPN when I'm not using Bitmask. I pay in Bitcoin Cash.

Those interested in getting started with WireGuard on Manjaro Linux see detailed instructions here: [https://habd.as/post/encrypted-internet- wireguard-manjaro-li...](https://habd.as/post/encrypted-internet-wireguard- manjaro-linux/)

<comment><USER7> Why Bitcoin Cash and not Bitcoin?

<comment><USER5> Not OP, but I use Cash instead of Bitcoin because transactions are cheaper and faster.

</comment></comment></comment></comment></comment><comment><USER8> I think it's worth keeping in mind that there are multiple different reasons that people use VPNs, and that different solutions are appropriate for those purposes.

Some want security, they want to be sure that the local network operator/ISP/government isn't monitoring their traffic. Those people should run their own VPN at a trusted location.

Some want to evade geoblocking or use P2P services without fear of copyright letters. This is what commercial VPN providers are for IMO.

Some want anonymity. Normal VPN services can't really provide this, but Tor and the like can.

\---

Personally my focus is on the security side of things. I have a VPN endpoint at home for personal use and a similar setup for my company. If I'm going somewhere particularly untrusted I'll set up a temporary VPS with a trusted provider just for use while I'm there and trash it afterward.

</comment><comment><USER9> You can run your own VPN with a little know how and determination. I have two servers which cost $20 / month ($10 each). Each running openVPN, then I share the keys to my laptop and desktop. Haven't done mobile, but I could probably figure that out.

The real trick, is VPNs need a lot of bandwidth and compute. Get a bare metal server with unlimited bandwidth.

I switch between the servers to limit how much data each provider can collect. Not perfect, but I also have ProtonVPN and use Tor periodically. This means I have at least 4 ways my traffic goes out. It's just about the best I can do

<comment><USER10> Can you recommend some sort of introduction/book to VPNs? I get the idea, I have read the wikipedia page, but my understanding boils down to "one server encrypts and sends small packets, the other decrypts". The packets still go through the public internet / your ISP, but they are encrypted?

<comment><USER11> You can consider a VPN service as sitting between you and any server or site you access. The traffic still has to go through your ISP and the public Internet (for this scenario). The VPN service does encrypt the traffic from your device to the VPN server (and back). This allows you to hide your browsing history from your ISP and anyone snooping on your ISP. They'd just see encrypted packets going to the VPN servers.

But the traffic from the VPN server to the site/server you want to reach may or may not be encrypted, depending on whether it would or would not be encrypted if you were to access it directly.

As far as the end site/server is concerned, it gets requests from the VPN server, and so it cannot (easily) know that the request is really coming from your device's IP address. This is how circumventing geographic restrictions works. If you want to access, say Netflix US, you'd use a VPN server with a US IP address, while you may be in some other country altogether. There are content providers who detect VPN usage and try to block them.

P.S.: There's a lot of simplification in the above descriptions.

Edit: This page [1] has a good explanation on VPNs.

[1]: [https://thebestvpn.com/what-is-vpn-beginners- guide/](https://thebestvpn.com/what-is-vpn-beginners-guide/)

</comment></comment></comment><comment><USER12> I only use VPNs for downloading torrents, basically just to avoid nasty letters from the cable company.

</comment><comment><USER13> I know private internet access has proven in court that they don't keep logs, but still, trust.

<comment><USER14> Some sources:

[https://torrentfreak.com/private-internet-access-no- logging-...](https://torrentfreak.com/private-internet-access-no-logging- claims-proven-true-again-in-court-180606/)

[https://torrentfreak.com/vpn-providers-no-logging-claims- tes...](https://torrentfreak.com/vpn-providers-no-logging-claims-tested-in- fbi-case-160312/)

Of course, there's still need for some level of trust, but I think when it comes to VPNs, having public court records of the VPN provider saying they are unable to provide data in response to a subpoena is probably as good as it gets.

<comment><USER15> Any other VPN you know of that have been proven in court as well? Thanks.

</comment></comment></comment><comment><USER16> Another vote for hosting your own. I used to roll my own VPN server but switched to Algo since it is easy to roll out and supports most major VPS providers.

[https://github.com/trailofbits/algo](https://github.com/trailofbits/algo)

<comment><USER17> I was doing this for about 2 years on DigitalOcean. But early this year they stopped accepting prepaid credit cards as a means of payment (I had been buying prepaid Visas from Wal-Mart with cash).

Since then I haven't been using a VPN... perhaps I'll try again on Linode or something. Does anyone know of a good VPS provider (or trustworthy/non- honeypot VPN provider) that accepts anonymous payments?

<comment><USER18> Mullvad is a VPN, but it has good performance, takes crypto for payment, and hasn't shown themselves to be untrustworthy yet.

<comment><USER19> Also actual cash ("5 EUR (or an equivalent amount in any other currency)" for a month), which may be easier to make anonymous than crypto.

<comment><USER17> Envelopes would be postmarked with the post code from which they were mailed. That probably wouldn't give Mullvad any information they don't already have, since they can see your IP address.

But an intercepting 3rd party could pair your account ID with with your geographic region; it would be even worse if you accidentally drop a hair inside the envelope.

<comment><USER19> Sure, it's not a silver bullet, but I suspect the risk model is better understood (post it away from me if geographic region matters, be careful of fingerprints and hair). It also has to be preemptively intercepted, rather than crypto which is recorded forever (if I pay upfront for a year, a bad actor has one shot to intercept, whereas with crypto they can _always_ analyse the transaction history to see if I've slipped up and they can correlate transactions anywhere).

I don't think either gives you an absolute guarantee[1], but cash doesn't have as many subtle pitfalls.

[1] At the end of the day, you have to assume Mullvad isn't compromised _anyway_, so even if they did, it may not help (as you can probably be identified from your traffic)

</comment></comment></comment></comment></comment></comment><comment><USER20> VPNs are the perfect vehicle for selling something warm and fuzzy to the masses with minimal deliverables. I place them right up there with military grade encryption.

<comment><USER21> Now that you mention it, "military grade x" sounds like something solid and unobtainable by civilians.

But looking deeper, "military grade x" where x is not a weapon prohibited to civilians usually isn't that interesting.

At a nearby surplus store you can buy MRE's and military clothing side by side with normal work clothes and camping gear. After a short time you realize civilians can get tastier MREs, boots and clothing that fit and work better... and they are lower priced.

<comment><USER22> I was a software dev for the military and typically the encryptions used are generally the same ones available to the public (AES, RSA, TLS). The difference is that the keys are longer that standard, ie AES-256/512, RSA-4096, TLS1.3. Additionally military grade security means multiple layers of protection. So lets say a wifi-link is protected via AES-256, there might also be channel hopping technology involved to make jamming and eavesdropping difficult. Military grade is basically overkill for most situations unless your life literally depends on it.

<comment><USER23> Doesn't wifi use frequency hopping too? Or is that bluetooth?

<comment><USER22> That's done to avoid interference and happens as minimally as possible which makes for easier signal processing. Military communications actively switch frequencies many times per second in unison according to highly secure crypto- variables. This makes jamming and eavesdropping very difficult because its hard to tell active channels from brief background static. Bluetooth, on the other hand, has about 80 channels about 1mhz apart and it tries to bond as many as possible for parallel transfers. This is why when you are far away from a bluetooth device the transfer speeds degrade rapidly.

</comment></comment></comment></comment></comment><comment><USER24> Host your own. The only way to be sure.

That said, what exactly is your threat model? Protecting yourself against literally every possible threat is a pointless effort...

<comment><AUTHOR> Sounds expensive and complicated.

What's a valid "threat model"?

<comment><USER4> Hosting wireguard on a VPS is neither expensive nor complicated. However, you then must trust a VPS provider, and the other tenants. If you use a dedi host you still have to trust the machine, network to not be tampered or bugged. If you use a colo you still have to trust the network and the staff.

If you start your own data center, lay your own fiber, and peer with ISPs and hosts, well, everyone knows who you are again.

There's no escaping trust issues 100%. The idea of a threat model is all about the trade offs, what things you will decide to trust or how you will defend yourself in depth.

<comment><USER25> Once I started really paying attention to security I thought I was being quite paranoid; you're right, there are threats that exist at every level, and tradeoffs to be made. Once I started learning about things like this I realized that tradeoffs are a must:

[https://thehackernews.com/2018/04/hacking-airgap- computers.h...](https://thehackernews.com/2018/04/hacking-airgap- computers.html)

</comment></comment></comment></comment><comment><USER26> I consider my threats to be my wifi connection and my ISP. I have a VPS, which I trust as my "starting point", that caps only bandwidth so there's no overages. I use OpenSSH as SOCKS5 proxy because I already use ssh and DNS goes over the proxy. I think ssh may limit the number of open connections because I sometimes need to close tabs to continue surfing.

My set up looks like this:

        ssh -fCND 1080 proxy-server
        socks5://127.0.0.1:1080
        export SOCKS_SERVER=127.0.0.1:1080

When I'm connected to a device that doesn't give me a routable address, I'll use a ssh jump.

        ssh -fCND 1080 -J jump-server proxy-server

This isn't a VPN but it's equivalent for my usage. I'm waiting for Wireguard to mature in Chromebook / Android. I want to try it out.

</comment><comment><USER27> Yes they do suck even if they totally truly respect your privacy and spill blood maintaining their systems, it's simply not possible to know if that's true or false and thus using a VPN service is NOT a sound method to increase your security.

Now, there are few cases that could be useful like evading those pesky private CYBER detectives that companies hire to track torrents. Also it could be used to bypass region restrictions. That's just that, i would never trust a single byte of private info to go through a VPN.

There are few services who do not try to evade the (big) question of trust and they tell you that you could use Tor through their VPN, but at that point we have already taken a first class sit to the "security theater".

</comment><comment><USER28> With Wireguard [0], setting up your own VPN [1] somewhere like DigitalOcean is an afternoon project, and is often cheaper than most VPN subscriptions.

[0] [https://www.wireguard.com/](https://www.wireguard.com/) [1] [https://www.digitalocean.com/community/tutorials/how-to- crea...](https://www.digitalocean.com/community/tutorials/how-to-create-a- point-to-point-vpn-with-wireguard-on-ubuntu-16-04)

</comment><comment><USER29> Using your own VPN vs using a VPN provider is not a 1:1 comparison. VPN providers give you access to multiple servers running on different countries. You cannot setup 250 servers all over the world just to emulate a VPN's offering. There are shared and private IP addresses etc.

If all you want to do is hide your traffic from a state level actor, then tor is a much better solution.

</comment><comment><USER30> For _casual_ privacy purposes, such as hiding Web traffic from your ISP or cafe WiFi APs, you can use Tor.

</comment><comment><USER31> Here is a good list of VPN services: [https://www.privacytools.io/providers/vpn/](https://www.privacytools.io/providers/vpn/)

</comment><comment><USER32> I'm surprised no one has suggested Outline: [https://www.getoutline.org/en/home](https://www.getoutline.org/en/home)

</comment><comment><USER33> I would honestly just host my own.

<comment><USER34> You presumably have to tell the truth about your identity to your cloud/VPS provider or, if using your own hardware, the ISP.

</comment></comment><comment><USER35> You'd be hard pressed to find a better recommendation than Troy Hunt. [0]

TLDR; Freedome VPN is really good and located in a country with strong privacy laws.

[0][https://www.troyhunt.com/the-importance-of-trust-and- integri...](https://www.troyhunt.com/the-importance-of-trust-and-integrity-in- a-vpn-provider-and-how-mysafevpn-blew-it/)

<comment><USER5> It _really_ depends what you want. Freedome (openly) logs your connecting IP address and they block some P2P ports. In addition they incentivize social media spam and make the traditional false claim of being 100% effective.

I have yet to find a "perfect" provider but this site helps learn about a lot of them at once: [https://thatoneprivacysite.net](https://thatoneprivacysite.net)

</comment></comment><comment><USER36> tor doesn't depend on it. although it's quite difficult to safely use tor. anonymity is easy (enough) to expose. some of the same flaws apply to vpn as well.

</comment><comment><USER37> It's a war-- the VPN companies against the tyrannical evil do'ers. Be thankful folks are trying to keep free speech, democracy, a spotlight on heinous, corrupt, morally absent regimes, and the truth alive.</comment>


SATNet: Bridging deep learning and logical reasoning with differentiable SAT - <AUTHOR> https://arxiv.org/abs/1905.12149 <comment><USER2> there's also this [https://arxiv.org/abs/1812.11948](https://arxiv.org/abs/1812.11948)

</comment><comment><USER3> and there's also this: [https://github.com/MatthiasNickles/delSAT](https://github.com/MatthiasNickles/delSAT)

</comment><comment><USER4> Can someone comment on the deeper distinctions between this and DeepMinds ILP paper on learning explanatory rules from noisy data? AFAIK thats a special case of SAT?

<comment><USER5> ILP and SAT are quite different. ILP is much higher level in that it can define new predicates and do recursion, which have no counterparts in SAT. On the other hand, SAT is much more scalable and can be applied to instances orders of magnitude larger. I think ILP's expressiveness and lack of scalability are related.

<comment><USER6> To complement this.

Inductive Logic Progamming (ILP) is a class of machine learning algorithms that learn logic programs from examples and background knowledge (where background knowledge is a logic theory, i.e. another logic program, as ar the examples).

SAT is the boolean satisfiability problem, the problem of finding variable assignments to the variables of a boolean formula that make the formula true.

So the two are not similar and one is not an instance of the other.

The δILP paper describes a differentiable ILP system that learns logic programs with a differentiable logic representation.

Finally, the paper above (SATNet) describes a differentiable satisfiabiilty solver that can be incorporated in a neural network architecture to enable the nerual net to solve satisfiability problems and perform reasoning.

<comment><USER7> Looks like they (SATNet) are not incorporating a real (exact) SAT solver but their differentiable "SAT solver" is a MAXSAT estimator which gives an approximation of the maximum number of clauses that can be made true.

<comment><USER6> Thanks. I should read this more carefully - I just skimmed it, to be honest.

</comment></comment></comment></comment></comment><comment><USER8> This seems like a promising direction.

</comment><comment><USER9> code: [https://github.com/locuslab/satnet](https://github.com/locuslab/satnet)

</comment><comment><USER10> Great, hopefully this'll get us past the halting problem.

<comment><USER11> The halting problem is formally proven to be undecidable.

<comment><USER12> In some senses we are past the halting problem once we accept that that we will sometimes be wrong or unable to answer. Insofar as it has anything to do with the halting problem, this seems just another way to do that. Might still be useful.</comment></comment></comment>


Comcast Is Said to Be in Talks to Acquire DreamWorks Animation - <AUTHOR> http://www.nytimes.com/2016/04/27/business/dealbook/comcast-is-said-to-be-in-talks-to-acquire-dreamworks-animation.html?partner=rss&emc=rss <comment><USER2> If anything happens that prevents them from finishing "How To Train Your Dragon 3", I am going to be very annoyed.

</comment><comment><USER3> Is there any other company who cares as little as their customers as Comcast?</comment>


Covers shouldn't just be for musicians - <AUTHOR> https://davidklaing.com/covers-shouldnt-just-be-for-musicians/ <comment><USER2> I play the guitar</comment>


Microsoft Knows Exactly Where Intel's Future Is - <AUTHOR> http://www.wired.com/2015/06/microsoft-knows-exactly-intels-future

<comment><USER2> Summary - Intel buys FPGA manufacturer, Microsoft is trying to use FPGAs with Intel processors to make Bing faster.

Kudos to Bunnie for actually already producing a laptop that pairs a CPU and an FPGA on the same board, and making it free and open source:

[https://www.crowdsupply.com/sutajio- kosagi/novena](https://www.crowdsupply.com/sutajio-kosagi/novena)

He makes the big guys look like a bunch of johnny-come-latelys

</comment><comment><USER3> When Intel applies their process knowledge to manufacturing FPGAs, they could really boost the capability of these chips and slash prices aggressively.

Now if only they could improve the _tooling_.</comment>


California Today: Why Rent Control Groups Are Taking the Fight to Silicon Valley - <AUTHOR> http://www.nytimes.com/2016/10/14/us/california-today-rent-control.html <comment><USER2> I've recently (as of four weeks ago) moved to silicon valley. I am _amazed_ at how much wasted land there is here used as car parks, or sprawling one and two store buildings, or just flat out vacant. (There is a _lot_ of vacant land.) I am also pleasantly surprised by the potential I see all around here for in- fill, and intensifying neighborhoods, or just outright building entirely new towns on top of that sprawl of car parks and office parks.

The solution to housing costs is _not_ rent control. It is better urban planning, and building more houses. Sadly half of the examples of intensification I see here are miserable, soul crushing places, huge monolithic superblocks of mid-rise cookie cutter apartments on-top of parking that you only access by driving into your building and driving out of your building.

South bay could practically be a utopia if it pulled it's head out of its car loving ass.

<comment><USER3> The housing problem in the bay area has nothing to do with space. There's plenty of space in most places, or at least enough room for greater density. Even as far out as Fairfield, you can see miles and miles of empty space, and yet all the stupid little houses are bunched up into a tiny little lot, surrounded by nothing but land.

The problem, as you said, is land use policy and regulations. All these rent control rules drive up the cost of building more housing, further constraining supply, causing even greater rent control... It's a downward spiral of epic proportions.

The true root of the problem is a lack of basic economic education. I've been viewing my voter election material, and there are countless politicians who freely admit that they've been "preserving open spaces", "preventing new construction and building" and even bragging about it! This tells you something about the general public: they don't understand (or believe in) the first thing about supply and demand. They just don't understand that more regulation leads to less supply, which leads to even higher housing prices.

<comment><USER4> > They just don't understand that more regulation leads to less supply, which > leads to even higher housing prices.

Maybe. Or maybe they understand it just fine and don't care. Prosperous anti- growth types want a) their houses to grow more valuable and b) their neighborhoods to stay the way they are. Some of the leftier ones also don't want poor people to be forced out of their homes. All of these are reasonable things to want. It's just that making them happen has nasty consequences.

</comment></comment></comment><comment><USER5> Rent control is anti-market. You can never control the rent control and end up with rich people taking advantage of it and poor people paying extra because market is adjusted without those rent controlled units...

<comment><USER6> The market is distorted. Is it sustainable when you have to make $216k/yr [1] to even afford rent (not mortgage) on a 2bdrm?

[1] [http://sf.curbed.com/2016/5/17/11692468/rent- salary-2016-san...](http://sf.curbed.com/2016/5/17/11692468/rent- salary-2016-san-francisco-)

<comment><USER7> The answer isn't to further distort the market with more price ceilings. All that will do is further mis-allocate resources.</comment></comment></comment>


Spyware Fix - <AUTHOR> This software operates a large database of viruses, spyware, malware and provides real solutions to remove these threats. Here are its other features:
It's awesome resource center wherein you can learn about the newest and most dangerous computer threats on the internet
Offers tutorials and guides on how to keep your computer protected
Avoid potential threats from infecting your system in the first place
Works hard to notify users whenever new threats arise to prevent them from becoming a victim
No need to be a pro in using this software, it's quick and easy to use. Check it out and finish the task in no time!
www.spyware-fix.net <comment><USER2> You have zero credibility for a security product if your website isn't even in https

</comment><comment><USER3> IIUC it's not a software you can download, but a blog where you post about virus removal.</comment>


Vue.js vs. React - <AUTHOR> https://vuejs.org/v2/guide/comparison.html#React <comment><USER2> We moved away from React to Vue about 8 months ago and everyone on the team is a lot happier.

First reason is we hate JSX. It forces you to write loops, conditionals, etc, outside of the markup you are currently writing/reading. It's like writing shitty PHP code without templates. It also forces you to use a lot of boilerplate like bind(), Object.keys(), etc.

Another problem with React is that it only really solves one problem. There is no official React router and we hated using the unofficial react-router for a number of reasons. A lot of people end up using MobX too.

With Vue there is no need to resort to third parties for your essential blocks. It provides an official router and store called Vuex, which IMO blows Redux out of the water when combined with Vue's reactive data.

Vue docs are probably one of the best I've used. They provide technical docs, plus excellent narrative docs (guides) for all their projects (Vue, Router, Vuex, templates, etc).

I won't say that Vue is perfect, but we would never go back to React.

If you don't like Vue but want to get out of React, check out Marko, the UI library by Ebay. It's better in every way than Vue or React except that the community and ecosystem are almost non existent.

[http://markojs.com/](http://markojs.com/)

<comment><USER3> > It's like writing shitty PHP code without templates.

For me, it's the other way around. I feel like you can still separate the logic and markup, but instead of the template engine syntax you can just JavaScript.

From the top of my head, I can at least remember six template engines' syntax I've learned: Smarty (PHP), Mustache, Blade (PHP), EJS, Angular and another custom template engine. When I tried React I was so happy that I did not have to learn another template syntax as it all was _just JavaScript_.

Another template engine syntax? No, thank you. I stick to React.

<comment><USER4> To be fair, JSX has its own idiosyncracies too for templating, such as className, htmlFor, and the obnoxious attribute name for dynamically inserted html. It is not immune to the criticism that it requires learning.

<comment><USER5> Those names have nothing to do with JSX or React, they're the actual properties you're setting. JS properties don't map 1:1 to HTML attributes: while for example the "src" attribute is controlled using the "src" property, the "for" attribute is controlled using the "htmlFor" property, and the "class" attribute with the "className" property. All React is doing is setting the properties you tell it to.

(The reason for the name change is that old versions of JS couldn't use keywords - like "for" and "class" \- as property names.)

<comment><USER6> I agree. Those examples have nothing to do with learning a new template syntax, it's simply the API of React.Component.

Granted, there is still _some_ syntax you need to learn for JSX, but it's very little. If you already know HTML's syntax, the only new things I can think of are the curly braces for using JS expressions as prop values (you also need to know what a JS expression is, lest you try to use an if statement), and spread attributes.

<comment><USER5> I think you misunderstand. The names are unrelated to React as well, they are native. Defined by the same standards bodies that define JavaScript itself, implemented by the browsers themselves. On a blank HTML page that includes neither React nor anything else, the line `document.body.className = "foo";` sets the body's class to "foo". (And `document.body.class = "foo";` does not.)

All JSX is doing is transforming `<div className="foo">` into `[create div element]; div.className = "foo";`. If you wrote `<div class="foo">`, JSX would faithfully transform it into `[create div element]; div.class = "foo";` - which doesn't work.

<comment><USER7> Whilst you're correct, that's where the names are from, it's also not totally accurate to suggest it has nothing to do with React.

React defines `React.createElement`, `<div class="foo"/>` transforms to `React.createElement("div", { "class": "foo" })`, so React could convert that under the hood to set className correctly.

Preact does something similar to allow this. However it now seems it is now too late for React for too little benefit. And there's a downside [1]:

> The JSX transform used to do that, but we don't recommend it because it's > confusing if you ever try to pass class= or for= as a prop to your own > components – you wouldn't expect to access them with a different name.

[1] [https://github.com/facebook/react/issues/4433#issuecomment-1...](https://github.com/facebook/react/issues/4433#issuecomment-143842840)

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> You'll see quotes in this thread like "The demand for both React and Vue.js is growing tremendously" thrown around. It's good to check out npm install stats to get an unopinionated comparison.

[https://npm-stat.com/charts.html?package=react&package=vue&p...](https://npm- stat.com/charts.html?package=react&package=vue&package=angular&from=2016-01-01&to=2017-08-19)

In reality, React is downloaded roughly 4-5x more than angular and 7-8x more than Vue. In August so far, React has 75% market share among these three libs. Interestingly, this share has grown in August compared to both last month (July) and beginning of year (January).

While this thread and the license thread might indicate that React is dying, it's not. It's growing.

If Vue is going to be what React is today, it has quite a long way to go.

<comment><USER9> Something worth noting is that both Angular and Vue are far more script-embed- directly-into-page friendly (mostly due to templating) compared to React. Almost all React users get it from NPM, while I would expect that the proportion of Angular or Vue users who get them from NPM is lower. I've seen a _lot_ of projects for those two run without any build system (and anecdotally, I'm pretty sure I'm not the only one who's learned Vue with just a script embed).

<comment><USER10> Perfectly said. I've used Vue for a couple of months now (a couple personal projects, experiments and some dashboards) and used Angular for ~2 years before (admittedly, mostly Angular 1), and have literally never had to start off from 'npm install', unlike react (which I used for a year or so before), where everything needed a lot of boilerplate setup.

Most devs I know start a react application by cloning some standard git repo which has a working webpack/tidyCSS/redux/some test suite etc. and then write your first line of useful code. The boilerplate is enormous!

<comment><USER11> Most Angular 1 projects I saw would start off with a Yeoman/Bower MEAN stack implementation. The boilerplate no less enormous there. I'll admit Vue is nicer about these things than either Angular or React, but Angular has tons of boiler plate.

</comment></comment></comment></comment><comment><USER12> I've built semi-large applications in both Vue.js and React. I like both but prefer React.

For me Vue.js is like a light-weight Angular 1, in a good way. It's very intuitive and you can start working immediately. It does however easily end up in confusion about where the state lives with the two-way binding. I've run into a lot of implicit state changes wrecking havoc. The declarative nature of React definitely wins here, especially working with stateless functional components. If you're serious about Vue you should adhere to unidirectional bindings, components and use Vuex.

The best thing about Vue.js for me is the single file components. It's such a nice feeling to know that everything affecting a certain component is right before your eyes. That's also the reason I started adapting CSS-in-JS in my React components.

The biggest problem for me with Vue.js is the template DSL. You often think "how do I do this complicated tree render in Vue's template syntax? In JSX I would just use JavaScript". For me, that was the best upgrade going from Angular to React and it feels like a step backwards when using Vue.js.

<comment><USER13> I have been building web apps for 19+ years. I like many of the frameworks out there but for some reason I HATE React. I think JSX is a huge turnoff for me. I just can't get past html in javascript. It feels wrong.

With that said, there are so many VERY smart people embracing React, so I am always questioning my "hate". Maybe one day I will change my mind.

I haven't use Vue but watched/read about it and seems very cool and simple to use.

For now, my favorite framework by far is Ember JS and it really blows my mind why it is not the most popular framework out there. The amount of stuff you get out of the box and the incredible productivity and happiness it brings to the developer experience is IMPRESSIVE. It will take you 2 weeks of work to make a new React app have the same feature set as an Ember app*

* I could be wrong.

<comment><USER4> Interestingly, I had recently joined a team that was using Ember, and we found that Ember hampered our productivity. We switched to React and was able to rebuild 4 months of Ember work in about 3 weeks of work in React (not sure how many developers were working on the Ember app originally, but it was mainly 2 of us who built the React app), including requisite tests.

I'm of the opinion that Angular is much better than Ember (note: I have 4.5 years of experience in the Angular ecosystem, including in open source), and I think I am overall perhaps more productive with React than Angular, although I feel like there are less issues with state management in Angular, which has been a pita in React. All the libraries/frameworks have various tradeoffs ultimately, so I don't believe there is a cure all for everyone's preferences.

A note about JSX - I am not a big fan of it, but I see it more as having tradeoffs like more traditional templating languages, but different ones. I have been a bit resigned that this is the direction the ecosystem has turned towards, so I have personally decided to hold that dislike more loosely and focus on more important architecture issues. It does little good to let dislike over style paper over higher level issues if you can help it IMO. I don't think we'll ever see a perfect template language.

<comment><USER14> A rewrite is always going to take less time to build than the original poorly- specified version when people were trying to figure out what to do.

And the original team could have been more junior, or if similarly-experienced than your 2-person team, adding more people to the team without good leadership can also affect productivity---or as they say in Scrum, "velocity".

</comment></comment></comment></comment><comment><USER15> In this thread people are fighting about their _opinions_ why they use Vue.js or React. And why X is really better than Y.

In reality these programmers don't want to have the feeling they might have made the wrong choice when they used X instead of Y. The idea that they might have taken the poorer choice hurts so much that they need to defend their decision so heavily while in reality taking ReactJS or Vue.js is like ordering pizza or pasta. You usually don't want to have both at the same time. So you need to explain why pizza is better than pasta tonight. Only that you usually have to stick longer around with Vue.js or ReactJS once chosen. Enjoy your choice and solve real problems, but stop fighting about it, programmers. Pasta and pizza will always both win.

<comment><USER16> You can't compare react and vue with pizza and pasta. Pizza and pasta are two finished products, while react and vue are two different ways of building the same product. Your comparison doesn't make sense at all to me.

<comment><USER17> Say you're about to cook pizza or pasta, you use flour and tomato for both. Comparison not 100% off IMO.

<comment><USER16> No. 1000 times no. For the pizza base you use flour, water, salt and yeast. For _fresh_ pasta most of the time you use flour and eggs. The process moreover is _completely_ different. You NEVER use tomato for making the fresh pasta or the pizza base. You _may_ use tomato as a condiment for pasta and pizza. This comparison is even more wrong than comparing apples and oranges. But I expect that unlike me you never cooked pizza and fresh pasta if you can't see the obvious difference.

<comment><USER17> In fact I'm a seasoned pizza cook but pasta is still a pending subject of mine.

<comment><USER18> _In fact I 'm a seasoned pizza_

I completely misunderstood your comment. I might need to go get food soon.

</comment></comment></comment></comment></comment></comment><comment><USER19> To me the whole idea of client-side HTML templates seems bad. They start out easy enough, but then they either limit you in power or introduce new and weird concepts to replace things that are easy, familiar and often better designed in the host language.

Here is an example on which I'd love to be proven wrong:

[https://jsfiddle.net/j2sxgat2/2/](https://jsfiddle.net/j2sxgat2/2/)

Its a generic spinner component that waits on a promise then passes off the fetched data to any other custom jsx. It can also take onFulfill and onReject handlers to run code when the promise resolves.

The concrete example shown in the fiddle renders a select list with the options received after waiting for a response from the "server". An onFulfill handler pre-selects the first option once data arrives. The observable selected item is also used from outside the spinner component.

With React+mobx and JSX its all simple functions/closures (some of them returning jsx), lexical scope and components. With Vue I'm not sure where to start - I assume I would need to register a custom component for the inner content and use slots?

<comment><USER20>
        or introduce new and weird concepts to replace things that
        are easy, familiar and often better designed in the host
        language.

Oddly, that's exactly how I feel about the "{condition_expression && template_evaluation}" idiom in JSX.

<comment><USER19> Personally I prefer the ternary operator in those cases, however I think do expressions will fix most of the if/else awkward stuff: [https://babeljs.io/docs/plugins/transform-do- expressions/](https://babeljs.io/docs/plugins/transform-do-expressions/)

<comment><USER21> Can that actually help react look better here? I'm currently imagining:

      { do {
        if (condition_expression) {
          template_evaluation
        }
      }}

<comment><USER19> For a single expression some of it can be omitted:

      { do { if (condition_expression) template_evaluation }}

But I gues thats not really better.

I'm hoping jsx will eventually default to `do` expressions though, and then it becomes

      { if (conditional_expression) template_evaluation }

</comment></comment></comment></comment></comment><comment><USER22> I used React for a few years and it was great and powerful, there were many things however that I disliked.. Particularly I was not a fan of JSX. I liked React but I did not feel comfortable using it.

When I first saw VueJS I had a hard time understanding how it would be any better than React, that is until I saw single file components.

[https://vuejs.org/images/vue-component.png](https://vuejs.org/images/vue- component.png)

I fell in love with the eloquence of being able to separate my HTML, JS, Styles for a single component.. it seemed /right/ to me..

In any case, I've been using VueJS ever since for my new projects moving forward and I'm very happy with it. It has everything I would ever need from React but in what I feel is a more polished and thought-out way.

Just my two cents :)

<comment><USER23> Completely agree! Single-file components are more natural to how I think about the web.

It's worth noting that Vue also supports render functions with JSX ([https://vuejs.org/v2/guide/render- function.html](https://vuejs.org/v2/guide/render-function.html)).

<comment><USER24> One of the reasons I moved to vue was the template section allowed normal html. Saved me so much time styling.

I do like jsx for simple things but always felt it bogged down the design piece having to convert even if its just the class to className

</comment></comment></comment><comment><USER25> I've used both. What makes me pick Vue in the end is the fact that there is no compiler needed, no jsx and all the non-sense that goes with that.

If you want a full blown huge application to last years, then go Angular... Although who knows if Angular will be there in 5 or so years.

There is no perfect library/framework but I love Vue because Vue does exactly what it says on the tin.

<comment><USER26> No application lasts "years" nowadays, so I'd suggest not go "go Angular" simply because it's Angular. The modularity and speed-to-productivity of Vue is the reason I choose it. Plus, the community is quite supportive; always nice.

<comment><USER27> I work near, but not directly on, an application that's lasted about 20 years so far. It's still actively maintained, and still making money. It's mostly written in vb6 and classic asp. Yes. Some applications far outside the hype cycle can last decades.

</comment></comment></comment><comment><USER28> In a way VueJS is "React for those who liked Angular1".

I've done many Angular apps. I've done a bit of React (with Reflux & Browserify).

I tried moving to React/Redux/Webpack but it's not an easy task to grasp the whole thing. Webpack itself was close to make me throw the towel on side projects.

I tried VueJS because of a job interview and quite liked it and got productive really fast thanks to good documentation and my previous experience in angular & React.

Professionally I wouldn't mind any of those but for side projects it will be VueJS from now on.

As a side note I don't get why all the boilerplates always mix backend and frontend code and dependencies. If you're not interested in a node backend and learning it's overwhelming.

The worst thing is that boilerplates you find are always outdated (router, hot-reloading etc) and worst of all mingling server and client deps so if you're not interested in a node backend you have to

<comment><USER29> I feel like a broken record, but definitely take a look at create-react-app if you haven't already. Its extremely well documented and takes care of managing the 20+ dev dependencies that are typically associated with a project.

<comment><USER28> It's useful but doesn't take care of state management AFAIK which can be a big part.

</comment></comment></comment><comment><USER30> Another option that is interesting right now is Polymer 2.x if you haven't tried it recently, give it a shot.

[https://vuejs.org/v2/guide/comparison.html#Polymer](https://vuejs.org/v2/guide/comparison.html#Polymer) There are some similarities shared between polymer and react/vue (personally only used react and angular 1.x before).

I've built applications with it using polyfills and things worked just fine with legacy applications on IE10 + jquery interacting with web components.

Performance is nice, there is more and more adoption from giant enterprises like Netflix, IBM, GE, Gannett, Electronics Arts, CocaCola, ING, BBVA.

Webcomponents.org has over 1k components to choose from and is growing.

Now with `lit-html` arriving soon we might see alternative to JSX if someone wants that, polymer-redux or polymer-uniflow is available as an option too.

[https://hnpwa.com/](https://hnpwa.com/) \- one of fastest Hacker News implementations is based on Polymer - and that is even without SSR.

SvelteJS also seems nice, although it seems one-man project for now :( On Polymer end I hope that on the summit next week they will announce proper NPM support finally and I miss that.

<comment><USER31> I used Polymer 2 to build a couple of highly used internal web components recently. And I'm currently in the process of ripping it all out. Why? It's not technically Polymer's fault, but the performance and stability on iOS and Safari are complete crap. Often crashes the browser on both desktop and mobile.

Also, the Shadow DOM is one concept that I liked in theory and hated in practice. Made it very difficult to do very simple styling tasks that were accomplished easily with plain css and proper naming (e.g. having parent components provide default styles for child components).

The polymer bundler in 2.0 is a buggy mess (it's still in beta) and I couldn't find any decent way to use Webpack with Polymer.

Many other complaints about Polymer that I won't go into. It's way too green in my opinion and I'd recommend avoiding it for at least the near future.

<comment><USER30> I got into same problem you had - the trick is to have view/parent components not use Shadow DOM - then you can use normal css styling, or alternatively prepare a `shared-styles` file that will contain styles shared across elements.

IMO having everything inside Shadow DOM is an anti-pattern.

I use my own pipeline based on gulp so I don't know much about polymer bundler, webpack support was recently added though, I haven't used it yet.

</comment></comment></comment><comment><USER32> For anybody looking into vue.js for the first time, I highly recommend starting with Laracasts series of screencasts which I found much more helpful than the information on the vue.js site itself when I was getting to grips to with it:

[https://laracasts.com/series/learn-vue-2-step-by- step](https://laracasts.com/series/learn-vue-2-step-by-step)

</comment><comment><USER33> These are the things I find to be killer features of React and it's ecosystem:

\- React Native (I know there's Weex but it's not production ready, nor as feature rich)

\- _Streaming_ server side rendering

\- React Relay (GraphQL integration)

\- JSX _by default_. VueJS pushes an Angular-esque template language where I have to learn new syntax, binding concepts, directives and conditional statements.

\- Corporate backing

I've used React in very large projects, where these features have been fairly critical. React's licensing is odd but not odd enough for me to ditch it. I'd really hate to see the community churn once again on frontend libraries, but that's JavaScript for you I guess.

<comment><USER34> i was in the same boat as you regards to syntax but in 10 mins you will grasp everything about vuejs.

of all the frameworks, vuejs has the simplest syntax to learn. its no where as complex as angular and way more elegant. also beats jsx in terms of making your code more cleaner and prettier. im never going back to jsx.

<comment><USER35> Which part of this is clean or pretty?

       <button v-bind:disabled="isButtonDisabled">Button</button>
       <div v-bind:id="'list-' + id"></div>
       <form v-on:submit.prevent="onSubmit"></form>
       <a @click="doSomething"></a>

There are _some_ redeeming qualities compared to say, Polymer. But it's neither clean nor pretty

<comment><USER36> You can make it cleaner:

       <button :disabled="isButtonDisabled">Button</button>
       <div :id="'list-' + id"></div>
       <form @submit.prevent="onSubmit"></form>
       <a @click="doSomething"></a>

<comment><USER37> Vue allows you to use Pug syntax in your templates, so this can be even simpler:

      button(:disabled='isButtonDisabled') Button
      div(:id='`list-${id}`")
      form(@submit.prevent='onSubmit')
      a(@click='doSomething')

<comment><USER38> I'm sorry but that is hideous.

JSX is incredibly simple. Why would you do _that_ to yourself and other devs?

<comment><USER37> Eloquently put.

</comment></comment></comment></comment></comment></comment></comment><comment><USER39> What's with the hate for JSX? I think handling HTML as data makes much more sense and is much more convenient than dealing with dumb templates or weird DSLs like Vue's or Angular's.

<comment><USER40> JSX is closer to JS than HTML, which means it annoying to write in some cases. Quick, what does this render as?

      <a href="...">Link 1</a> |
      <a href="...">Link 2</a> |
      <a href="...">Link 3</a>

It's not

      Link 1 | Link 2 | Link 3

as you'd expect - instead, the whitespace after the pipe character is eaten by JSX. This is because HTML is whitespace sensitive, but JS is not, and so to allow indentation, JSX trims whitespace.

Here's another -

      <dl>
        { Object.entries(definitions).map(([term, definition]) => (
           <dt>{ term }</dt>
           <dd>{ definition }</dd>
        )}
      </dl>

This does not work - instead, you need to return an array, but the result is ugly - the commas are part of JS, not HTML, and don't appear in the output, but reading this quickly it's hard to see that (the difference is the braces surrounding the block).

      <dl>
        { Object.entries(definitions).map(([term, definition]) => ([
           <dt>{ term }</dt>,
           <dd>{ definition }</dd>,
        ])}
      </dl>

Vue's 'weird DSL' _is_ HTML (the same is not quite true for Angular's). What you see is exactly what you get. Having a DSL also means you can define your own syntax. Things that are verbose (due to historical reasons in JS), such as iterating over an object, can be made simple -

      <dl>
        <template v-for="(definition, term) in definitions">
          <dt>{{ term }}</dt>
          <dd>{{ definition }}</dd>
        </template>
      </dl>

<comment><USER39> Good point about the whitespace, but I'd still rather have the templates inside my code than separate the two, mentally parsing two separate languages with different syntax and stitching them together is a lot more mental overhead IMO.

<comment><USER40> It's a matter of personal opinion, but I guess I'm more used to server-side templating languages, which Vue's looks much more similar to. I have the same problem as you for JSX - I keep trying to read it as HTML, except it's not, and mentally translating it is annoying.

</comment></comment></comment></comment><comment><USER41> One of the biggest things React has going for it, other than being maintained by Facebook and having a much larger community, is React Native. You can learn one web framework and now also make compelling, real native apps. To me those are both deal makers.

Surprised I haven't seen this mentioned more in the thread.

<comment><USER42> Or you can just compile any HTML5 mobile app using Cordova and in 99% of the cases your users won't notice any performance difference between native-app and HTML5 app.

<comment><USER43> Maybe for extremely simple webapps that might be true, but for any non-trivial Cordova+React based app you can't come anywhere close to the UX you can get with React Native without some extreme engineering effort. I'd much rather eat the cost to port the HTML5 app to React Native instead. Yes, the users DO notice.

Inability to have the same level of control over soft keyboard behavior is one of the top problems with Cordova, IMO.

Source: wrote & maintained a Cordova+React app on iOS/Android for 3 yrs.

<comment><USER42> Yeah, you are right, I was mostly referring to the performance part. If you need native UI elements or native UI interaction it's harder to do that in a HTML5 app.

I mostly worked on games, where the UI is custom and there are very few similarities to the UI of the OS, so it worked pretty good.

</comment></comment></comment></comment><comment><USER44> My #1: download vue(.min).js and you are ready to go. No packagemanager, bundler and what not needed.

<comment><USER45> You can do the same with react. Unfortunately with either library you are going to want it for any serious project.

<comment><USER46> This whole "React is complicated" is a strawman.

How is JSX more complicated than any template language?

How are Vue components any simpler than React components?

<comment><USER9> You can't write JSX without a template compiler (how ergonomic is it to hand write a render function?). It's painful to write React components with just a script embed (this might not be important to _you_ , but it's important for newbies coming from jQuery), while Vue lets you get away with HTML attributes and Vue.extend(). Lastly, Vue's style scoping is superior to anything React has to offer.

<comment><USER46> Hu?

You can write JSX with just script embed.

<comment><USER9> ..How? You'd just get a syntax error. Embedding a runtime babel compiler isn't mentioned in the docs at all (though I guess it would work albeit killing load performance, but it's not something that you would expect newbies to know, especially if it's not in the docs).

</comment></comment></comment></comment></comment></comment><comment><USER47> I happily used Angular 1 for a few things. When it became clear that Angular 2 was the party line, I looked at it and unfortunately found an overengineered framework chasing what React was.

I looked at React, but without a cohesive framework, that ecosystem is just a bit too much of a mess. A gazillion starter app templates that can't quite agree and always seem a little out of date with the fast moving components. JSX is just ugly. At least to me. I regularly use Django templates, so the clean leap to Handlebars-style templates feels very natural to me. Redux is straight up unapproachable to someone new to the concepts, but at the same time it feels like it simply reinvents events and event handlers.

Vue was a revelation. It is simple, cohesive and I feel productive.

</comment><comment><USER48> I know this is about Vue vs React, but a lot of the things people are saying they like about Vue can be found in Google's Polymer. It's very simple to comprehend and you can make single file components. And it's based on W3C standard web components so you won't be building yourself into future obsolescence. With Polymer 2 components are now built using classes, so your code is clear and 100% native JS. Lastly, the goal of the Polymer team is to get rid of Polymer by advancing web standards, and with 2.0 you can see they are definitely following this approach as Polymer doesn't add much to web components other than ease of use functionality such as template binding and cross browser shims.

<comment><USER49> I've used polymer and I wasn't impressed. I found it was much slower than Vue and the docs left a lot to be desired.

<comment><USER48> What was slow about it? Depending on how you use template binding, it should be as fast as anything else.

<comment><USER50> It's possible he was using Polymer v1, which was pretty slow.

Polymer v2 in a web browser that supports Web Components v1 should be pretty fast, though. But that was only released last May.

</comment></comment></comment></comment><comment><USER51> This discussion might just get a lot of light just cause of Facebook rejecting the licensing issue.

<comment><USER52> Absolutely. I just checked and vue.js uses the MIT license which would seem to be much more startup (and investor) friendly than the React license.

</comment></comment><comment><USER53> I used both react and Vue, and I would always choose Vue.js over react. beside all the features Vue has, its the documentation that I really like. it makes you want to read more and more.

</comment><comment><USER54> Elm is also promising: [http://www.oreilly.com/web-platform/free/files/why- elm.pdf](http://www.oreilly.com/web-platform/free/files/why-elm.pdf)

<comment><USER55> I'm using react and like its functional approaches. I started implementing libraries such as immutablejs, recompose and ramda. I also make use of pure functional components exclusively. Then I had a look at Elm and I realized that, with all the libraries I have put together, I created my own crippled frankenstein'ish version of Elm. I think I really should give Elm a try!

<comment><USER56> Agree that Elm is a good all-in-one solution for SPAs.

You should also give ClojureScript with the simple React-wrapper Reagent a spin. All the functional stuff is built into the language, like Elm, albeit without the types, which both has its pros and cons.

</comment></comment></comment><comment><USER57> I don't know why inferno isn't more popular, I use a lot of html5 apis so for what I'm working on inferno is more useful to me than react or Vue. I'm doing webaudio so react native doesn't help me. Also inferno doesn't require me to enter into a patent agreement with Facebook and yet I get all the benefits of react from using inferno. Now if I were needing to use native APIs then I might need react native but then you have to balance that need with the potential license issues

</comment><comment><USER58> I'm currently investigating Vue to see how it compares to the current React code I have. So far I'm liking it.

The main things that I like so far;

* Single file components - I actually _really_ like this, I find it much easier on my brain to have everything related to a component in the same file.

* The router and data modules - having the router and Vuex as "official" parts of the ecosystem (as opposed to in React where they are "adopted") means that everything just clicks.

* Styling - when I first started out with React, it was a pain to find a nice way to do CSS - do you use modules? Just have files that you import? Inline? Having it automatically scope the styling to the component if wanted, or using modules if thats your thing - is so much nicer than having to think about it. I just add <style lang="scss" scoped> and I don't have to worry.

The only downside I have at the moment, is having to learn the "v-" bindings (which is what put me off Angular when it first came out) but I think that it is something I can live with. Although you can use JSX and have a render method so I might try that and see how that flows for me.

</comment><comment><USER59> For me, the best thing about jsx is the fact that it's so easy to create different implementations of `React.createElement` to solve different problems outside of the scope of React itself. Want a render function that uses jsx but returns a string, a DOM tree, or something entirely different? Totally possible! I didn't like jsx at first, but the fact that it's so decoupled from React itself counts extremely in its favor, in my view.

For example, for one of my libraries I wanted a really simple way to allow people to include custom templates. I started with string-based templates, but quickly realized that this was inflexible for any kind of event binding or later dom mutations. Achieving that was super easy with jsx -- I just implemented a custom jsx function which directly outputs DOM elements.

Step 1: implement a jsxDom function [^1] which takes (name, props, children) (e.g. [https://github.com/krakenjs/xcomponent/blob/master/.babelrc#...](https://github.com/krakenjs/xcomponent/blob/master/.babelrc#L11))

Step 2: point babel to my jsxDom function (e.g. [https://github.com/krakenjs/xcomponent/blob/master/src/lib/d...](https://github.com/krakenjs/xcomponent/blob/master/src/lib/dom.js#L938-L1015))

This even allowed some cool hacks like including iframes directly in the jsx, to sandbox sections of the page (since the library is geared towards creating components to be embedded on 3rd party sites):

      containerTemplate({ jsxDom }) {
        return (
          <iframe>
            <style>
              p {
                margin-top: 40px;
              }
            </style>

            <p>I can be sure the styles in this iframe won't affect the parent page</p>
          </iframe>
        )
      }

</comment><comment><USER60> How are people getting along with Vuex vs Redux?

It looks pretty clean and grokable in the examples and deals with async out of the gate -

[https://github.com/vuejs/vuex/tree/dev/examples/counter](https://github.com/vuejs/vuex/tree/dev/examples/counter)

<comment><USER61> If you use something like Kea ([https://kea.js.org](https://kea.js.org)), the amount of boilerplate for Redux goes down dramatically. The syntax is actually pretty simiar to Vuex, perhaps with even less boilerplate.

<comment><USER60> You've done a nice job with kea. The examples are pretty clear. Somehow the selection of verbs and structure is more readable for me in the vuex example but I'm not sure you could do much about that.

I won't be using this as it definitely sets off my library-depth spidey sense.

The multiple libraries it abstracts would all change versions over time and lead my applications to be even more brittle.

Vuex being mainline with Vuejs is a major plus as I look at its long term stability, though whether it insists on vuejs I need to look into.

<comment><USER61> Hey, thanks for the comments/feedback!

For the library-depth spidey sense, there's really no getting around that. In a way, as React itself is just the view library, you're forced to add new pieces to your app until it all clicks together. Kea is just one more of these pieces... And I wrote it so the other ones would click together. The alternative to abstracting libs like that is to write and bundle everything yourself, but that is a hard and, in this case, unnecessary path to take.

Two of the libraries it abstracts (redux and reselect) are as stable as a rock. There have been no breaking changes for many major releases. The third one, redux-saga, is a bit more brittle, but as it gets passed direct control over its domain, I don't see how kea would break anything there, at least not in the near future.

Of course I'll do my best to keep up with new releases of all dependencies. I do have a few apps with Kea that I actively maintain.

There's still the chance that Kea itself will change drastically. I hope not. I'm actually trying to stabilise the API for a 1.0 release.

</comment></comment></comment></comment><comment><USER62> Go for Ember: \- Proven tech \- No licensing issues \- Solid community \- Community driven, no company calling the shots

<comment><USER63> I was a huge Ember evangelist until I started trying to onboard other devs into my project. It took months for people to figure out which way was up. In comparison, other devs picked up Vue in a week or so.

<comment><USER64> Interesting, because my company chosen Ember precisely because it would start a hiring wave of new developers, often junior ones. Mostly because of Ember's "convention over configuration".

I dont see much of this problem, including myself as one of these just hired jr devs.

<comment><USER63> The projects I work typically have very fast turn around times (2-4 months), so I don't have the time to teach a dev use a framework, and I definitely don't have the time to onboard junior developers.

I need a framework where any experienced JavaScript developer can pick up the project and deliver working product in a week. With Ember/Angular/React+Redux, I have to hunt for a developer that specializes in that particular framework. With Vue, the hiring pool is vastly larger.

</comment></comment></comment></comment><comment> vladimir-y Vue.js is going to win because simplicity and easier bootstrapping matter. In the same time Vue.js is powerful enough for building the complex and scalable apps.

<comment><USER65> Onboarding green devs into anything more than a simple Vue app is a lot more complex than a React app of similar complexity, from my experience.

The simplicity of the nested, inception style architecture of React makes it super easy to onboard and up-ramp.

<comment><USER66> Couldn't disagree more. Or perhaps, more accurately, I think the scenario you are referring to isn't the one that matters.

It's not about taking a massively existing complex application written using one of VueJS or React and onboarding someone completely green into it. Adoption is about "how easily can I incrementally adopt this technology into my legacy app". And the problem is that React is nearly unusable without switching entirely over to a Webpack / transpiler system and learning JSX, which makes it almost a non-starter for someone who isn't planning a major rewrite of their legacy app front end. By contrast VueJS "just works" after dropping a simple JS bundle into a page and the first templates you write are barely distinguishable from regular HTML. You can start by just enhancing the odd page element here and there, and slowly build up to a fully based VueJS app.

<comment> vladimir-y > learning JSX

Not just learning, JSX/React.createElement approach is the hell itself, it increases the technical debt every time you use it, but some people prefer to make a blind eye to this. When juniors come to work with React I guess it makes them think that React way is the only way, but it's more like the 10 years old PHP code.

Let's imagine that for some reason in 2-3 years there will be a silver bullet like framework. So most likely hipsters will be going to switch to it and I'd like to see how they will be cherry-picking all the template's parts from the JS/JSX code to the single holistic template (I don't think the sliver bullet like framework will follow the mixing template with code ideas).

</comment></comment></comment></comment><comment><USER67> The single best argument for vue is that we should not support large internet monopolies. vue is so awesome even more so once you realize that it is basically driven by a single person

</comment><comment><USER68> Actually my major complaint of React is the state of state. There seems to be no common knowledge about how to do this right. I just joined a team that has two React projects that development started about two months ago (I just joined like a week ago). There is a a large component that I am working on that is completely bound to Redux. There are major state update issues and the team had opted to assign IDs and data to the DOM elements and use those to look up state in the redux store before modifying it. On top of all that, the application is completely unable to handle 2 instances of any component they wrote. I am trying to re-write some of it to encapsulate the state in at the component level. It's pretty awful compared to the Angular (not AngularJS) app I recently rolled off of.

Edit : Also wanted to add, while I think a lot of people really don't like JSX, I actually do like it but I think someone could take that aspect and come up with a better state management system outside of redux and friends. I think something along the lines of Angular (not AngularJS) with JSX would be great.

<comment><USER69> > There are major state update issues and the team had opted to assign IDs and > data to the DOM elements and use those to look up state in the redux store > before modifying it.

This sounds awful and seems like an anti-pattern. I don't think this anything to do with React (other than perhapps that React gives you the freedom to do things wrong). Your devs don't have a proper understanding how React (or Vue) works. Define state model, define view, modify/interact with state, let React modify view. That way you'll never need dirty hacks like fetching state from Redux by using the DOM ID.

</comment></comment><comment><USER70> Maybe a bit off-topic, but not so much IMO.

Everyone talks about react, angular and vue.js. How about Polymer?

What are your experiences with it, if any? I'm no expert in either technology, but Polymer seems much more lean, needs no build process as far as I know, and is quite flexible.

Why wouldn't it be an option to replace react/angular/vue? Any thoughts?

<comment><USER30> It is an option to replace other frameworks - I've built an SPA with it, it was very clean and natural feeling to me.

Building Polymer components is very similar to building Angualar 1.5 `component()`s or react components (or actually any component system for that matter).

New elements are true DOM nodes which is quite an advantage in my opinion.

You can add redux/uniflow on top of that or some vdom lib like preact too if you need that - I wonder what will come out of `lit-html` that is supposed to be vdom alternative.

One interesting thing one should understand that applications view components that are not meant to reusable should NOT use Shadow DOM (just regular DOM)- this way you can use bootstrap or whatever else to provide "traditional" styling of your application.

BTW I think right now Polymer also requires a build process - because 2.0 is written in ES6 so that means building to support older browsers like IE10/11.

</comment></comment><comment><USER71> I experimented a little bit with Vue. I was a little bit disappointed about two points:

1\. I couldn't CSS style a Vue component. I find components very important and they should behave like HTML elements. It should be possible to write a <video> element in Vue if that element didn't exist.

2\. I find the state management Vuex somewhat an afterthought. Some people say you will know when you need state management, but I think if the integration of state management is really seamless there is no need to avoid state management even for the most simple apps. So don't listen to these people and start with Vuex straight away, even if it takes a little bit more effort.

I'm sure that there are more points for an even better solution. However for the moment Vue seems to me the simplest, the most elegant and most intuitive framework. So I will use it for my future projects.

<comment><USER9> One of the biggest selling points for single file components is styling (with optional scoping): [https://vue-loader.vuejs.org/en/features/scoped- css.html](https://vue-loader.vuejs.org/en/features/scoped-css.html)

If you need to override child component styles from a parent (bad idea in 99.999% of cases), /deep/ would work.

<comment><USER71> Vue components are second class citizens compared to HTML elements, because you don't style them, you pass them props.

This idea with stylable components is for a different framework, perhaps.

</comment></comment></comment><comment><USER72> Vue.js is like perl. Too many ways to do a single thing

<comment><USER73> Out of curiousity, examples?

<comment><USER46> They bait newbies with their easy data-binding and switch them to components later.

</comment></comment></comment><comment><USER74>
        In React, everything is just JavaScript. Not only are HTML structures expressed via JSX, the recent trends also tend to put CSS management inside JavaScript as well.

for me this is the deal breaker, just JS should be enough.

</comment><comment><USER75> The conciliatory tone is refreshing - as a community it doesn't have to be a "Vue vs. React" death match. Both are reasonable approaches that incorporate some pretty dope technology in slightly different ways.

</comment><comment><USER76> For what it's worth, I tried Vue first and ended up moving to React and it just seems to click better with me. More/better libraries too. Nothing on the Vue side of things is as good as Material UI.

<comment><USER77> There's also [http://vuematerial.io](http://vuematerial.io)

<comment><USER78> Vuetify is better IMO: [http://vuetifyjs.com](http://vuetifyjs.com)

</comment></comment></comment><comment><USER79> Vue is good for simple things. But it do not shines for complex apps and sometime makes it even harder than it should be. React can appears complicated when beginning, but it pays off on complex apps.

<comment><USER80> This is the impression I get, but I've not got any Vue experience to back it up so it's literally just based on first impressions.

I completely agree that React can feel like overkill for simple stuff, but really shines as the apps get more complex - complexity feels a lot more manageable.

For example, I built this in-browser Illustrator-inspired site/app using React and couldn't have imagined doing it without (in terms of making managing state and reasoning about things easy as the app grows more complex): [http://f37foundry.com](http://f37foundry.com) (the type tester on the desktop homepage, apologies for limited browser support!). Curious if you could do that sort of complex app with Vue.

<comment><USER81> > please visit this site using some recent version of [browser that sends all > your data to Google]

 _slowclap_

If using a JS framework means you don't have time to test your website in more than one browser, I'll happily continue writing plain JS (or better yet, no JS).

<comment><USER80> It's just the type tester element which is not accessible with browsers other than Safari or Chrome, because there's quite a lot of CSS trickery/hacks to make it work which didn't work in Firefox.

As mentioned in my other comment, due to the target audience it was decided that it wasn't worth the investment to get it working on other browsers right now, but the rest of the site should still work.

Not React's fault, just a lack of time/budget and a lack of native browser support for advanced typography.

</comment></comment></comment></comment><comment><USER82> Not knowing much about either one, I find 'scaling down' very appealing. I recently did some work with Angular 2, and found it very distasteful because of the big learning curve.

</comment><comment><USER83> Angular - has appeal for "corporate apps," well, because of Angular 1.*

React - has influence wherever Facebook has influence

Vue - took off in China as FB did not bother to proselytize developers there

</comment><comment><USER84> Dunno if it's just me, but I read these Vue articles and all I see is a bunch of hypocrites with an identity crisis, criticizing React for fragmentation, Angular for having 'one Right Way'. So they're better than React for offering one Right Way, then they're better than Angular for offering fragmentation? I mean, jeez, pick one stance and stick with it.

</comment><comment><USER36> I checked React, didn't like JSX, then I find out about vue, and after an hour or two into its guide, I am completely hooked. Especially love the fact that you don't need a compiler, or a node installation. Although single file component looks very nice, I don't want to "bring in a whole jungle just to have a banana".

</comment><comment><USER85> I prefer React. I do like a lot of the ideas in Vue.js, but when it comes down to it I prefer the lower abstraction level of React.

Where React wins for me:

\- Higher order components \- Stateless functional components \- React 16, especially the scheduler

Also I really like building the virtual DOM directly (JSX) but that doesn't seem to be very popular reading the other comments.

</comment><comment><USER83> It surprises me how this "vue vs react" gets to the first line for the 10th time in one or another form

<comment><USER86> Let me guess-- you're going to argue that "shills" are behind the quick rise?

<comment><USER83> Tell why should I?

</comment></comment></comment><comment><USER87> If anyone is interested in more Vue talk and some back and forth, check out the VueJS subreddit here: [https://www.reddit.com/r/vuejs](https://www.reddit.com/r/vuejs). It's probably the most active VueJS community online.

</comment><comment><USER88> This part of the documentation is pretty unchanged for the last 6 months I think, how come it gained so much attention today? We've been using Vue instead of Angular 2 and we are pretty happy with our everyday work. So +1 for the VueJS team.

</comment><comment><USER89> So Vue is based on the same Virtual DOM as Elm, or its own implementation? Do non-react tools in this arena still have react-like lifecycle hooks, or different ways of handling "on mount" behavior, for example?

<comment><USER90> I'm not very familiar with React, but Vue does have lifecycle hooks that work well: [https://vuejs.org/v2/guide/instance.html#Instance- Lifecycle-...](https://vuejs.org/v2/guide/instance.html#Instance-Lifecycle- Hooks)

</comment></comment><comment><USER91> I'm curious Vue.js has always had this comparison guide. Why re-post it now?

</comment><comment><USER92> I use material design. Angular and React have the best MD libs as of a month ago.

I also make mobile apps. Angular and React have the best native apps as of a month ago.

I use old devices. React and Vue are the most responsive.

Large companies use React on desktop and mobile.

React it is.

</comment><comment><USER34> i sense there may be a flood of react devs switching to vuejs. once their react projects are finished.

honestly react devs are missing out on how great the vue experience is. it didnt take me too long to see how much better vue is.

<comment><USER93> I would say that experience-defining tools are webpack-dev-server with hot reload, ability to use modern ES features and type definitions via TypeScript or Babel+Flow.

These are available for both Vue and React. Is there something on top of that available for Vue?

<comment><USER34> [https://nuxtjs.org/](https://nuxtjs.org/). here you get all of that out of the box

</comment></comment></comment><comment><USER94> A lot of people don't know about RactiveJS [https://ractive.js.org/](https://ractive.js.org/). Which I think is better and easier to use then most.

</comment><comment><USER95> Vue feels like a framework written by AngularJs developers. It's not "better React", it's more like better angularjs.

Html templates are a major turn off for me there, and using JSX is not optimal.

</comment><comment><USER96> As someone who has been maintaining a growing React/Redux app for a while now, this one has kept me up at night.

The main arguments in favor of Vue.js revolve around the idea that it is easier for new developers to understand; that people can pick it up and immediately be productive, with React/Redux being much harder to understand. As someone who wants to onboard new developers onto my project, it makes me wonder if I need to look into a switch, if not for my current project then for the next one.

A lot of the commonly touted differences are either a wash, or are only benefits for very small applications with perhaps a single developer. These would be Templates vs. JSX (This is a wash, they're the same thing, but this maybe even favors JSX for large applications), running Vue.js without a build system (you will want a build system regardless for any production application), "Two-way data binding" (Fools gold, will cause horrors if you ever use watches, you will end up hoisting almost all of your data to Vuex anyway in a production application) and "Single-file components" (Really skeptical that this will make a difference in development vs. any other organizational strategy). I can expand on any of these, but they've already been discussed to death.

\+ Where I think Vue.js is _actually_ superior to React:

Vue.js is quite opinionated and clear on where to put both data and computed properties. That's basically it, but it's a huge difference.

React itself is _very_ hand-wavy about where to put data and how to interact with it; it basically leaves the problem for someone else to solve. Even Redux, which is designed specifically to store application data, has a weird interface to connect your data to the React application and has _no_ opinion on where to put computed properties. React-router suffers from this same problem as well; you basically end up looking for blog posts on Medium to figure out how to construct an actual SPA out of these components.

This is a gigantic failing of the React ecosystem, and I think this represents almost 100% of the perception (or perhaps even reality) that developers understand Vue.js better than React.

\+ Where I think React/Redux is still better

The React ecosystem takes a lot of inspiration from functional programming; it prefers "immutability" and pure functions whenever possible, and I think this becomes increasingly valuable as your application grows; not just for enormous applications, but even for medium-sized applications.

Even if you're exercising maximum discipline with Vue by hoisting your state to Vuex, you've still got many opportunities to create difficult bugs based on the mutable state. Are you sure you're not referencing mutated state in one your actions? Does one of your components hold onto mutable state in order to do a custom transition or animation? If you're using watchers, you're really risking some dangerous bugs here. Now, I know _you_ probably won't do something silly like this, but as your development team grows and you can't code review everything going in anymore; can you vouch for everyone on your team not to make a subtle mistake with a mutable reference?

React/Redux also enables a few very useful patterns that Vue/Vuex doesn't offer at all. For example, the famous optimistic application is nearly a first-class use case for Redux, but would be quite difficult to implement in Vue. This doesn't matter for small applications; it _does_ matter for large applications. Will it matter for your medium application? The same thing about Isomorphic rendering; Redux was built with this squarely in mind. It won't matter for your small app; are you planning for your app to be small forever?

Finally, because it is all Javascript, I think React/Redux has a much better ecosystem of tooling. That includes both linters and transpilers; for example, writing Vue in typescript isn't especially natural, but it works _great_ with React/Redux. When considering my own purposes, effectiveness with Typescript is one of React/Redux's greatest advantages.

In summary, I would still maintain that React/Redux is better for medium to large applications than Vue, due to its commitment to pure JS and the inspiration it takes from functional programming. However, I definitely see the appeal of Vue.js, and I wish that the React ecosystem would take a note on how to provide clear opinions for developers.

</comment><comment><USER97> MithrilJS

<comment><USER98> Oh if only mentioning mithrils name would be enough to explain it's benefit I think a lot more people would be using it, but we need to do a bit better than that. Mithril is one of the few libraries that really embraces JavaScript and the beauty of a clean abstraction and lean API. There's no heavy learning curve, just learn a couple of method signatures, and you're ready to go. Once you need to do something advanced or use a third party library mithril won't be in your way! I still haven't seen anyone happily go back to react or vue for that matter after experiencing mithril.

[https://mithril.js.org](https://mithril.js.org)

<comment><USER99> I left mithril for domvm. It has a smaller focus and less magic.

[https://github.com/leeoniya/domvm](https://github.com/leeoniya/domvm)

</comment></comment></comment><comment><USER100> Is there a compiler for Vue components to web components?

I'm worried about forward compability of all this React components I'm building

</comment><comment><USER101> it seems odd that vuex is part of core but there isn't a default way to do get/post requests. [http://jrmeyer.github.io/tutorial/2016/02/01/TensorFlow- Tuto...](http://jrmeyer.github.io/tutorial/2016/02/01/TensorFlow- Tutorial.html)

</comment><comment><USER102> These are the threads that are often to the most frustrating to picking anything...

</comment><comment><USER103> If the licensing is an issue with React, then what about Preact?

</comment><comment><USER104> Ugh. Vue.js is just Angular 1.

</comment><comment><USER105> I have to many points associated with this handle. I'd like a 100 or so shaved off

React is for CS-savvy programmers. Vue is for those who like to think of themselves as programmers.

</comment><comment><USER106> I would go with react just because it is more popular. Unless you are someone with free hand picking a technology that is more widespread (hence more in demand) is in this era the wise choice to make.

<comment><USER107> The demand for both React and Vue.js is growing tremendously. There isn't really a wrong choice to make here.

(I would also say the same goes for picking programming languages, as long as it's one of the top ~15, and you stay somewhat flexible.)

<comment><USER108> There is way more demand for Angular and react than there is for Vue</comment></comment></comment>


Intel EOLs Atom Chip Used for Microsoft HoloLens - <AUTHOR> http://www.anandtech.com/show/11705/intel-eols-atom-chip-used-for-microsoft-hololens?utm_source=twitter&utm_medium=social <comment><USER2> This isn't necessarily a death knell. If Microsoft wanted to continue with the product, they can do what is called a "lifetime buy" where they buy up enough chips to carry them until their next iteration with a different CPU.

This is especially common in industrial electronics where volume is lower and product life is longer. Some lifetime buys can cover production builds for over ten years or more.

<comment><USER3> Is it possible that Microsoft might have HL-2.0 which perhaps does not rely on this Chip?

<comment><USER4> It literally says that in the article. This is in no way a death knell.

>The next-generation Microsoft HoloLens will be different compared to the existing augmented reality platform, Microsoft revealed recently. While the device will run Windows 10 and will be equipped with an HPU, it will also feature an AI co-processor integrated into the latter that will use neural networks to enable object and voice recognition skills without the need for an Internet connection. The HPU 2.0 with the programmable AI co-processor will be a self-sufficient device that will run on battery power of the next HoloLens (hence, its power consumption will not be too high). The HPU 2.0 and the AI co-processor were designed entirely in-house and therefore are tailored for usage model of the HoloLens.

<comment><USER5> I also would not be surprised, given what I perceived to be Microsoft's roundabout passive aggressive PR complaints about the Atom family, if Microsoft might make a play for the HoloLens 2.0 to run on ARM instead of x86.

</comment></comment></comment></comment><comment> Const-me Technically, Intel continues to sell similar products. For example, i5-7Y54 consumes same 4W of power, the CPU is about 2 times faster, GPU is about 3-4 times faster.

The main downside is the price. These atoms were sold for $20-40, the newer ones for $280. Not sure whether that's a huge problem for MS Hololens, but everything cheaper than that gonna switch to ARM for sure.

<comment><USER6> For a moment I thought this kind of massive price increase on a core component would matter for HoloLens and then I remembered the dumb thing costs $3,000 USD anyways.

</comment></comment><comment><USER7> It'll be interesting to see what they come up with to decrease rendering latency. From what I can see, that's one of the bigger challenges recently with GPUs; instead of focusing on raw throughput (to improve image quality), latency is now more of an issue.

I personally would welcome a AR HMD that sacrifices whatever is necessary to get a low-latency system that very smoothly tracks the user's movements.

<comment><USER8> I wonder if it would be possible to move some processing into the display. It's not the same, but in particle physics pixel detectors, which are basically CCD sensors, people have been working to move the readout electronics into the pixels. There, the motivation is radiation hardness and cheaper production. Here, it could be decreased latency. What if you could put a super small shader in each pixel, and do a final processing step like 'timewarp' right there? Or a part of your graphics memory _is_ directly your display, no bus in between?

That being said, I tried a couple of VR solutions and I don't really have a problem with latency. What I find more irritating is that I cannot focus well on different planes. You do have the effect when you cross your eyes that you put images from different planes together - although badly, because even if you don't see the pixels, you do get some kind of moire pattern when shifting planes (I can't describe it better). And what you don't have at all is depth blur. I think both can only be solved by true light field displays (if that is even possible). I hope there will be a breakthrough with holographic projection at some time.

<comment><USER9> > What I find more irritating is that I cannot focus well on different planes.

You might be interested in this Oculus VR research then:

[https://www.oculus.com/blog/oculus-research-to-present- focal...](https://www.oculus.com/blog/oculus-research-to-present-focal- surface-display-discovery-at-siggraph/)

</comment></comment></comment><comment><USER10> This whole comment section is basically people that didn't read the article, and then people copypasting article contents as replies.

</comment><comment><USER11> It was a shitty chip anyway. No SIMD of any kind. Good riddance, I hope Microsoft picks something more respectable next time.

<comment><USER12> The Cherry Trail Z8x00 chips are listed as supporting SSE too, are you saying the Z8100P is a custom design with the SIMD units removed and MMX disabled from the x86 FPU? Interesting idea, but would call for a reference I think.

<comment><USER11> I mean real SIMD, the kind you need these days: AVX, AVX2, FMA. And to add insult to an injury, MS was running the chip in 32 bit mode, which further restricts the usable instruction set.

</comment></comment></comment><comment><USER13> Sounds like what happened to the BeBox back in the day. They put their bet on the Hobbit chip initially (multiple hobbits iirc, hence the emphasis on multi- process/multi-thread) and had to delay quite a while to revamp their architecture.

<comment><USER14> not sure where you're getting that from, x86 chips are swappable with little design considerations apart from socket, TDP and in very edge cases - IO.

As for hololens, the current version is approaching EOL anyway.

<comment><USER13> The Hobbit was _not_ an x86 chip, hence the delay its discontinuation introduced.

I was not suggesting that an architecture change was necessary for Hololens, but are there a large range of low-power/mobile x86 SoCs out there to choose from? I know ARM has sucked up most of the oxygen in this particular room, but surely someone other than Intel is working on a similar line?

<comment><USER14> > The Hobbit was _not_ an x86 chip, hence the delay its discontinuation > introduced.

Exactly my point.

> I was not suggesting that an architecture change was necessary for Hololens, > but are there a large range of low-power/mobile x86 SoCs out there to choose > from? I know ARM has sucked up most of the oxygen in this particular room, > but surely someone other than Intel is working on a similar line?

ARM and x86 have readily available implementation for Windows OneCore.

</comment></comment></comment></comment><comment><USER15> Products that are not Laptop, Desktop or Server x64 CPUs at Intel are cut with extreme prejudice when the bean counters look at them roughly 6 months to 1 year after initial announcement and realize "hey these are not i7 margins".

It's incredibly damaging to everything they do. You can't cut a chip platform that your customers literally solder into embedded products with an announcement 3 months before last order.

<comment><USER16> > Intel asks its customers to place their final orders on the Atom x5-Z8100P > SoC (belonging to the Cherry Trail family) by September 30 and says that the > final shipments will be made on October 30. Given the fact that Intel seems > to have only one customer using the microprocessor, the short amount of time > between the announcement of the product discontinuance and the actual EOL > was probably negotiated before. Moreover, since we are talking about a semi- > custom chip, Microsoft was probably the initiator of the EOL, which > indicates that the company is on track with its next-gen HoloLens.</comment></comment>


BananaBread: 3D first person shooter game compiled to JS+WebGL - <AUTHOR> https://developer.mozilla.org/en-US/demos/detail/bananabread <comment><USER2> I'm wondering: Was the technique of compiling from C++ to JS primarily for code reuse? I always perceived the ability to code in something else besides C++ as one of the main advantages of the whole "Games on the Web" thing.

<comment><USER3> Code reuse was a major reason, yeah. It was much, much easier to compile a full open source game engine (that was worked on for many years!), instead of writing a new one from scratch.

Another benefit is C++ compiled to JS tends to be faster than handwritten JS, because it avoid things like GC and property accesses and focuses on things JS engines can easily do fast, like typed array accesses.

</comment></comment><comment><USER4> It took a few tries on OSX/Chrome (no relevant errors from the console to report) but it seemed to be more reliable when running inside a "fresh" tab as opposed to one I had already reloaded several times.

Having played it, I must report back to say: this is stunning. It's wicked fast. Wow. Just wow.

<comment><USER3> The load problem on Chrome seems to be audio decoding related. Reloading usually fixes it. Still investigating and looking for a better workaround.

</comment></comment><comment><USER5> Very impressive!

Was playable in low-ress mode, though sometimes laggy, on my 2010 MacBook Air with Chrome.

</comment><comment><USER6> Tried playing but didn't load. The demo video though looks amazing. [http://www.youtube.com/watch?feature=player_embedded&v=m...](http://www.youtube.com/watch?feature=player_embedded&v=mIYmxPdtsl4)

<comment><USER7> Yeah not working on Chrome on Linux for me. Gets to "preparing" and then stops doing anything.

<comment><USER3> Strange, works for me on Firefox and Chrome. Can you look in the error console? Debug output goes there, could help narrow down the problem.

Edit: The "troubleshooting" section on the page might help.

Edit2: If that doesn't help, try clearing the cache and reloading, I've seen that fix things on Chrome, not sure why.

Edit3: And specifically for Chrome, make sure pointer lock is enabled, it's disabled by default.

Edit4: I think I can reproduce this, once every few runs it stalls like that, because Chrome fails to decode audio sometimes. Reloading fixes it for me.

Debug build is up at <http://dl.dropbox.com/u/80664946/index.html> which tells you what is causing startup to fail in the error console.

<comment><USER8> Stuck at the end on preparing in Chrome. No errors for me. Just the following: <http://pastebin.com/raw.php?i=wucwzSxM>

<comment><USER3> Thanks, that's very strange. It looks like the correct output during startup, and then it just stops.

It's not too surprising there are bugs here, this is one of the first examples of its kind on the web, and I'd expect issues in browsers and in the game itself. However it does work for me in multiple versions of Firefox and Chrome so I don't have a good guess as to what the problem could be in your case.

For a future version I'll try to put in more debug output, perhaps that will help.

<comment><USER8> It did work once I tried Firefox. Pretty cool. Although, having to change my settings every time I went in (keys, mouse invert, mouse sensitivity) got old fast.

Clicking into one of the text boxes (mouse sensitivity) and hitting backspace caused the browser to go back in my history. :(

<comment><USER3> About the settings, yeah, we should store them using IndexedDB for later runs. Haven't gotten around to that yet.

I've seen the "go back" bug myself a few times. Not sure yet what causes it, I think I saw it with the middle mouse button on Linux primarily.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> Should have evolved some element for the <http://www.ludumdare.com/> event.

Maybe next time ;)

</comment><comment><USER10> "Banana Bread" was also the name of a very early and very obscure erotic adventure game on the Apple II.

<comment><USER11> I'm curious. More details?

<comment><USER10> Sorry, it's been too long ago, and too long before Google. I only remember the mention of the name.

</comment></comment></comment><comment><USER12> Alas, unplayable with a non-QWERTY keyboard.

<comment><USER3> You can enter the game's menus (`) and change the keybindings.

(However, we haven't implemented saving the config file for next run yet, so it will just be for that run.)

</comment></comment><comment><USER13> looks awesome.. i'll try it when i get home.

</comment><comment><USER14> tried it in chrome windows 7, got error pointer lock/mouse is missing, any ideas?

<comment><USER3> See the troubleshooting section on the page - pointer lock is disabled in chrome by default, you need to enable it to run the demo (you can do so in chrome://flags).</comment></comment>


Understanding and Beating the Odds of Startup Failure - <AUTHOR> https://annotary.com/blog/47/understanding-and-beating-the-odds-of-startup-failure/

<comment><USER2> _Across three consecutive venture-backed attempts, the probability of a $10MM exit is now 34%._</comment>


Bradley Manning loses challenge to most serious charge - <AUTHOR> http://www.bbc.co.uk/news/world-us-canada-23364342

<comment><USER2> Does that article's title make anyone else's brain melt out their ears?</comment>


Show HN: nextfeed – a minimalistic rss reader - <AUTHOR> http://www.nextfeed.org/

<comment><USER2> I subscribed and added a feed. I don't see how it reads the feed [1]. On adding a 2nd feed, it adds the feed and throws an 'Invalid feed' prompt.

Also, it is not clear if 'Copy to Clipboard' worked. You should have a notification saying so.

[1] [http://i.imgur.com/wYMSxF0.png](http://i.imgur.com/wYMSxF0.png)

</comment><comment><USER3> OPML please, I can't copy/paste/click 30 times before I decide whether or not I'd like to use this.

The weird randomized string URL is a hard pill to swallow too.

</comment><comment><USER4> Screenshots? That's the only thing holding me back from signing up.

<comment><AUTHOR> What screenshots would you like to see? There's just a simple table for managing feeds and a link to bookmark (it's... minimalistic :) )</comment></comment>