Vue 3.0 Updates [slides] | Hacker News Reader

Vue 3.0 Updates [slides]

docs.google.com

292 pointsmxstbr123 comments

I think the best part about Vuejs is that how simple it is and everything just works!

A vue component is still as simple as {template: 'hi'}. You don't need webpack or any transliteration for it to work. Just drop the script tag like the good old jQuery and it's working! No wonder it was so easy to switch to it.

Transition from vue1 to vue2 was really simple. I'm sure the same will be true for v3.

Maybe it's the constant React vs Vue articles that make me suspicious, but if you are referring to React when mentioning webpack / transliteration, i'd like to mention that you don't need them for React neither. It can be resumed to a simple script tag as well.

I hate this misconception and wish it would just go away.

Could you paste the simple script tag that makes React work without transpilation? I always thought you needed Webpack (or an equivalent) to transpile JSX into a vanilla js function the browser can interpret.

If you're referring to Create React App, it uses Webpack - just preconfigured so you don't have to fiddle with it before you start building.

Something like this? https://gist.github.com/gaearon/6668a1f6986742109c00a581ce70...

That’s without JSX. Transpilation is required in order to make use of JSX.

So what? You can use React without JSX.

Using the createElement structure is more annoying than just doing a es6 template string in Vue.

Moving the goalpost. I'm only pointing the fact that it is possible, and saying it is impossible is false.

Personally, I don't find the function-call format that "annoying", and I think it presents some advantages neither JSX nor template strings have, along with some disadvantages (it's more verbose, like you pointed out).

And I think GP was saying even if possible it seems rather irrelevant. You could use react without JSX but most likely you will not because you would be throwing away the good things about react. Technically you can eat soup using a fork, but you won’t because...

When React was new and compilers/tooling wasn't that good it was pretty common to use it without JSX. JSX is pervasive because the tooling is now first class (and you'll need it if you make a non-trivial app sooner or later...at which point might as well use JSX since its there), but it works perfectly find without. My first couple commercial apps for React didn't use JSX and it was quite usable. There's just a lack of examples on how to do it these days because no one bothers.

The only time when you won't really have access to a tool chain is for quick demos with just an html page and a script tag (if you don't want to pull in babel as a script), but most online tool allow jsx too now anyway.

There's also a babel script that you can drop into a script tag and will transpile stuff in the browser for you if you want JSX.

