Vue RFC: Expose logic-related component options via function-based APIs instead - <AUTHOR> https://github.com/vuejs/rfcs/blob/function-apis/active-rfcs/0000-function-api.md <comment><USER2> Vue team lead here.

There is a lot of FUD in this thread so we need to clarify a bit:

\- This API is __purely additive __to 2.x and doesn 't break anything.

\- 3.0 will have a standard build which adds this API on top of 2.x API, and an opt-in "lean build" which drops a number of 2.x APIs for a smaller and faster runtime.

\- This is an open RFC, which means it's not set in stone. The whole point of having an RFC is so that users can voice their opinions. It's not like we are shipping this tomorrow.

For more details, we added a Q&A section at the top of the RFC to avoid further confusions: [https://github.com/vuejs/rfcs/blob/function-apis/active- rfcs...](https://github.com/vuejs/rfcs/blob/function-apis/active- rfcs/0000-function-api.md#high-level-qa)

<comment><USER3> I just wanted to point out a significant change made to the above document today.

Earlier today, there was a "Standard" build and a "Compatibility" build.

The "Standard" build excluded support for "data", "computed", "methods", "watch", "provide/inject", "mixins", "extends", and all lifecycle hooks.

In the updated document, the old "Compatibility" build became the "Standard" build, and the old "Standard" build became the "Lean" build.

<comment><USER4> Not sure why Evan is not being more transparent regarding this renaming.

It would be easy to just say "yes, I got a bit carried away with the naming and my big future plans, but the community reaction made me realise perhaps it was not a great idea"

Insead he's like: "what? it was the plan all along :)"

<comment><USER5> That's partly my fault. Evan focuses on more technical sides of things but there are people in the team that focus more on the community aspect and we didn't catch that potential naming issue and the whole message that the RFC gives away.

We're all still learning how to work with the RFC documents. We want them to be an important tool for the community but initially, the response from the community was very low. Paradoxically this whole situation made the wider community aware of those RFC documents so hopefully it will go in a good direction. But that initial low response made us believe "oh we have time to sort out things like the phrasing". Turned out it was wrong.

The advice to change the names came from the community and it was a good one. It got support in the core team internal channels and got implemented.

</comment></comment></comment></comment><comment><USER6> Evan, although the proposal as it stands indicates that these changes are slated as optional for Vue 3, the longer term focus is unclear. It looks like the set up to a bait and switch in Vue 4.

Here's the problem: when Vue was released, people jumped on board because its design was incredibly simple when compared to React, which at the time was heavily focused on the functional, performance based approach to UI development (and to this day, still is.)

If you've got a team that's super focused on performance and loves FP, React is always going to be the better choice. Facebook continues to invest heavily into performance improvements. I can appreciate that you guys care about performance too, but you're now stepping on the toes of the guys who really only care about that one thing.

Performance is _not_ the selling point of Vue, nor is functional programming or any of the other weird changes that have been introduced in this RFC. Nobody looked at Vue and was like, "wow, thank god Vue is 2ms faster than React when you render this benchmark component a thousand times."

The people who adopted Vue are the ones who had first rejected the complexity introduced by React. And now your team is saying "well, this approach is for more advanced users" \-- what an insult, honestly. Many of us had the foresight to recognize that the complexity introduced in React was not worth it for our teams, or we had already experienced the problems that such complexity introduces, and we chose Vue because it managed in general to be as effective as React without the fuss.

What Vue 3 seems to be is an answer to the question: how can we beat React at its own game? And congratulations if you've done it, but that's not what your users are here for. That's not what we pitched to our teams, our bosses, our stakeholders, etc.

My question to you is: honestly, how am I supposed to manage this? The long term answer seems to be that I have to change my code base to this new syntax (beyond or during Vue 3), at which point I'll be right back where I started when I decided to leave React for Vue. Do you think this is fair to ask of your users? Are you sure this is what we want?

<comment><USER2> First of all, this new API has relatively little to do with performance. The main performance gain in Vue 3 comes from a new template compilation strategy invisible to users.

Second, I think it is over-simplifying the issue by equaling the new API with Complexity. The RFC can be tough to grok because it is dense; but actually looking at some examples will probably show you that the new API really isn't about "complexity": [https://gist.github.com/yyx990803/762ec427882a61be3e4affe02f...](https://gist.github.com/yyx990803/762ec427882a61be3e4affe02f8af555)

Vue has a wide range of users. I honestly don't quite get how introducing an optional API can be an insult - because we clearly see some use cases we ran into can be more elegantly solved with the new API. Maybe you haven't run into them personally, but that doesn't mean your use case is "inferior" \- we are all dealing with different types of applications. However, I think it would be a real insult if you think Vue will never have a use case that is complex enough to warrant these advanced APIs.

Regarding your question: feel free to stay with the current API for as long as you wish. As long as the community feels there's a need for the old API to stay, it will stay. The only one that can make the decision to switch to the new API is yourself.

<comment><USER7> In my opinion the old API looks significantly better in every every example here. I really hope you guys figure out a way to better preserve that original simplicity. It was what drew me to Vue as a clear winner in the sea of JS frameworks.

<comment><USER8> What better way to preserve it than to just keep it, and not change it?

</comment></comment></comment></comment><comment> chupa-chups @Vue team if anyone should read this: I'd recommend to rename vue in the process (for example vueNG or whatever) in order to reduce the amount of false/outdated information when searching for a topic.

<comment><USER9> Yes, that's what the React team should have done when they implemented hooks.

<comment><USER10> Well, with React you can "opt in" when searching by simply adding "hooks" to the search term. Such wasn't possible with Angular back then

<comment><USER9> Since the majority of the community will probably be using hooks from now on it will be assumed that is the default React methodology which will break books, talks, blog posts, SO answers, etc.

<comment><USER11> You can mix-and-match. If you want to write an individual component as a class you can, and if you want to later convert it to using hooks there's nothing stopping you.

<comment><USER9> That's not the point.

The point is that most of the React literature available today will become obsolete.

<comment><USER11> How? It's still perfectly valid, usable, idiomatic React.

<comment><USER9> If you learned React with hooks the class notation won't make sense, and viceversa.

<comment><USER12> This is what I don't get about hooks. Remembering Markbages great talk on 'Minimal API Surface Area'? How is having multiple ways of doing the same thing minimal API surface area?

React is losing sight of what made it great when it came out. Do one thing, do it well, and do it the simplest way possible.

<comment><USER13> That sort of absolutist logic will never allow a framework to progress and become better. Sometimes good ideas come around (IMO like hooks) that are worth increasing the API surface area for.

I for one loathe using class components now and not being able to share logic compositionally via hooks when I work with them. I feel more productive and I feel like my components are smaller and more focused, and I don't repeat myself as much. It's been a net win for me, and I think it's well worth having two supported APIs that do roughly the same thing.. because despite this, React is still a small and focused library API-wise.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> Before you lament this move (and it's similarity to hooks/increase in complexity for questionable gain), check out John Lindquist's talk on Proxies:

