Vue.js: the good, the meh, and the ugly • Hacker News Board

Re: Vue.js: the good, the meh, and the ugly

#121

Post by joshschreuder » Thu, Jul 05, 2018, 11:19 PM UTC

mcbits wrote: post #108

carusooneliner wrote: post #11

I can vouch for the author's points on the good parts of vue.js. We've built our single page application (SPA) web app with vue.js and are very pleased with the results -- https://checkoutclip.com . We were able overcome most of the stumbling blocks by looking up https://vuejs.org/v2/guide/ , https://github.com/vuejs/vue/issues and https://forum.vuejs.org . For server side rendered (SSR) pages, we're using nuxt.js, w…

Five (5) megabytes of JavaScript for a basic brochure site... I assume 99.9% of that is only necessary after signing up and signing in, not while unfortunately viewing the page on a less-than-flagship mobile device and metered data plan?

Welcome to web in 201x. This is not a problem exclusive to Vue.

With that said, the new vue-cli uses Webpack 4 now which can do code splitting, and you can code split on route also to make individual page bundles smaller.

Re: Vue.js: the good, the meh, and the ugly

#122

Post by vanderZwan » Thu, Jul 05, 2018, 11:20 PM UTC

Has anyone checked out the linked framework benchmark[0], and some of the other frameworks linked in there? I had not heard of surplus and S.js before, but they look like an interesting combo[1][2].

Their reasoning for why surplus uses real dom nodes seems pretty solid[3]. My oversimplified TL;DR: a virtual DOM mainly solves the problem of JavaScript not being reactive; the DOM already is. So if you have an efficient general solution for adding reactivity to JS, the need for a virtual DOM is reduced as well, and removing it then saves on the performance / complexity / interop overhead that it would add.

And S.js looks like pretty sweet reactivity library, even without surplus - lots of fine-grained control options too.

[0] https://github.com/krausest/js-framework-benchmark

[1] https://github.com/adamhaile/surplus

[2] https://github.com/adamhaile/S

[3] https://github.com/adamhaile/surplus#why-real-dom-nodes

Re: Vue.js: the good, the meh, and the ugly

#123

Post by toddh » Thu, Jul 05, 2018, 11:23 PM UTC

andrewstuart wrote: post #69

I don't get the thing about ReactJS boilerplate where he says "Moving from React to Vue seems like a breath of fresh air. No more bind(this) or setState() everywhere. Yay! " Surely there's better ways of doing ReactJS rather than lots of setState? Of course I use setState but try to avoid it generally. And I almost never, ever use bind() - don't es2015 fat arrows make it obsolete?

The react tutorial uses bind all over the place. So they apparently think it's still necessary.

Re: Vue.js: the good, the meh, and the ugly

#124

Post by voltagex_ » Thu, Jul 05, 2018, 11:25 PM UTC

jazoom wrote: post #101

voltagex_ wrote: post #88

Earlier quoted context omitted.

How does your site sound/read in a screenreader like NVDA? [0] 0: https://www.nvaccess.org/

That's a really good point, and it's one of the drawbacks of designing a website for the 95%. I haven't tested myself (I'm just one dude - there's a lot I'd like to do but haven't yet), but I see no reason why it wouldn't work well. I try to design semantically and everything is rendered server-side. But, in reality, I don't think this is the kind of website that would be usable for a blind person anyway. There's not…

Vision impairment is a spectrum, so someone who can see to some extent may be using a screen reader to assist. People might be using your site at 150% zoom, etc etc.

One thing you can do is put a note somewhere easy to find that says "if you require assistance using this site, email someone@domain.org". Sites that I've worked on also had a phone number here but I understand that's an edge case.

You also mentioned alternative ways to get information - if there's ones you can link to (without linking to a competitor or whatever), there's no reason not to provide links.

Re: Vue.js: the good, the meh, and the ugly

#125

Post by voltagex_ » Thu, Jul 05, 2018, 11:27 PM UTC

carusooneliner wrote: post #104

voltagex_ wrote: post #88

Earlier quoted context omitted.

How does your site sound/read in a screenreader like NVDA? [0] 0: https://www.nvaccess.org/