Not recommended for large projects in production (but then I'd be using webpack or similar for large vue projects too), but it works pretty well (and surprisingly fast) for quick experiments.

I wrote a tutorial about this.

In this lesson I cover JSX:

https://github.com/kay-is/react-from-zero/blob/master/02-jsx...

No, I meant simply adding a tag and using react directly, in any context. That's how it was originally designed, btw. It wasn't meant only for SPAs when it was conceived, but as an addon to existing websites.

The other comment gives a perfect example and there are a few tutorials (although I do agree not very mainstream) that teach React without JSX/Webpack/Babel/etc.

edit: You are correct that you need transpilation for JSX but you don't need JSX for React. The confusion of JSX/React sounds eerily similar to how newbies confused jQuery for JS.

I don’t think the comparison with JQuery vs JS is at all similar. JSX was created for React, and nearly every time you see React code it’s using JSX. Technically, each of them can be used separately, but it’s a very reasonable impression to consider JSX one of the main features of React.

JS was not created for JQuery, and you can not used JQuery without JS.

"jQuery was created for JS, and nearly every time you see JS code it's using jQuery." Doesn't that sound like something you would hear a few years ago?

Sure, but that’s a linguistic trick. That sentence implies a completely different meaning for the word “for”.

When I say JSX was created for React, I mean that it was created to be a part of the design of React. Meaning they both first came into broader public awareness at the same time, together, and have continued to be promoted as two independent parts of a single system.

In the docs: https://reactjs.org/docs/react-without-jsx.html

Unfortunately it uses ES6 features. There's no ES3/ES5 demo without JSX -- https://reactjs.org/docs/react-without-es6.html uses JSX

Unfortunately it uses ES6 features.

As an aside, is that really a problem these days? All modern browsers now offer comprehensive native ES6 support. Unless you still need to support older platforms like IE or some of the legacy mobile browsers, it's mostly a non-issue.

IE11 is holding out. Mobile Safari is hit & miss

Presumably IE11 will hold out forever, since it's not under meaningful development any more.

What's missing from any recent version of iOS Safari, though? Anything from 10 upwards supports pretty much all of ES6 with very minor exceptions, AFAIK. Even features from more recent versions of ES tend to be supported quite well quite quickly in the era of self-updating "evergreen" browsers.

Like you said, it depends how much you're betting on your JS to work perfectly, and who your intended market is. If all you're doing is hoping for the most optimistic JS runtime (and perfect connectivity, high bandwidth, etc.) and your site is a white screen of death otherwise, then you're not really building a robust piece of software for the web. Of course, that may not be what you're trying to do, then it's a non-issue.

If vue 3.0 uses proxies (as the slides say), then Vue 3 will also now require ES6 features.

http://jamesknelson.com/learn-raw-react-no-jsx-flux-es6-webp...

This is my mini React template for experiments, including JSX: https://gist.github.com/Badestrand/3609e7c3c88ba47bb9682a474...

><script src="https://cdnjs.cloudflare.com/ajax/libs/babel-core/5.8.24/bro...

isn't this just a little bit disingenuous

Wow, that’s cool! I didn’t know you could do it all in the browser. Hats off to the Babel devs.

You definitely do not need Webpack. Here's a bare-bones React component "editor" with support for JSX: https://codepen.io/namuol/pen/MXJOzy

Having started with vue, and now playing with react, I’ve found myself often thinking “this is so much simpler”.

But maybe I just sucked at vue.

I think two-way-binding is the reason why many people prefer Vue to React.

If you did Ember or Angular1, Vue is much easier to grasp.

Well, one-way binding (or rather, unilateral data flow) is why I prefer React :)

Same here.

But I probably wouldn't look too much into React if I wasn't forced to do it in a project 3 years ago.

"v-model" isn't two-way binding like in AngularJS where both parent and child can modify the same data. It's just shorthand for defining a property and an event handler. Like in React, properties flow down and events flow up. See https://vuejs.org/v2/guide/forms.html

Makes sense, I've done some Angular but I'm not used to Vue.

Not really related but forms really are the most painful thing to handle in all those frontend frameworks, it's driving me insane how much work has to go into them when it's dead simple with a backend framework (eg Symfony/Django)!

There are frameworks for AngularJS etc that handle most of the work in rendering forms.

That's the narrative - if you're coming from Angular, you're going to find Vue more similar and probably easier to grasp.

That's interesting, I started with React, and switched to Vue, and felt Vue was the simpler tool.

Same here!

Agreed. When evaluating both of them, it looked like React and Vue implement the same concepts, but React did it in ways that made it more complicated than it needed to be. I specifically didn’t like that Redux and it’s docs were too heady for what it really is (it’s just event triggering and handling, why does it have to be so complicated?), and the fact that React didn’t have any official “here’s is how to build a complete app” docs. It was always “well here are different choices and project layouts you could use”. I don’t want to care about using this templating system or that. I want batteries included. Vue did that well.

Redux is an independent project from React. You could use redux with Vue. Your other points are valid but detracting from one library because people often use another you don’t care for seems outside the scope of React vs Vue.

Just for the record most people using vue would be using Vuex:

https://vuex.vuejs.org

Which IMO is simpler to understand as a newbie than Redux. Maybe because it had the luxury of coming after Redux/similar projects and underpinning a simpler parent framework.

Sounds as of 3.0 it became much simpler, as vuex doesn't sound as necessary.