[https://www.youtube.com/watch?v=95haj8RqR5o](https://www.youtube.com/watch?v=95haj8RqR5o)

This is what Vue 3 is using -- Proxy support enables really easy and natively supported observables (as well as enabling a bunch of other crazy stuff), and it's actually pretty impressive.

I think the reactivity system is Vue's biggest wart -- I've been surprised by it way more than I would expect. I strongly dislike the complexity react seems to encourage, I'm not a fan of hooks, but I am coming around to seeing this as a way that Vue gets closer to KnockoutJS -- _not_ as a way that it gets closer to react. Knockout had the simplest reactivity model you could ask for -- make an observable object and you're done -- it's observable, no surprises, very predictable interactions/behavior. I'm choosing to think of this as Vue going in this direction, although by more complicated means (Proxy vs a simple souped up observable wrapper).

That said, at this point I feel it's up to Vue to bungle my high opinion of the project -- they made it this far by being the simplest component frontend library with the best features, and the day they stop being that I'll be moving on. Already warming up to MithrilJS in my own projects, it's wonderfully minimal, performant, and light.

<comment><USER15> As a "full-stack" developer I just don't have the time to follow the JS circus as closely as a dedicated front-end dev would. I switched from Backbone to Mithril a few years back (major improvement to my productivity) and I see no reason to go through the effort of learning a new framework again.

But if I had to find a new framework for some reason, I'd probably go with Vue.

<comment><USER14> A very reasonable stance -- congratulations on getting lucky (unless it was the result of tons of research) and picking Mithril after jumping from Backbone (+Marionette I assume). There were _a lot_ of wrong, but good-looking choices to make there.

In case it wasn't clear, I still think Vue is the best minimal component library all things considered -- simple syntax, simple and mostly clear usage, support for typescript, not too much overbearing tooling (they're trying to "fix" this with vue-cli though), and a large community & ecosystem. I'm just scared they're going to blow it and start putting in , but I'm well aware I'm just a hanger-on to the project (I don't contribute to it).

Mithril[0], on the other hand is almost allergic to change, in the linux kernel way, which is great until you have a problem with how it works or think it should work differently. Mithril is also the most complete though -- it has routing, AJAX, all that stuff built in (context: normally when people say "vue/react" they mean "vue/react + vue/react-router + vuex/flux"). I also particularly like how Mithril uses the hyperscript syntax and just calls it a day -- full "single file components" without the transpilation hassle. Mithril also passes one of the key indicators for high quality software, a comparisons page[1].

Shameless plug -- I wrote a short guide[2] on how to get started with mithril & parcelJS (ignore the link URL, I started with rollup and then quit because it was too inconvenient to use, I write about it in Step 5):

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

[1]: [https://mithril.js.org/framework- comparison.html](https://mithril.js.org/framework-comparison.html)

[2]: [https://vadosware.io/post/mithril-systemjs-and-rollup- gettin...](https://vadosware.io/post/mithril-systemjs-and-rollup-getting- started-guide/)

</comment></comment></comment><comment><USER16> I guess that's my cue to leave front-end programming forever, and my current job (I'm not joking). I've been through too many cycles and it will never end. There's no way I'm staying for whatever crazy migration my company is going to go through again. And we have apps written in every single JS framework ever conceived. Time to learn COBOL.

<comment><USER17> I just left frontend, and I'm the maintainer for express-vue. Vue is great in its current iteration. But the whole JS ecosystem is just horrible right now. Looking at these changes, it's not for the better.

<comment><USER12> I'm almost done with it as well.

I can actually handle the churn and the random rewrites, a lot of them have been marked improvements, that doesn't bother me. What bothers me is when things change in ways that make them _more_ complex than they were before, which also happens constantly.

Not only that but I'm sick and tired of tool developers pandering to noobs. Nobody should ever be learning to use a library like React before understanding the programming language they're working with. For the React team to come out and say something as stupid as 'classes are too hard', in the context of the sheer wall of accidental complexity around the front end space, is a joke.

All the problems with PHP back in the day are going to come back with a vengeance when our new generation of coders that don't understand basic language constructs all graduate to tool making.

<comment><USER18> I'm trying to focus on the good parts of it, like: at least our jobs are safe.

Anyway do you have a minute to talk about our lord and saviour Rich Harris?

[https://svelte.dev/](https://svelte.dev/)

<comment><USER6> This was literally the exact same pitch Vue made when it came out. The developers get bored and add complexity. Don't get your hopes up.

<comment><USER18> I'm aware of that - hence the form of my previous comment.

"This time it's different" though.

The difference being: this here is radically less complex and unlikely to become much more.

All this complexity in frameworks was always added in a vicious cycle, namely:

1\. Developer looks at a component - they see complexity.

2\. They don't know how much of it is due to the business logic being complex and how much is introduced by the framework, which has to deal with the limitations of the platform, so they assume it's the latter.

3\. To deal with this they create yet another abstraction and an associated convention, which makes one problem better and a good few others worse.

4\. Other developers see the examples and figure that this new method indeed solves that one problem, so they adopt it.

5\. The result is ever increasing complexity.

Enter Svelte(and similar technologies): it's not a framework, but a _compiler_ \- it doesn't have to play by the same rules, so it (eventually) avoids framework-related complexity.

It's noticeable in the way how Svelte 3 ditched setState() altogether and replaced it with simple variable assignment.

<comment><USER19> Are there any svelte tutorials/examples that specifically target vuejs users?

<comment><USER18> I haven't seen any, but as a relatively early proponent of Vue(as in: I was there when v2 came out), I found Svelte even easier to get into than Vue.

Anyway Rich Harris' presentation is a good starting point:

[https://youtu.be/AdNJ3fydeao](https://youtu.be/AdNJ3fydeao)

<comment><USER20> God why did you show this to me. Now I really want to build something with Svelte but the project that I'm working on currently is built in Vue...

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER21> I've been following the Vue + TypeScript progress on and off for the past couple years (ever since I converted a React project to Vue and threw out TS in the process, since it was just so fundamentally incompatible with Vue's APIs). This is a pretty wild change compared to the now-abandoned class proposal, and I'm somewhat bummed by it, but I'll admit that's mostly due to my continued skepticism of hooks (as someone who hasn't yet adopted them in my React projects, either).

This will require one hell of a migration path to support and I imagine lots of people will be on that "Compatibility Build" for a long time. I'm very, very curious whether folks who have large-scale Vue apps have had a look at this proposal, and if they've had any input on it.

<comment><USER22> I really disliked the function API and felt the class API with decorators was much easier to read and work on.. I'm pretty sad they are doubling down on function API and, apparently, ditching the class API?

<comment><USER5> The class API will remain the current status of an add-on. The idea was that if we make the class API built in to the core, it will somehow be better than now and remove all the issues with it. More and more into the game it was turning out that's not that easy.

Even the decorator thing was problematic. Remember that the core Vue library is supposed to work both with and without build tools, but in case of TypeScript it's not possible. There is a decorator proposal for JavaScript but it works differently than the TypeScript one so there would be a clash.

In the meanwhile we found out a new solution that not only solves these but also some other problems (composability).

</comment></comment></comment><comment><USER23> There is a theory which states that if ever anyone discovers exactly what a JavaScript framework is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable.

<comment><USER24> adams is a visionary :P

</comment></comment><comment><USER25> FINALLY. What took so long? Seemed like we're long overdo for a big syntax change to take up engineering time with no real gain.

I should have never left C.

<comment><USER26> > with no real gain

Did you read the linked motivations?

<comment><USER6> Nobody cares what the motivations are if they can't update their code base without thousands of hours of work.

<comment><USER26> This new API is additive and not a breaking change, much like React's addition of hooks.

</comment></comment></comment></comment><comment><USER27> I always saw VueJS as a successor to AngularJS in that it followed a lot of the same concepts/syntax/etc. that made it really easy to jump into.

Now Vue is maturing and becoming more Angular/React like...so it's only a matter of time before another framework comes out that replicates VueJS2/AngularJS in being super easy to jump into and just write code and the cycle repeats.

<comment><USER28> Scope creep. It's really hard to say "no" to feature requests, especially if hundreds of people give it thumbs up, but it's a necessity if you want to keep your project from bloating over time.

<comment><USER27> Yeah I'm not saying it's a positive or negative change. Just an observation. Personally, I'd rename the next version to something else and let Vue be Vue, where Vue was founded as a replacement for the bloated SPA frameworks and super easy to just drop in and use.

</comment></comment></comment><comment><USER29> I might be totally and completely wrong, but changing everything does not help anyone except scratch the itch of the framework's designers.

I'm pretty sure this is all with the best intentions, but this would be a disaster similar to how Angular suddenly changed _everything_.

Not against change, but the API is fine. Just iterate and evolve it.

disclaimer: Big fan of Vue, early user and conference attender..

<comment><USER30> > this would be a disaster similar to how Angular suddenly changed everything.

To be fair to Angular, if they'd stuck with what they had, it'd have faded into obscurity far more than the current version has. Angular.js was great for its time, but lost most of its advantages as the web caught up, and what used to be its advantages started to become kludges.

<comment><USER31> Im still om angularjs. Cant bother to learn new frameworks every other month. Also using Angularjs in recent projects i never ever thought I was hobbled. Angularjs,jquery,vue - doesnt matter which tool one use. If you know any of these at advanced level you can create anything

<comment><USER32> The initial release was 8 years ago. Surely, you've had at least an ounce of curiosity about how the front-end ecosystem has changed since then? Even if you didn't adopt it, just to maybe poke around and look at what React, Vue, et. al. are up to?

It's not be dismissive of what you currently do. But perhaps you might see new efficiencies that allow you to do more with less, with these newer solutions.

</comment></comment></comment></comment><comment><USER33> I haven't done front end work for about one year. Looks like I'll be re- learning everything at some point, because this looks like a fairly major change. I'd strongly prefer backwards compatibility over a breaking change.

<comment><USER30> I feel like I'm shilling a bit for React over here, but they _are_ nearing two years without major breaking changes, and has been the de facto framework to go to for quite a while now.

<comment><USER34> It seems inevitable that hooks will be the only API 3 years from now though, and its already the case that all the new literature and examples are only going to teach hooks. Vue might maintain compatibility just as long but they've totally hosed their messaging on this judging from all the comments in this thread.

<comment><USER30> True, though as I said elsewhere: relegating the "old" syntax to a "compatibility build" is giving a strong signal that they will be deprecated soon.

But yeah, for now it appears they'll maintain compatibility well enough.

</comment></comment></comment></comment><comment><USER35> This isn't what I signed up for. I wanted the class api. This is spaghetti garbage. One god function that returns 47 variable wrappers because we can't make the number 4 reactive. And we'll put .value after everything.

</comment><comment><USER9> I used to be a huge Vue proponent for about 3 years and stopped using it at the end of 2018.

I moved to Inferno + MobX because the cognitive overhead is practically nil. You can architecture your application and specially your state in any way you wish since your reactive data is made of objects, classes, or whatever you want to use.

MobX also makes your React/Inferno components much more enjoyable. No need to use setState() anymore since your component state is reactive much like Vue or Svelte do.

After using that for a while and coming back to an old Vue/Vuex project I realized how many conventions and ad-hoc abstractions it has which was quite oppressive.

A couple of weeks ago I discovered mobx-jsx[1] which is pretty interesting. It's a very thin rendering library that compiles JSX to imperative DOM instructions and relies on MobX for tracking state changes which makes the virtual dom irrelevant. It adds loops and conditionals which IMO are the biggest annoyances of using JSX. This is probably what I'll be moving on in future projects.

(Actually what converts JSX to DOM instructions is a babel plugin from the same author)

[1] [https://github.com/ryansolid/mobx-jsx](https://github.com/ryansolid/mobx- jsx)

</comment><comment><USER36> Mixed feelings.

I decided to pick up front-end JavaScript a year ago and chose Vue. Although I'm a fan of that specific framework, one thing that I found annoying about the ecosystem (and the great JavaScript family in general) is the "unsteadiness". When I go on StackOverflow and look at questions related to, say, Flask and I see answers dated 2012, I have a sense that although Python has mostly migrated to version 3 now, the answers that I get are likely still relevant today. It's not because Flask has always made the right design choices. But the maintainers stick to their decisions, because people have already _invested time_ to learn to do stuff that way. It's not the best approach, it's not the worst either. You just learn it like this and when you have a problem, you ask on StackOverflow and someone will tell you what hoops to jump through. You'll scratch your head for a minute, but then be on your way to get shit done.

When I look for an answers related to Vue, everything seems to have an expiry date attached to it. Anything dated 2017 raises flags in my mind. Things seem in a constant state of flux. It's like trying to learn to walk on quicksand.

I saw the list of improvements/simplifications/deprecation. Not bad. If Vue was a fresh new framework these changes might have had more value, but it's not. A lot of time and efforts have already been invested to learn to do things the Vue 1 way and the Vue 2 way (not to count the accessory libraries and tooling). So I don't know if after tallying up all the pros and cons (which go beyond the technical concerns listed in the specs) whether this change might actually be more costly than helpful.

<comment><USER37> this is a javascript problem, not vue problem.

Because of libraries are working around javascript's limitation, it is inevitable that they will be as fast and ever-changing as js and js ecosystem is

</comment></comment><comment><USER38> It seems like a distant dream where Evan You promised 99% syntax backwards compatibility: [https://medium.com/the-vue-point/plans-for-the-next- iteratio...](https://medium.com/the-vue-point/plans-for-the-next-iteration-of- vue-js-777ffea6fabf).

About a year ago, my team rebuilt a large solar power plant prediction modeling Angular 1 application with Vue.js 2.0. It was the only big bang rewrite I've heard of that was a massive success. I work in Vue.js everyday and swear by it. Mr. Evan You, don't do this to us.

<comment><USER39> The new Function-based API is not replacing the current syntax. You will still be able to use your components in v3.

</comment></comment><comment><USER40> Well that's enough to reinforce my switch to [https://svelte.dev](https://svelte.dev)

I want a JS framework simple enough that even hobbyist devs can understand in an afternoon.

React syntax is an overly complicated mess; like reactivity forcing itself onto HTML.

Current Vue syntax is neat, simple and clear; like HTML with added reactivity.

<comment><USER41> Is Svelte 3 production ready?

I've been meaning to start a project with Svelte 3, but I'm not sure what tools to use. Is Sapper ready for v3 or is it still mostly on v2?

I've also somewhat been hoping that Svelte 3 will get TypeScript support so I can have a typed interface between my Svelte frontend and my Rust backend...

<comment><USER42> On what I've read, Sapper is still v2. Understandable I guess since Svelte has a small community.

<comment><USER43> You can use Sapper with v3 already and could for a while now. It's RC for now though.

</comment></comment></comment></comment><comment><USER44> Man, this is quite a bummer. It's basically a new framework to learn.

Edit: Might as well give it a completely new name.

</comment><comment><USER45> Why don't they just call it a new framework if its undergoing such a major overhaul. This only makes me feel better about picking react at my current company as now I view this framework as dangerous for building anything long lasting.

<comment><USER46> The React ecosystem introduces huge breaking changes and paradigm shifts literally all the time... _coughreactroutercough_

<comment><USER45> Reactrouter is a 3rd party npm package... the core react framework has been very stable and backwards compatible.

</comment></comment></comment><comment><USER47> I personally feel like I need some time to play with this in the context of my own projects before truly passing judgement. My initial reaction "seriously, wtf?" Personally, for me, if Vue can remain the simple, compact, non- dependency hell that is React, I'll take whatever they do.

My big question is how does this approach scale, and does it need a more fleshed out set of helpers, a la the mappers they have in the current API. Won't really know until I work with it. Would also love to see how this approach works into, for example, Vuex.

<comment><USER47> Also, this seems like the kind of change that would greatly benefit from some automatic code rewriting tools a la go.

</comment></comment><comment><USER48> Hopefully history will repeat itself and some clever dev will fork Vue 2.0 and create a new framework which has all the good parts of Vue 2 and nothing from this react inspired Vue 3 and all would be good again

(just like Evan did when Angular went rogue)

<comment><USER19> I think it's inevitable that if EvanYou does betray us, we really could just have a community fork of 2 and 3. You can see the support exists in this thread, and let's be honest here, VueJS seems pretty good and complete as is anyways.

</comment></comment><comment><USER49> Why not release a completely different framework if things are changing so much?

Here's a rule for framework creators... if your framework is changing more than jQuery has in its entire 13 years of existence, save everybody the pain/frustration and just start a new framework.

</comment><comment><USER50> Quick reminder that you can still write complex and useful form-driven web applications with no JavaScript at all.

<comment><USER51> Sure, but are there any people or companies who would willingly pay for this kind of web applications?

<comment><USER52> Sure, why not? highly depends on the product of course.

</comment></comment></comment><comment><USER53> Breaking changes such as this makes me rethink what could be the best approach with regards to front end development.

I can recall the time when I moved past Angular when they introduced so many breaking change on their next version. I started using React but was not comfortable enough to keep pace with its progression. Then I found Vue which was a breath of fresh air as this framework has allowed me to deliver end products faster yet being simple enough to allow for easy scalability & enhancements.

With these upcoming enhancements, I hope that it wouldn't introduce major changes that would require for me to rewrite large portions of my applications.

I have a lot of trust and confidence with Evan and the Vue Community and I guess all these changes are in line with best practices and better productivity rather than following a path because another framework is doing things like that.

<comment><USER54> I have a 100K+ LOC project in React started in 2015 that's going strong, and I imagine Facebook has much, much bigger projects than that using React. I can't recall a single time during all these years that something would have broken in a non-backwards compatible way. We're on the latest version of React, writing class-based components (with zero intent to move to hooks) and feeling very good about it.

<comment><USER55> I think Abramov said they habe over 38000 components at facebook, which is enough reason for Thema to keep backwards compatibility.

<comment><USER56> A lot more than that - roughly 100K now. Shawn Wang collected comments from the React team over time showing the growth of React's usage inside Facebook:

[https://www.reddit.com/r/reactjs/comments/btx9nq/reacts_grow...](https://www.reddit.com/r/reactjs/comments/btx9nq/reacts_growth_rate_in_facebook_some_datapoints/)

</comment></comment></comment></comment><comment><USER57> These API improvements (aka potential situation to refactor code within the next 3 - 4 years max) is why I think compile-time frameworks are going to win eventually.

People want to build UI. They don't want to migrate from function components to class components. They don't want to migrate from mixins to HOC. They don't want to migrate from Hooks, to whatever comes next. _They just want to build UI_ by writing code once such that it stays performant and maintainable for as long as possible.

Now is a good time to switch to Svelte / Elm / Whatever. Something that helps me declare my UI layout and behavior with a minimal API, but has a deeper understanding of my intentions. Such that, whatever that is better is eventually a compiler advancement - not an userland API change.

</comment><comment><USER54> Not a Vue programmer, but looking at the code, why is the example code using {{ count }} instead of standard JS interpolation like ${count}, and using an App.template block instead of just returning the template with the count and other params. E.g. why not just make it plain JS, and minimize framework surface? I could rewrite that example removing almost all of the "Vueisms", and it wouldn't be a single line longer.

<comment><USER19> Single File Components are converted to functions at build time (not run time) and that's the syntax for "string interpolation, but the variable is not trusted html". This protects against html injection.

</comment></comment><comment><USER58> It's important to note that this is an RFC for 3.x, and they seem to want to provide it for a 2.x revision, and provide a compatibility build, so it's not like angular 2+ where there's no real migration path.

If you have comments, this is where to tell the vue team: [https://github.com/vuejs/rfcs/pull/42](https://github.com/vuejs/rfcs/pull/42)

</comment><comment><USER59> Welp, it's dead to me then. There's a lot of thought seems like it went into the redesign and he(they?) have my respect but I'll be damned if I spend more time learning another js framework, I've already gone through react, angular 1 -> ∞ and vue. This is tiring.

</comment><comment><USER30> It's amazing to me that after so many years of being the leading framework due to being the first to introduce a new paradigm (the virtual DOM), React is still "the framework to follow", i.e. again being the first to come up with an innovation (hooks) that spreads like wildfire. And even more amazing that they managed to do so in a backwards-compatible way.

(And also: with not that much pressure to adopt it. Having a "Standard" and a "Compatibility" build does result in that pressure.)

</comment><comment><USER7> I switched from React to Vue because I didn't like the direction they were going with hooks. Now it looks like Vue is heavily borrowing from the same approach. Slightly upset about that but I guess I'll have to learn the new style. Maybe it will be better in the long run.

<comment><USER9> You could look into other options like Svelte.

<comment><USER60> Svelte is really nice because it makes the mundane easy (some say magic) and the tough stuff like reactivity and animation manageable.

</comment></comment></comment><comment><USER11> The more they change Vue the more I wonder why I'm not just using React.

</comment><comment><USER61> One of the best features of Vue 2 is how declarative components are.

The syntax proposed here is much more imperative, making it more difficult to read and understand components.

</comment><comment><USER62> The whole html template is one long string literal. I prefer JSX, where the XML is treated as code rather than a long string that needs to be parsed.

<comment><USER63> I prefer this because it doesn't require a build step.

<comment><USER64> True, but realistically you need some kind of build pipeline for production quality JS anyway so adding it in is pretty painless.

</comment></comment></comment><comment><USER65> It's moves like this which make me feel good about doubling down on Aurelia - [https://aurelia.io](https://aurelia.io) and forgoing the latest trend frameworks and libraries that many seem to jump on and use because they're popular. I was disappointed when I saw Evan and Vue jumping on the "classes are bad, functions are good" bandwagon. There is a lot of misinformation out there about classes in Javascript. If you use them without inheritance (like Aurelia promotes) they're really useful and great. I also admire the fact that Aurelia itself has never had a major breaking change in syntax, I've got Aurelia apps that have been running since 2015 without issue.

I think this undoubtedly means that Vue's private prototype they've been working on will be thrown out and they'll be starting from scratch again, which means Vue 3 probably won't be out for at least another year or more. If Evan and the team proceed with these proposed changes, it'll be the end of Vue.

</comment><comment><USER66> I'm happy they provide a way of migrating incrementally at least. But I really don't see us migrating any time soon, like possibly years.

To give a timeframe, this is the first major rework of this web based UI in nearly a decade. I wish these JS libraries had longer support timelines.

</comment><comment><USER67> While I can appreciate its their project and they can do what ye want, at least have the fortitude to admit the 2.x API is depreciated. Please, no nonsense about compatibility builds, anyone who uses one of those might as well accept becoming this generations VB6 devs.

We don't all work as freelance webdevs or in some startup. I work in a bloated, slow, soulless financial services firm; depreciating now or depreciating in 3-4 years as part of Vue 4 time might as well mean you're depreciating next week; it'd be the height of irresponsibility for me to use Vue for a new project knowing I would need to refactor everything, I'm going to have enough code to rewrite as a result of this as it is.

</comment><comment><USER58> Evan You is responding to comments on twitter

[https://twitter.com/youyuxi/status/1137567675356291072](https://twitter.com/youyuxi/status/1137567675356291072)

</comment><comment><USER68> To be honest, I don't actually mind these changes. Grouping all exposed members together makes for a cleaner API and the functional style makes reuse a lot easier, so that should trim down code length.

But.....that's not a sufficiently compelling reason to change. Even with backwards compatibility, it still adds confusion to the mix, requires a huge effort in new/updating documentation, etc.

I can't really see how the benefits justify the effort.

</comment><comment><USER69> It's Angular all over again.

</comment><comment><USER70> I welcome the added flexibility of this new syntax. This eases encapsulation of related logic within the same block of code, instead of having it spread over different Vue directives.

Plus, at a glance, it seems very easy to pick up and very intuitive.

I also appreciate that you stay away from "javascript classes"

</comment><comment><USER71> This is painful. I am finalizing a 4 month migration to Typescript using the now abandoned Vue class based decorator approach (including Vuex Decorators) Even though the migration probably is a 50% split between frontend and backend, it looks like a lot of time has been wasted.

<comment><USER5> I'm sorry to hear that. The class API will still stay with us though, even the current plugin solution will work better thanks to Vue internals rewritten to TypeScript. It won't be as good as the function API, but during the works on a native class API we realized there are problems with classes API that even a native solution wouldn't solve.

<comment><USER71> Thanks, I guess it's a bit early for me to jump to conclusions. I'll just have to wait and see what you guys come up with :-)

</comment></comment></comment><comment><USER72> > Function-based APIs are exposed as named ES exports and imported on demand. > This makes them tree-shakable, and leaves more room for future API > additions. Code written with function-based APIs also compresses better than > object-or-class-based code, since (with standard minification) function and > variable names can be shortened while object/class methods and properties > cannot.

I don't yet have an opinion on the wider changes but this is great. Tree- shaking really helps bring down file sizes and I'm not in the camp of "it only loads once and caches" group that disregard file size these days. And not just because that's no longer true with async component loading depending on the route/page.

</comment><comment><USER73> I'm glad I've held off for this long... almost time to jump in!

<comment><USER74> You're making the assumption JavaScript frameworks are iterating towards perfection when in reality it's just generational churn. We're still talking about mostly trivial business form apps. Yet they need to be thrown away after 3-5 years because nobody can maintain them, and nobody wants to. Much better to lure young developers with "exciting" (immature) tech.

<comment><USER75> That.

</comment></comment></comment><comment><USER5> One of the biggest advantages of the function API is the flexibility it gives for the library authors, making them more powerful and much easier to maintain, so instead of fighting against the API they will be able to focus on new fancy features, better documentation or community support.

This gain will be visible for all Vue developers regardless of which API they use because we all want to have the best quality libraries in our ecosystem.

</comment><comment><USER76> I've written a blog post with my own feelings about it (hopes and fears included ;) ) - feel free to check it out: [https://lukaszkups.net/notes/do- we-have-to-be-afraid-because...](https://lukaszkups.net/notes/do-we-have-to- be-afraid-because-of-latest-vuejs-rfc/)

</comment><comment><USER77> If it's going to break compatibility anyway, go big. I would welcome something like what Svelte did for v3.

</comment><comment><USER78> Sorry about the breaking changes, but glad "this" will be going away.

Thinking about transitioning (from AngularJS) to Vue, but prefer FP to OOP, and I'm glad that these new value wrapper things can be passed or used as partially applied arguments, as well as the other functional composition support changes.

</comment><comment><USER79> I proposed new Scoped Mixins API (only basic draft ideas), could you looks at this and give feedback - [https://github.com/vuejs/rfcs/issues/60](https://github.com/vuejs/rfcs/issues/60)

</comment><comment><USER80> [I have no affiliation with the Vue team .. just a happy user]

IMHO, composition functions are an elegantly simple and well thought through _addition_ to Vue brought about by a good consultative process. I think this demonstrates that Vue is in good hands with intelligent and wise counsel steering the ship. This small change is nothing like the Angular v1 => V2 experience! No one is breaking backward compatibility!!

Vue is all about coding simplicity ... and although reading through this RFC is at times heavier reading (meaning Evan's team thought through this addition very thoroughly), the final outcome is not! It's uses syntax that is very similar to existing Vue components so if you needed to refactor existing larger components into smaller composition functions, the coding experience is fast and would feel very natural and familiar with minimal to learn. No one is forcing this additional on you ... its just there if you needed it.

So please before getting spun up on any further misinformation in this thread please read the RFC from Evan You or this very thorough explanation of the RFC which has some nice coding examples.

\- [https://dev.to/danielelkington/vue-s-darkest- day-3fgh](https://dev.to/danielelkington/vue-s-darkest-day-3fgh)

Is it just React Hooks? ... here's a Comparison

\- [https://github.com/vuejs/rfcs/blob/function-apis/active- rfcs...](https://github.com/vuejs/rfcs/blob/function-apis/active- rfcs/0000-function-api.md#comparison-with-react-hooks)

My personal journey

I've coded Angular/Ionic, ExtJS & Sencha Touch, Knockout/jQuery in the past. Learning Vue was nothing like learning and keeping up with these! I was highly productive in Vue in 3 days and the learning curve and documentation was much simpler and lighter so more time to stay focused on the code. I've refactored a legacy boostrap/jQuery web site into nice Vue components in a few hours (impossible with the others!).

I'm absolutely loving the super productive Quasar Framework built on Vue 2.x/3.x which now delivers 130 components, directives and boot plugins with builders for ALL platforms: Web or SPAs (Desktop & Mobile), PWAs, SSR, SSR + PWA, Cordova iOS/Android mobile, Desktop/Electron and dream documentation.

\- Check it out: [https://quasar.dev](https://quasar.dev)

</comment><comment><USER81> I hope Vue.js gets some kind of automatic migration tool. Otherwise, I'm not sure how migration would be possible, given the amount of code certain projects have (sometimes without proper testing).

</comment><comment><USER82> Eh, it was either this or wait till everyone switched to another implementation of 'vue with hooks' or react.

</comment><comment><USER83> Classes really seem to have gone out of fashion in JavaScript land these days.

<comment><USER75> JS land and Frontend in general changes fashion every 6 months (tops)

</comment></comment><comment><USER84> Oh well, Angular is a safer bet.

</comment><comment><USER85> We have a (currently) 50-60KLOC SPA that, in the past 8 years, has survived migrations from a homegrown backbone+jquery-based MVC framework into angularjs (starting from v0.9), then to componentised angularjs v1.5 with webpack and TypeScript, to a heavily deangularised (but still based on v1.7) app where we've removed all useless DI (it didn't even help testing) and made all angular services into pure ES6 (well, in TypeScript) classes imported as modules, with Jest and TS transpilation via Babel.

We also have our own Redux/Vuex-inspired uni-directional state management solution that uses immer under the hood.

The next step, largely motivated by the fact it's hard to find developers who want to work with older frameworks, is to convert the app into Vue from the inside-out using ng-vue as glue, and when all components are Vue, remove the outer angular shell.

So we have been tracking these proposals. The original class-based RFC looked perfect for us, since that was 95% matching how our current (class-based) components look like. Seeing it get abandoned was a cold shower, but okay, not the biggest problem. Our components are as dumb as possible anyway, and we have all business logic in services. It'll just be some additional manual text-wrangling work.

The new proposal looks okay. I guess, just as React hooks made classes unusable in React, they had to go from Vue as well (though honestly, I don't really see the fascination with hooks, but maybe that's because we don't do anything like the Hooks examples I've seen in our app). I do really like the idea of the reactivity system being completely separate from the rest of the framework.

I personally never liked the original JS-only API either, with the { props:, methods:, computed:, } etc. "separation" (commenters here call it "simple", but I think it's far from that), so in my Vue 2.x projects I used vue-class- component.

Overall, the motivations and reasoning in this RFC seem sound to me.

However, here I come to my three biggest problems I have with this API:

1) The fact that you have to return the render props from the setup() function. It's annoying repetition, and I foresee people forgetting to add a newly added prop here. It also makes the definition of the component feel procedural instead of declarative. You have to read/mentally run the setup function to know the shape of the component. Hopefully maybe you can notate the setup() function return type to match a TS interface without breaking editor support?

2) The fact that they couldn't come up with a better-looking way to declare a prop with a complex TS type other than `prop: (null as any) as PropType<SomeComplexType>`. I guess I could make a noop generic helper function for this, though.

3) props are optional per default. I feel this is the completely wrong default for a TS project (mentioned as a consideration in the RFC though)

</comment><comment><USER86> That everyone on HN seems to be unanimously shitting on it, I am now certain that Evan is going 100% _THE_ right way with this, and am super-stoked about trying it out!

</comment><comment><USER87> Churn in the JavaScript ecosystem you say? What what tally ho pip pip!

<comment><USER7> No one is forced to upgrade. An ecosystem with optional churn is better than an ecosystem that has no churn just because people aren't creating new things for it.

<comment><USER88> Yes I love the Windows 2000 UI, but I guess I'm not forced to update.

</comment></comment></comment><comment><USER6> Python 3 vibes. Terrible decision. Our team has decided after seeing this to use Vue 2.x until we can move away from Vue. Extremely disappointed. Simplicity was Vue's bread and butter. Literally the only reason to use it over React. Now what's the point? We get it, you're a smart guy who likes FP, quit punishing the rest of us.

<comment><USER89> I'm not a fan of this RFC but how can you make such as drastic decision at such an early stage?

<comment><USER19> Everyone's treating this "request for comment" as if it's an official declaration of the new API.

</comment></comment></comment><comment><USER90>
        // expose bindings on render context
        return {
          count,
          plusOne,
          increment
        }

No, this here is why you want classes. On a large project you are going to have multiple people touching contiguous code. This block is going to have several pages of code between it and half of the declarations and that kind of ping pong is no big deal for a limited percentage of the Dev population but is NOT trivial for everyone else.

There's a difference between having a problem and admitting you have a problem and _lots_ of devs trip up on code constructs like this on a regular basis. It's double data entry and that is bad. It also hamstrings editors, adding friction to discoverability. All things I shouldn't have to explain to a framework writer but constantly find myself having to soapbox.</comment>


Competitive Self-Play - <AUTHOR> https://blog.openai.com/competitive-self-play/? <comment><USER2> I imagine this is the way we get to "true AI", or AI indistinguishable from our own. We train it with a simple virtual environment, that we can gradually increase the complexity of, until it mimics our own. Then we can download the AI into a robot. Boom, it's that easy :P

One interesting outcome of this type of AI is that no one knows what the robot's thinking, since no person designed its brain. The brain evolved, just like ours did (but over such a shorter period of real time).

<comment><USER3> This is one reason I'm hopeful for a not-killer-robots future. I think there's a chance strong AI will have to evolve over a non-trivial amount of time (as opposed to an afternoon's super-singularity), and a strong evolutionary pressure will be "don't scare the humans."

<comment><USER4> "Don't scare the humans" is an insufficient criterion if you're trying to prevent an AI apocalypse. It just means that the AI that destroys us won't be _obviously_ dangerous.

<comment><USER5> Today I have already consumed more sugar than most of my distant ancestors would see in a year. The device i hold in my pocket reminds me that it is time to perform the action, and so i will perform the action. I sit down about 10 hours a day, and I have never once hunted for an animal I would eat, nor retried food from nature to consume, aside from a few raspberries on the hill in my parents' back yard when I was a child.

The contours of my life are dictated largely by a curious system called 'capitalism', a distributed computational mechanism whereby largernumbers of agents act with only one goal: to maximize their own utilities. I think capitalism is a mostly benevolent AI attempting to limit the oppressive conditions of our reailty's scarcity, and to allow billions of us to live on a planet that can only support so many hunter-gatherers per square meter. Many suspect it is not benevolent.

The singularity is already upon us; it's unevenly distributed. It started with the sedentary shift. Agricultural societies dropped the egalitarian nature of their ancestors, they had lower average health, and they had a tiny elite cast of nobles presiding over a much larger population of what were essentially slaves. As hunter-gatherer population increased, fighting was more frequent. An army of slaves beats a smaller contingent of well-fed free men. This terrible knowledge was the apple in the garden. What we call our written history is essentially the singularity playing itself out, as knowledge accumulates, depends, reflects itself, and expands.

Our lives are already controlled by this embodied, accumulated knowledge. Capitalism, rule by the head, our tools are knowledge condensed into matter, and we are controlled by them, living lives as far from our natural environments as cows in a farm or chickens in tiny cages, towering over the streets of hong kong.

I don't think it's destroying us, any more than we seek to destroy chickens or cows. Well, sometimes we do. I had a veggie burger for lunch today though.

<comment><USER6> I love this comment.

Sorry I'm not contributing anything substantive, but I wanted you to know someone noticed this, and it was brilliant.

<comment><USER5> Thank you! If you enjoyed the comment, you might like my book on amazon. It's free if you have kindle unlimited.

[https://www.amazon.com/Mechanics-Emotion-Structure- Possibili...](https://www.amazon.com/Mechanics-Emotion-Structure-Possibility- ebook/dp/B01MDPLI4S/ref=sr_1_1?ie=UTF8&qid=1507919723&sr=8-1&keywords=mechanics+of+emotion)

</comment></comment></comment></comment></comment></comment><comment> d--b Mmmh so far, it doesn't look much more compelling than good old genetic algorithms...

<comment><USER7> Welcome to the Fad Career! :D

Previously relegated to Online Software Engineers, now Data Scientists can feel what it is like to have tons of recent undergrads flooding their fields and coming up with all sorts of "new" ideas that are just the first version of something that is established in the field for decades!

Next up, Electrical and Firmware Engineers flooding the IoT Fad Career! Just give it some 5 or 6 years.

<comment><USER8> Make sure to also look out for

        epigenetic

        neuro-

        noo-

        quantum

        cyber-

       negentropic

etc. in the coming years

</comment></comment></comment><comment><USER9> I've seen much better videos of simulated walking structures, e.g. [1].

[1] [https://www.youtube.com/watch?v=pgaEE27nsQw](https://www.youtube.com/watch?v=pgaEE27nsQw)

<comment><USER10> Also, much better competing AIs (and wittier narration), from back in 1994 [1]

[1] [https://www.youtube.com/watch?v=JBgG_VSP7f8&t=2m10s](https://www.youtube.com/watch?v=JBgG_VSP7f8&t=2m10s)

</comment></comment><comment><USER11> This seems pretty obvious for practicality. The AI can play thousands, or millions of games in different VMs 24/7 and be exposed to a radically higher number of simulated circumstances versus the comparatively plodding rate of genuine interaction.

<comment><USER12> The main issue with self-play is that unless done very methodically it can lead to behavior that does not learn what we want it to learn, but games the simulation and basically cheats. Its not a perfect solution and is just another tool being used to improve models. It can produce really interesting results especially in complex games but its also not perfect.

<comment><USER13> I agree... I feel like advanced games will always need guidance to alter the game such that they AI don't reach some local maxima through an exploit.

This happens all the time when making games for humans and is evident by how many balancing patches are made to new, highly competitive games (such as any Blizzard title).

The next logical step would be for another, impartial AI to observe the games and changing the rules and parameters intelligently as they evolve to guide the player AI toward the actual goal.

So, I'll just dive sideways right into a religious/philosophical thought based on the simulation discussion I've been having all over the place:

 _A universe-sized simulation built for a purpose, which requires simulated intelligence to carry out that purpose, would almost certainly include a God intelligence to alter parameters and induce suffering /hardship to direct the simulated intelligence toward that purpose._

<comment><USER14> Earlier iterations are buggier and have poorer dev tools. So the God intelligence has more need to smite and command the AIs within the game.

After a while the bugs are ironed out, so God can settle back and gently tweak parameters at a distance.

<comment><USER15> > After a while the bugs are ironed out, so God can settle back and gently > tweak parameters at a distance.

That explains the hands off approach God has lately with the human society.

</comment></comment></comment></comment></comment><comment><USER16> I'm having a hard time understanding how the body can stay stable at all. For the emergent behavior to appear, you would need the AI to control the body pretty precisely, but if you just had a "random" AI the body would never stay up straight.

Seems hard to imagine any amount of generations that get the body up to "stand". I would have maybe expected it to crawl on all fours.

<comment><USER17> > Agents initially receive dense rewards for behaviours that aid exploration > like standing and moving forward, which are eventually annealed to zero in > favor of being rewarded for just winning and losing.

</comment></comment><comment><USER18> It seems like fighting games such as Street Fighter or Tekken are a perfect fit for Self-Play.

Anyone at OpenAI attempted to build such an agent? Are there any AI research platforms designed specifically for player vs player fighting games? As far as I know, elite human players are still massively dominant. Even though it would make for an exciting matchup. But giving the complexity of actual fighter competition, with combo attacks, power meters, time limits, etc. There is an absurdly high dimension of training variables required.

I'd actually like to try and take a step back and apply self-play to something lower dimensional. Perhaps a 2D Tron Light Cycle sim. And see if some truly unexpected strategies arise ;)

<comment><USER19> Given perfect information, execution, and instant reaction times, fighting games would be trivial for an AI to win at. There are already some bots that will do things like auto-block or parry any incoming attack in Tekken and they're pretty funny to watch (see TOOLASSISTED's videos like this one: [https://www.youtube.com/watch?v=nNG5iRMdeg0](https://www.youtube.com/watch?v=nNG5iRMdeg0) )

At high levels of play, where execution largely isn't an issue, it's all about reading your opponent, conditioning them to play how you want to play, and exploiting their tendencies to get in your damage. It would be pretty cool to see a bot learn to play with a human-level reaction time handicap and put them up against a pro in a long set, though!

<comment><USER18> Actually your comment just triggered a sense memory for me. Of a rudimentary "classic" AI for a prototype 2D cell-shaded bitmap sprite sheet fighter game I created more than a decade ago. I think it was in adobe flash and actionscript 3...

And yeah my bot "cheated" extensively ;)

</comment></comment></comment><comment><USER20> Imagine a robot police force, based on this technology. If a suspect were to attempt to tackle or evade the police, it would react accordingly. This robot police force would be networked, so all police nationwide would learn from every suspect encounter. You may have seen movies where the human "outsmarts" the robot, but when robots are hundreds of steps ahead of humans, how do we defend ourselves?

</comment><comment><USER21> Evolution created consciousness as we experience after billon years of brutal trial and errors. Creation of consciousness will endanger mankind but from evolution point of view, evolution will jump to a next level of evolving. That something evolution could not created directly by herself but her best child mankind created for her.

</comment><comment><USER22> Leading to a thought... are dreams how animals engage in competitive self- play?

<comment><USER23> I don't think that can be the only purpose of dreams because I would think that children need to learn a lot more than adults, but they sleep about the same amount.

</comment></comment><comment><USER24> just a reply to a common reply to this kind of things

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

</comment><comment><USER25> At 0:59 in the movie, I noticed another kind of emergent behavior: kicking the goalie where it hurts after it defends the goal. I would call it "retribution".

</comment><comment><USER26> Tangentially, I'm so in love with the site design. Shout out to the UI team.

<comment><USER27> Me too! Mousing over the article links[1] reminds me a lot of the modern Apple TV UI.

[1] [https://blog.openai.com](https://blog.openai.com)

</comment></comment><comment><USER28> I wonder if the AI was as annoyed with the music choice as I was.

<comment><AUTHOR> Aw, that was my one contribution to the video :)! What kind of music would you have preferred instead?

<comment><USER29> First, turn the volume down. Then music that is quieter, more ambient, and _unnoticed_ , or none at all.

Like this[0] or any electronic genre (without lyrics preferable).

I also did not like the music. Seems trivial and unnecessary to point out, but that's the point: if people can't help but "notice" the music and view it as a distraction, it was a bad choice.

More generally: the cloying, "chipper" stock music of many youtube videos is _always_ irritating to me, and never a good choice for any videos in my opinion.

[0] [https://youtu.be/85bkCmaOh4o?t=109](https://youtu.be/85bkCmaOh4o?t=109)

</comment></comment></comment><comment><USER30> Create an ICO for it and you'll earn millions /s

<comment><USER31> So we have a pool of agents, they can send binary blobs, they need to have X many tokens per day to survive (start it low, let it grow over time), they need some way to mine a blockchain, allow some way for them to reproduce via genetic ai & random mutations, add in some misc mechanism of disaster in order to reward saving for a rainy day, maybe add in a mechanism where agents can group up to kill other agents, see if they evolve a means of striking deals & splitting up loot for future attacks

Then eventually add a human console where people can invest in agents, see if the agent will give out returns, eventually allowing agents to put smart contracts on ethereum & interact with misc smart contracts..</comment></comment>


Ask HN: What's your favorite, cheap throwaway computer? - <AUTHOR> <comment><USER2> I got the blue HP stream 13 for about $200 and it's remarkably versatile. I was able to get Photoshop and Illustrator and Visual Studio Code running on it, which covers most of my needs for portable computing (only thing it doesn't cover is iOS mobile dev, but there's no cheap throwaway solution for that).

And its memory is all solid state, so I don't have to worry about screwing up hard drives when transporting it like has happened with every single past laptop computer.

[http://www.pcmag.com/article2/0,2817,2472573,00.asp](http://www.pcmag.com/article2/0,2817,2472573,00.asp)

<comment><USER3> Interesting. How is battery life? Have you used other development tools aside from the ones mentioned?

<comment><USER2> I mean, I don't use much else on a regular basis outside of work, but I don't see why it couldn't handle most things except maybe the full Visual Studio suite (and I've been tempted to install it to try it, but there's not too much more space left in the main memory, because small SSD).

Like Atom, Sublime, Notepad++ all that should be fine. Maybe it'd struggle with Eclipse. I wouldn't expect it to work as well as a $400 computer, though. This is a dirt cheap computer, on about the same level as basic Chromebooks, but you can install desktop applications on it (my main requirement at the time).

I mainly bought it for: writing python scripts, writing stories in coffeeshops, and some light graphic design work (thankfully it handles medium graphic design work, because I do a lot more of that nowadays), while on the go, with an SSD, and as cheap as possible. It's handled all of that much better than expected for the price.

</comment></comment></comment><comment><USER4> Chuwi Hi10, it's a touchscreen Windows 10 tablet with 2 usb ports, HDMI out, 4GB ram, 64GB storage, 64-bit Windows. Currently on sale for $170. Unfortunately I dropped mine and broke the touchscreen but I still use it on my TV.

[http://www.banggood.com/Chuwi-Hi10-64GB-Cherry- Trail-Z8300-Q...](http://www.banggood.com/Chuwi-Hi10-64GB-Cherry- Trail-Z8300-Quad-Core-1_84-GHz-10_1-Inch-Window10-Tablet-p-1004298.html)

</comment><comment><USER5> I have an Acer Aspire 1810TZ (11.6" 768p, Pentium dual core, 4GB RAM, SSD) which still runs Debian and OpenBSD really well.

People love to hate on Acer laptops but this one proved to be extremely reliable.

I bought it 7 years ago for about £400. I have the impression netbooks / chromebooks these days don't offer much of an improvement over this little machine for the price.

</comment><comment><USER6> Actual x86 computer:

dirt cheap Thinkpad/decommissioned business laptops from ebay

Microcontroller:

arduino clones

4 dollar cypress PSoC 4 kits

</comment><comment><USER7> Acer C720 Chromebook I picked up for $130 off groupon a couple years back.

</comment><comment><USER8> Old MacBooks, just because I like osx.

</comment><comment><USER9> This $49 one is interesting: [https://getchip.com/pages/pocketchip](https://getchip.com/pages/pocketchip)

</comment><comment><USER10> On the higher end I like my Chromebook, for projects I like the PI.

</comment><comment><USER11> Chromebook 11 ($150)

</comment><comment><USER12> PI

</comment><comment><USER13> Arduino</comment>


'Oumoamoua Is Not Alien - <AUTHOR> https://www.youtube.com/watch?v=wICOlaQOpM0 <comment><USER2> Title is misspelled. Right now, the title of the video is "'Oumuamua Is Not Aliens". That is also a misspelling, because it's name is "ʻOumuamua", starting with a ʻokina, the Hawaiian letter, not an apostrophe.</comment>


Ask HN: When should an open-source library stop supporting legacy browsers? - <AUTHOR> You can also rephrase the question as:<p>- Are you assuming full ES5 support when building libraries?<p>- Are you assuming partial ES6 support when building libraries?<p>- Are you pushing shim responsibility to the user?<p>- Are you ignoring browsers that are 1% or lower in market share?<p>- When should a library stop hand-holding older systems?<p>What's your opinion? When should a library shed off legacy browser code?<p>(legacy = IE10 and below, browsers older than the previous version) <comment><USER2> I think you can throw out support for these legacy technologies IF:

1\. Doing so results in competitive advantage--such as being able to move significantly faster, being able to maintain significantly cleaner codebase, etc.

2\. Your library does something unique that no one else does - If there are tons of other libraries that do the same thing, you will be thrown into a feature war. I guess that's fine and there's nothing wrong with that but I personally wouldn't want to be in that position.

</comment><comment><USER3> When it meets the goals of the project. Tossing out legacy support probably means breaking behavior for people with the fewest resources. Larry Ellison probably has someone whose job includes making sure his laptop is up to date. A family living in a slum with a hand me down laptop doesn't.

Good luck.</comment>


Data Mining competition for predicting drug reactions - <AUTHOR> http://omopcup.orwik.com

<comment><USER2> Not exactly timely; the competition started in September 2009. There are well- known algorithms for mining association rules; see, e.g., [http://www.eecs.umich.edu/~klefevre/eecs584/Papers/agrawal_1...](http://www.eecs.umich.edu/~klefevre/eecs584/Papers/agrawal_1994.pdf) .

<comment><USER3> Yea, I always find out about these things a bit late. Too bad. Probably getting something together by March is nearly impossible.

</comment></comment><comment><USER4> Only for US Americans: _"The Competition is open to data analysis experts ("Participants") from the fifty (50) United States ("U.S.") and District of Columbia ("D.C.")"_ [http://competition- files.s3.amazonaws.com/OMOP_Cup_Competiti...](http://competition- files.s3.amazonaws.com/OMOP_Cup_Competition_Official_Rules_v3.pdf)

</comment><comment><USER5> NetFlix offers what .. a million dollars for their data mining contest, and their revenue is in the millions.

Something doesn't seem right.</comment>