Live data from Hacker News

Vue 3.0 Updates [slides]

docs.google.com

71–80 of 126 posts

Re: Vue 3.0 Updates [slides]

#71
post #43

Earlier quoted context omitted.

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.

Re: Vue 3.0 Updates [slides]

#72

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.

Re: Vue 3.0 Updates [slides]

#73
post #36

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: `
        My inline subcomponent
      `
    }
  }
  ...

Re: Vue 3.0 Updates [slides]

#74
post #45

Earlier quoted context omitted.

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.

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

Re: Vue 3.0 Updates [slides]

#75
post #45

Earlier quoted context omitted.

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.

Re: Vue 3.0 Updates [slides]

#76
post #4

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.

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.

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

Re: Vue 3.0 Updates [slides]

#77
post #16

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... {{ user.name }} let userList = new Vue({ el : '#users', data: { users: users } }) ...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 bett…

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 ti…

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.

Re: Vue 3.0 Updates [slides]

#79
post #16

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... {{ user.name }} let userList = new Vue({ el : '#users', data: { users: users } }) ...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 bett…

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.

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.

Re: Vue 3.0 Updates [slides]

#80
post #39

Earlier quoted context omitted.

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.

Post reply on HN