I’ve yet to build a Vue app that I felt needed external state management (though admittedly none are huge SPAs) but I have felt the pain in React working on a similar sized project. Just something about how the events work out of the box. React I felt like I needed to pass in functions to change parent state through a callback function in props, whereas in Vue I just emit the event and forget about it.

You can still use the function prop pattern in Vue but it doesn’t make much sense when event emission is so much simpler to reason about.

I purposefully avoid Vuex until a) the state becomes large or b) deeply nested objects (which reacitivity handles poorly, as whole trees rerender) or c) when I have lots of deep nested Components with a maze of events.

This is where I've found Vuex is a life saver for reducing complexity, organizing state in a seperate area, and having a consistent interface for accessing/mutating data without a tangled web of events and functions across multiple files/layers.

Redux is at its core super simple.

Action handler gets data, does business logic stuff, sends result off to reducer that publishes the data back to the UI layer.

Online explanations of this suck.

For me, how vuex works was very very easy to visualize. State, mutations and actions are very intuitive.

On the other hand, redux's reducers are harder to visualize at the beginning. Until you learn how the reducer works, every reference to "reducer" leaves you slightly confused.

I visualized redux's better with a simple example. It helps you to see how state and reducers interact.

Long before learning of React or redux I built a similar system to do IPC between two embedded MCUs.

All state was owned by the master MCU, slave MCU sent messages to the master requesting changes of state, the entire state for the slave CPU was then sent over with the requested changes.

Even what UI screen was shown was handled this way.

I was much more junior then, so the entire system wasn't event driven, all state was transferred every 33ms (iirc).

Redux is moderately more complex than that system, although my system was built in pure C and involved interop between C and C# running in an interpreter.

What I like about react is that it's batteries NOT INCLUDED, allowing me to choose tools best fit to the job. I think it's good that there's a healthy choice between vue and react, however!

