Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

medium.com

Post reply on HN
Print view View original

101–110 of 382 posts

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

#101

Post by jazoom »

voltagex_ wrote: post #88
jazoom wrote: post #55

Earlier quoted context omitted.

It's not common. My site with hundreds of thousands of users has been using React/Vue for years and I've never had one complaint about JavaScript. If JavaScript is disabled I just show a message saying the site needs it. I also only support modern browsers and haven't had a complaint for 3 years. About 3 months ago I completely dropped support for any browser that doesn't support CSS grid (no more IE 11!). Again, no…

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 really anything to read. There would be much better ways for a blind person to get information than using this website.

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

#102

Post by carusooneliner »

benbristow wrote: post #92
carusooneliner wrote: post #38

Earlier quoted context omitted.

Our site does't work with js disabled. Serious question: is it common for folks to disable js? vue is used only for the web app. No js frameworks used in the chrome app.

It's best to use some sort of server-side rendering so you get the best of both worlds. JavaScript-only is not friendly for SEO.

Agreed! We're working on prerendering some pages -- https://ssr.vuejs.org/#why-ssr .

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

#103

Post by parr0t »

RussianCow wrote: post #57
parr0t wrote: post #5

Interesting timing with coming across this article for me. I have started developing re-designing our site frontend to use Vue with Vuex and the point this author makes about where to put the API logic also made me scratch my head a bit. Sometimes I just need to make a simple API call that does not alter the application state and just needs to grab some information and render said information in 1 component. Technica…

I think the most important thing is to be consistent, instead of having a mix of API logic that originates from components and from the store. And since there are certain types of higher-level logic that are very difficult to house inside components, I have found that having your store be the origin for _all_ API-related logic is the best way to go, even if it seems overkill for simple things. It's better to be globa…

This is essentially my chain of thought and what I have done. Even if it is a simple request that is confined to a single component when a developer looks at the codebase they can know that all API calls are called from Vuex modules and not modules _and_ components.

That then leads me to my next question though, if I am using Vuex to abstract the API calls is it bad practice to use Vuex actions for API calls that don't need to be saved into the store?

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

#104

Post by carusooneliner »

voltagex_ wrote: post #88
jazoom wrote: post #55

Earlier quoted context omitted.

It's not common. My site with hundreds of thousands of users has been using React/Vue for years and I've never had one complaint about JavaScript. If JavaScript is disabled I just show a message saying the site needs it. I also only support modern browsers and haven't had a complaint for 3 years. About 3 months ago I completely dropped support for any browser that doesn't support CSS grid (no more IE 11!). Again, no…

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.

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

#105

Post by spiritcat »

acemarke wrote: post #72
DougBTX wrote: post #35

Earlier quoted context omitted.

React was advertised from the start as the V in MV-whatever, so that seems like an overly restrictive definition of "idiomatic". > At which point, JSX is basically just another fancy HTML templating library. JSX is optional syntax sugar; my team uses React and Redux heavily, but we've opted not to use it. HTML templating is great actually, all the rendering is data -> UI. If you go back to the early Rethinking Best P…

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.

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

#106

Post by _bxg1 »

aylmao wrote: post #95
_bxg1 wrote: post #87

Earlier quoted context omitted.

I've been using React full-time for a year and a half now, and I've never felt like pure-functional components are a good fit for more than a handful of use-cases. If all you're doing is displaying data, then sure, they're really elegant, but most UI code isn't a pure function of state; it also sends messages back to state, which means the two are tightly coupled, which means pretending they aren't feels gross and we…

> most UI code isn't a pure function of state; it also sends messages back to state, which means the two are tightly coupled I think this is what the Flux model is all about, making UI code actually be a pure function of state. By that, I mean literally a function, where state is the argument, and where all you render depends solely on said argument. If you want to change what is rendered, you send a message and a St…

Well because the UI isn't just a function of state, it's also a function of those actions (the actions have to literally be passed in to the rendering function). So there's bi-directional coupling between the UI code and the Store (the UI code renders from the state, and passes messages back to the store).

Also, conceptually, you often have a lot of state that's very directly concerned with and specific to the UI, and isn't just idyllic, agnostic "data". Things like "is this menu open or closed?" and "what's the current string value of this input (which isn't meaningful until the form is submitted)?" In Flux, those things tend to add a ton of boilerplate in terms of change actions, and split tightly-related concerns into separate corners of the codebase (if I remove this menu component I have to remove its open/closed state variable and the corresponding action).

To be sure, there's not really a great way to decouple things in the reactive architecture. I personally lean towards stateful components that are decoupled at their boundaries instead, which does carry its own downsides. The only solution I've ever seen that truly felt right was two-way databinding, which Vue (sort of) still has, but which has fallen out of fashion in general because it requires "magic" and because it tends to come with performance costs.

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

#107

Post by jgrpf »

ilovecaching wrote: post #52
ElatedOwl wrote: post #28

We adopted Vue 2 years ago and I've been extremely happy with it. It's very easy to get into, the learning curve is not steep at all, and for the most part it just works. TypeScript support is mediocre. It's supported (Vue will let you use anything) but it's clearly a second class citizen. There's also no real accepted best practices, which the author touches on (where do API calls go). Third party component design v…

I'm curious to know, what about Vue makes it easier to learn than React? It's just a function that takes in data and returns a piece of html. React also just works, and unlike Vue, it's worked for companies like Netflix, Wallmart, Facebook, Instagram, etc that have exceedingly complex requirements and require exceedingly fast rendering. What did you really buy with Vue over React?

Apart from anecdotal experience telling me that fresh JS devs have a much easier time with Vue than React, I love to still have the option to use it through a simple embed without a build system but can switch to a Webpack/any module bundler if the requirements demand it.

The JS ecosystem really has a problem with bloat in my opinion and Vue trumps React in the regard (react eject anyone?).

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

#108

Post by mcbits »

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?

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

#109

Post by jarvelov »

octref wrote: post #89

Have to do some clarification here on the point of "Unclear architectural patterns", as the article is way too misleading. - The reason the API call is made at `created` lifecycle is that the video is a quick, 5 minute intro for beginners . Beginners, as in "people who are familiar building static websites using html/css/js". There is no need to bring in Vuex or vue-router yet. In fact the whole beginner example can…

I'm not sure were the author looked for information about architectural patterns but there is a separate section on it in the documentation: https://vuex.vuejs.org/guide/structure.html

This clearly outlines a suggested structure for non-trivial apps, where API requests are separated from the state management. It also references the Shopping cart example as a guide.

Due to this glaring oversight I can't see any criticism the author has as valid in the section about "Unclear architectural patterns".

Post reply on HN