Haven't tested, I intend to make it possible. Thank you.

I haven't checked recently, but JAWS [0] is probably the dominant screenreader still - NVDA is the open source alternative. Ideally you'd test in both

0: https://www.freedomscientific.com/Products/Blindness/JAWS

Edit: using a screenreader effectively is a skill in itself. There are consultancies around accessibility testing. I am not affiliated with any of them.

Re: Vue.js: the good, the meh, and the ugly

#126

Post by voltagex_ » Thu, Jul 05, 2018, 11:33 PM UTC

octref wrote: post #111

voltagex_ wrote: post #93

Earlier quoted context omitted.

>Some other frameworks assume that you want a build tool, state management, client side routing etc and beginners spend hours configuring those tools and figuring out state management and client-side routing, instead of doing real work. Okay, say I do the tutorial and build a simple page - how hard is it to retrofit routing or whatever to it? A lot of the time with new frameworks, if I get past the initial setup hurd…

One thing I want to say is: Don't assume only developers make websites. Don't assume everyone wants to ship a heavy and complex SPA. Example 1: A great typographer, Wenting Zhang, author of Type Detail[0], contributing to Source Han Serif, learning Vue to do some interactive widget for variable fonts[1]. Example 2: Brian Terlson on TC39. He's using Vue without Vuex or Vue-router to build an app to track TC39 discussi…

Thank you! That's a really good way to think about things and might be the push I needed.

Re: Vue.js: the good, the meh, and the ugly

#127

Post by interlocutor » Thu, Jul 05, 2018, 11:33 PM UTC

spiritcat wrote: post #105

acemarke wrote: post #72

Earlier quoted context omitted.

Out of curiosity, what are you using instead of JSX? Plain `React.createElement()` calls, `createElement` aliased to a shorter variable like `e`, or something like the `react-hyperscript-helpers` library?

it's funny how originally jsx is what kept me away from react, and now it's what keeps me from leaving.

You can actually leave react and still keep JSX. This tiny library lets you use JSX as a templating mechanism: https://github.com/wisercoder/uibuilder

Re: Vue.js: the good, the meh, and the ugly

#128

Post by HumanDrivenDev » Thu, Jul 05, 2018, 11:34 PM UTC

I started out with vue, but found it too heavyweight and clunky. A viewmodel framework shouldn't need its own god damn compiler or file format. I ended up switching to mithril.js, which is much smaller than vue and comes with its own router. Haven't missed vue at all.

Re: Vue.js: the good, the meh, and the ugly

#129

Post by strken » Thu, Jul 05, 2018, 11:36 PM UTC

chrisco255 wrote: post #86

strken wrote: post #51

Earlier quoted context omitted.

React isn't about JSX and passing foo/onUpdateFoo down 20 levels of props. It's about data flowing in one direction down a tree of diffable virtual components, then being passed back up. The single most important idiom is that all data for a component should come from state or props, and that when you need to break this rule you should do it inside a single component or a handful of components that will then handle y…

Redux is not over-engineered. It's a simple library that's <1000 lines of code. It is great for large, complex apps where state gets hairy to manage. It's a bit verbose for smaller apps. But just because something is verbose does not mean it's over-engineered. It is explicit in defining all the possible states your application can get in. That's useful for a certain class of application.

It might have been more accurate for me to have said "the code you will get if you follow the reference implementations and documentation of Redux will be overengineered". I dislike three things: that dispatch isn't usually made globally available, but is passed through context, which makes it effectively global anyway; that asynchronous actions are only available via plugins despite being a core part of JS development; and that dispatching an action is just a more complicated way of calling a function.

Interested in hearing what you think, though. My Redux experience has been more limited by trying to avoid it on small projects.

Re: Vue.js: the good, the meh, and the ugly

#130

Post by jorblumesea » Thu, Jul 05, 2018, 11:37 PM UTC

One of the best arguments against Vue is typescript support. React has really good support for it, even for the state libs like Mobx/Redux etc. Until they turn that around it will be hard for any frontend application to scale properly.

I think Vue is great for smaller projects and would absolutely recommend it.