Hi, I'm a Redux maintainer. FWIW, we're looking at revamping the Redux docs in the near future (see https://github.com/reduxjs/redux/issues/2590 for plans ).

If you've got any specific suggestions for improvements, please let us know! I'm always looking for ways we can make the docs better.

As a side note, React is separate from Redux, and Redux is definitely not tied to React. Here's a recent post about a team that opted to use Redux with Vue: https://snipcart.com/blog/redux-vue .

Sorry I just saw this. If you see this comment, yes I know Redux and React are separate and that you can use other state management systems besides Redux with React. However, that doesn’t help when evaluating the React ecosystem at first. I don’t want to play “pick a library, build a framework”. What I do most of the time is pretty common stuff: SPA with login, CRUD data manipulation, etc. I want a a framework that does 80% of that and has flexibility to create the other 20%. Many React/Redux tutorials are happy to oblige. But they are also all incomplete and unofficial. And by the time a large comprehensive tutorial is written by some kind soul, the APIs have changed, and you are back to SO looking for how to make the damn thing run.

Specifically with Redux, I would suggest clarifying stuff around reducers and possibly renaming them. As is, reducers sound like “a monad is a monoid in the class of ...” Vuex specifically does a very nice job of calling their equivalent thing “mutations” which is more intuitive.

My visualization of Redux/Vuex is basically an application of the event system to state management. Instead of manipulating global.state.foo directly, you ask the system to change the value of foo and a callback does it. A simple explanation like that from the start with some examples of benefits of it would be really helpful.

Also, Vuex has a less strict but more usable idea of not having to import actions. You just refer to them as strings.

Also also, examples of XHR/promises handled by Redux especially with error handling all the way from “server returned 404/400/500/etc.” to how to hand that off to a UI element would be helpful. Takes way too long to discover the right pattern for action returning a promise.

Redux is an incredibly simple idea, I have no clue why every explanation of it sucks.

The naming doesn't help.

"Reducers" is just so academic. Maybe a term like "publishers"?

Of course passing data by props instead of receiving a lambda is a bit of a different paradigm already. Takes some getting used to.

People who found a way to overcomplicate their toolchain for React will also find a way to do the same for vuejs.

I ended up taking over a Vue 1.x codebase and tried to update it to vue2. We used single file components and it was a nightmare trying to upgrade. I spent a good two weeks trying to upgrade and eventually just stopped because it was just taking too long. There were a lot of breaking changes from 2.0 to 1.0, especially with the way events were handled. Now, I will admit that the person who wrote the vue 1.x version did not write idiomatic vue and that caused some problems in updating. A lot of the components we used were also not updated to vue 2.0 and, of course, they were using deprecated features. That meant I had to search for something similar to replicate the existing functionality.

I'm very happy to see React and Vue influence each other. They definitely are the highest quality frameworks out there and having two different research teams only improves the overall quality of the ecosystem.

I'm a React fan, yet I really applaud all the nice stuff which is coming in Vue 3. Well done.

Similarly, I'm a Vue fan, and them having to keep up with and learn from React's moves keeps it solid. I am very happy with recent updates to Vue and their framework is a pleasure to develop with (the tradeoff being a certain level of power that React provides that Vue cannot obtain, but it's plenty).

What power does React offer you that Vue can't? It'd be quite interesting to hear your take on it.

Being able to tell everyone that you know react.

Exporting reactive JS native apps for iOS and Android is the most significant feature -- was what I would have said.

I looked it up before writing this comment, and apparently Vue introduced this in June 2018. Case in point of this comment thread :)

With vue native you can use anything from the react native community in a vue application. You get the best of both worlds!

https://vue-native.io/

The funny thing is that that’s built on top of react native isn’t it?

I thought this was the preferred option? https://nativescript-vue.org/

nativescript-vue has made a lot of progress over the past few months, it’s shaping up to be a pretty great mobile development experience.

>research teams

Lol. Writing JS libs is not research.

React is pretty advanced under the hood. Just because it's Javascript doesn't mean you can't write advanced tech in it.

What makes you say that? People are actively earning phds researching implementations in different languages. JS is different because it’s useful? Runs in a browser?

That's not academic research but that's R&D. And the React team has shown they're very thoughtful about what they're building.

It's been years since people were mocked for using Javascript. The language has greatly matured.

3.0 is a huge milestone for vue.

Currently the architecture forces you to import the Vue object entirely , has Vue under the hood isn't really modular...

With 3.0 Vue has taken the typescript way and is using packages , similar to angular , it looks absolutely awesome to work with now.

I really hope class based components will be supported natively without compiling or transpiling.

Working "out of the box" has always been part of Vue philosophy , I really hope this continue.

This is really a big release , but it's still sad to see the 3.0-alpha branch is not visible on GitHub , i really would have loved to have a look at it.

Vue 3.0 is reported to support class-baed components natively: https://medium.com/the-vue-point/plans-for-the-next-iteratio...

My feeling is that most people who use Vue or React only need a template engine. Typical use case: You have an array of objects and a template how each object should look like.

So you do...

    <div id=users>
     <a v-for="user in users" :href="'user/'+user.id">
      {{ user.name }}
     </a>
    </div>

    <script>
     let userList = new Vue({
      el  : '#users',
      data: { users: users }
     })
    </script>

...to make Vue render the list of objects.

This is the only thing I ever use these frameworks for. Everything else I think I can implement in a better, leaner way myself. So I wonder if I should switch to a template engine instead.

What is the next most basic/common usecase for Vue?

as a React developer, SPAs in general are overused. Most LOB apps could (and should) still be written in a backend templated language. SPAs should be reserved for applications (or even individual components) with advanced interactive features, ie a proper web app.

That's also my conclusion after toying a bit with those frameworks. You want to use them for specific pages ressembling applications, but you still want the main structure of your frontend to be defined server-side, using the most standard technology.

This lets you split your interface into more isolated components, and makes you free to use different framework depending on the type of interaction your page needs, as well as be able to update your site progressively.

yeah, for most web apps that are primarily regular CRUD+routing interfaces, you can/should use SPA tech to progressively enhance your more advanced controls. There are cases where it makes sense to build a whole SPA (I'm working on an in-browser editor that wouldn't work very well as a backend app, for example) but the vast majority of cases where React is used, it just adds complexity and challenge.

React/Redux hasn't been around long enough for its best practices to solidify in the general industry so you'll often find that companies that picked up React have a hodge-podge of incorrectly used technologies included because they didn't know the use case for Thunks vs Sagas, how to use Reselect correctly, whether to store any given state in Redux or a Container, and so on.

Just to confirm: SPA = Single Page Application. What does LOB mean?

line of business. It's basic internal apps most software devs are working on. Usually 90%+ CRUD forms and tables.

Enterprise apps are also a suitable venue for SPAs. You've got some developers coming from e.g. Swing, MFC++ or even Tcl/Tk, and for those doing every frontend bit in JS is closer to standard UI toolkits, instead of the constricting request/response cycle of old webapps (except those few that did some hacks with server-side continuations).

Also, in those cases a few extra seconds for the initial load or the general size of the application don't matter. It's all better than your average Swing application ("Challenge accepted", said the Electron developer).

Although this isn't something contemporary frameworks seem to aim for (ExtJS is dying, and that's good), you get close enough to desktop UI development with Vue/Vuex/Ant Design, Angular/AngularMaterial or React/Material-UI/Redux-boilerplate-reducer-of-the-week.

yeah that's basically the TL;DR of it - the more "desktop app" type functionality you need in your web application, the more SPA technology you're liable to need.

Not sure if your use case includes automatic rendering (new/delete/mods) when the underlying data changes. If it can be done automagically (via unique id in the data) that is a big win (aka, code I do not have to write). Things like shadow DOM et al, are not something I want to implement or maintain.

When the user triggers a change of the underlying data, I do a roundtrip to the server and re-render the current page. I keep the time needed to do so under a second. My users regularely express how WOWed they are by the snappyness of my sites.

I guess what other sites save on re-rendering html, they lose multiple times on bloated code.

„Under a second“ might be ok for websites, but doesn’t cut the mustard for web applications. People expect highly dynamic user interfaces which react almost instantaneously.

If all websites would react within a second to user actions, this would be heaven. But the reality is different:

https://news.ycombinator.com/item?id=18476247

While 30s is off the chart, I see bloat that needs multiple seconds everywhere. The new Reddit, AirBnB, the various Google tools etc etc.

That literally means that you aren't doing SPAs. If you aren't doing SPA then yes using React or Vue is rather a waste.

However the majority of sites these days use some form of SPAs.

Also under a second is a very low bar to strive to. a fast round trip to the server is 100ms. A reasonable one is somewhere around 300ms. Displaying effects to changes is often under a millisecond in SPAs and is basically impossible to reach in Multi page applications.

> However the majority of sites these days use some form of SPAs

Do you have a reference for that claim? I very much doubt you are correct, but I'd be interested in seeing some stats either way, if they exist.

The claim might be true among YC companies or even startups... but the majority of websites by far don't use React/Vue: https://w3techs.com/technologies/history_overview/javascript...

I'm not saying that React/Vue aren't important and drastically changing what's thought of as best-practices in web development... but just because everyone on HN uses a front-end framework for their websites doesn't mean "all websites" do it.

Thanks, these are exactly the kind of numbers I was looking for!

> If you aren't doing SPA then yes using React or Vue is rather a waste.

I disagree, based on my experience of writing a reasonably complex non-SPA application which very much benefits from Vue.

I also think the fact that Vue Router ships as a separate app further suggests SPA is just one use case.

If you're just rendering HTML, you might as well do it on the server with your choice of language/framework. The power of Vue and other Javascript frameworks is in their reactivity and the ability to create extremely powerful interfaces.

I only use Vue when I need to alter the data clientside before it gets rendered. For example mark some of the users in the list as friends depending on which friends the user has stored in localStorage.

If the data is ready to render while still on the sever, I do so.

Sounds like you really have a firm grasp of everything.

I'm DevOps, with 20+ years background in Ops. So the Dev side of things often fascinates and confuses me.

Thank you for clearly talking about why you'd use Vue and when you wouldn't. It's this sort of experience-based knowledge that I often lack.

I'm currently writing basic (very basic!) node stuff intended to further my understanding of Kubernetes: accessing a database, talking to a redis instance, etc etc. It can be bewildering trying to navigate the "oh-so-easy" basic examples of different frameworks and compare their different features.

Hm, that sounds like I'm asking for help, which I'm not - I just want to give an example of why your comments were so helpful to me!

One should use what is necessary and no more. If server side templates work for you - great.

My rule of thumb: if I need to do more then a trivial amount of DOM manipulation then I will use a framework, because otherwise I will end up writing my own anyway (which I can easily do) which wastes development time.

For projects with several developers a framework can help maintain common coding style and reduce ramp up time for new hires.

Also, good frameworks come with nice tooling that make for more productive development. For example, Vue + Vuex and the Vue browser plugin are great for inspecting the state and observing state transitions.

An example of my use case: I have a non-SPA app that receives various data via Websocket and the view is immediately updated. Several components take this same data and render it in different ways. Vue is excellent for this. I still use templating on the server side for the basic page structure.

Could you add the lines needed to the above example to make the user list grow / shrink real time via websockets?

Would be interested to see how you would implement that.

Pseudo-ish code because I’m typing from my phone.

Vuex code as per docs to create state.stuff and mutations.update_suff() then in main Vue instance

    mounted () {
      this.$socket.subscribe(‘stuff’, data => {
        this.$store.commit(‘update_stuff’, data);
      });

where $socket is a subscriber client I wrote wrapped as a Vue plugin.

Then inside the components

    computed () {
      stuff () {
        return this.$store.state.stuff;
      }
    }

then use stuff as in your example.

So very simple, and nothing that I couldn’t do without Vue but it takes care of the boring DOM manipulations and using the browser extension during development I can watch state change (which becomes interesting when there are multiple subscriptions with data combined).

So the first step towards your solution would be to include vuex? Like this?

    <script src="/path/to/vuex.js"></script>

And then?

What are mounted() and computed()? They look like methods of a class?

If a template engine is all you need here's the simplest: https://github.com/wisercoder/uibuilder used by apps such as https://circles.app

Some people maybe, but I doubt it's "most" people.

The point of using Vue is data-binding with reactive models and components.

For your use case I agree Vue is overkill. A templating engine should be enough.

You could use string tags. The only thing that is really needed is a DOM diff library to make UI updates bearable. The rest can be completely handled with a basic MVC architecture.

Vue 3 is a massive new update:

- TypeScript

- Double the performance

- Half the size and memory consumption

- New reactive system that supports classes a la MobX

- Class based components

I've been using Vue for a couple of years and I'm very excited about this new release.

It appears that there are similarities in Vue 3.0 with Aurelia, at least on the surface. Things like class based components, proxy-based observer mechanism* and the move towards typescript all remind me of Aurelia.

Been using Vue 2.0 for personal projects and Aurelia for a big work project over the past year and I have to say I am very happy with both. Personally I prefer the single file components in Vue but the class based style of writing them in Aurelia. Seeing these two things converge in Vue 3.0 together with the performance improvements looks very promising.

*Not sure that under the hood Vue 3.0 works the same way as Aurelia but the mentioned points in the slides lists array index / length mutation and later the observable function are familiar from Aurelia.

The Typescript support is by far the thing I'm most interested in. Lack of useful Typescript support is, for me, the only downside of Vue right now, and it's a big enough downside for me to use React instead of Vue in a lot of cases.

Do you reckon we'll ever see Typescript support in the non-jsx templates? I do really like vue templates for e.g. if-conditionals. I really don't like using ternary operators for template logic. And then the alternative being to hoist things out of the single JSX template breaks make code less linear to read which kinda sucks

to me the biggest downside was how vuex and typescript didn’t work well together by default. You had to rely to adding a few plumbing functions, and that felt really like dirty patching.

Yep, that as well, I agree. And the plumbing is super verbose

Vue has a strong leader - and that is promising.

Does someone have the talk (if there's one) which used this deck as well?

How about the ability to create multiple components in the same .vue file? for instance I need to define a sub-component that will be used only inside my component, this is easy in React but with Vue I have to create another file to define this sub-component, this makes the project management becomes harder as the project grows

This is totally possible. You can create a sub component, register and use it in the same file as the parent component. Though not really recommended you can even do this:

  ...
  components: {
    "inline": {
      template: `
        <h1>My inline subcomponent</h1>
      `
    }
  }
  ...

That is one of the few aspects I prefer in React over Vue.

But you can indeed create small inline components in .vue files.

There are different approaches: https://codewithhugo.com/writing-multiple-vue-components-in-...

>How about the ability to create multiple components in the same .vue file?

No problem: https://www.youtube.com/watch?v=l3GHggI3_z8

As you can see, the're quite a few nested components in a single .vue file.

> ... implementation re-written from the ground up

Rewriting a big project from scratch is often used as something to brag about: "Look at all the hard work we accomplished!". Except in software what matters is correctness and efficiency, not the age or the code or the size fo the rewrite. Rewriting "from the ground up" is throwing away years of bugfixes[1].

Maybe this new version is fine; I'm only suggesting that big re-implementations should be seen as an unknown risks, and that "carefully refactored problematic areas of the code" is something worth bragging about on a slide.

[1] https://www.joelonsoftware.com/2000/04/06/things-you-should-...

> Rewriting a big project from scratch is often used as something to brag about

Not necessarily. Sometimes it means "our old code was such a mess no one could make any sense of it" :)

When your project is such a size that a single person can keep it all more or less in their head (in this case, Evan), clean slate rewrites end up being fairly efficient. It's a much different case than 20->200->2000 devs scale applications. It's vastly more easy to develop something from scratch if you'd put a lot of thought into it over time

Vue itself is less than 10,000 lines. It's not a huge project.

Happy to see this project move forward, but I get surprised when I read 100% speed improvement, since it was already super fast. I wonder how they manage.

Slide 20 "flow -> typescript" is under making it more maintainable - does anyone have any thoughts on this?

I use flow because I am interested in soundness, have had a few issues with it, but nothing has suggested to me that typescript is more maintainable.

TS is more popular and has a bigger ecosystem. It could enable more contribution to the project.

Code? I've been toying with a very specific type of proxy-based observable, and I'd like to compare notes.

I'm interested in looking at the code for a very similar reason, but Evan said it's not open yet: https://twitter.com/youyuxi/status/1063275580920135680

I'm happy to see another framework moving to Typescript.

In case there are any newcomers, it's probably worth noting that just the core framework is written in Typescript, and compiled to normal JS - you are not forced to use Typescript in your own Vue code unless you want to.

Any news on native support for fragments?

Scrolling experience (I am on iPhone) on your site is absolutely horrible

FYI it takes 5.16 seconds to download the 5 megabytes of vendor JavaScript needed to view your landing page from a cold cache (and 2 for your app itself), not to mention the 6 seemingly needless Firebase API calls or the fact you're running the development version of the Firebase SDK.

No matter how awesome you think whatever framework is, this is a terrible, terrible experience.

Nice period substitution. ¬¬

Reply on news.ycombinator.com