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

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

#131

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

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?

We’re still using https://www.npmjs.com/package/react-dom-factories for plain DOM elements, so code looks like

    dom.div({ props }, ...)

For our own components, we export the output of React.createFactory https://reactjs.org/docs/react-api.html#createfactory rather that the component itself, so rendering code looks like:

    MyComponent({ props }, ...)

I realise that both of those are marked legacy, with a nudge towards using JSX instead, but they are pretty thin wrappers around createElement so it seems like a small dependency.

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

#132

Post by carusooneliner » Thu, Jul 05, 2018, 11:38 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?

It's going to change and get less hefty, we're looking into code splitting.

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

#133

Post by j1elo » Thu, Jul 05, 2018, 11:41 PM UTC

carusooneliner wrote: post #38

ppiuser wrote: post #31

Earlier quoted context omitted.

Have you looked at your site with javascript disabled? Additionally, was vue used just for the website or the chrome app as well?

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.

Well for what is worth, I had been thinking on the idea for a while after growing tired of so many scripting and tracking everywhere, and I felt encouraged to make the jump and disable Javascript after reading this comment in HN (thanks bmurphy!):

> The single best improvement I've made to my mobile browsing experience in years wasn't getting a new faster phone, it was installing Brave and disabling javascript. [1]

To be honest, (s)he was right. But at the same time, it's disgusting, and plainly bad, to see how much of the Internet is _broken_. Which by my definition means requiring JS even to show some text and images on a web page.

I understand that more advanced features might require some scripting, but come on, I'm pretty sure that's not the case for printing some good old letters and pixels on a browser window! And still, lots of places seem to not know how to do it without dynamic code all around. (I'm not talking about this specific site, in any case. Just felt like ranting.)

[1]: https://news.ycombinator.com/item?id=14153588

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

#134

Post by allover » Thu, Jul 05, 2018, 11:41 PM UTC

atombender wrote: post #118

allover wrote: post #113

Earlier quoted context omitted.

But if you looked at the official React docs the answer was always 'setState' and embracing components, that was the whole promise of React to begin with. Not once did the React team/docs ever say you needed Flux to build a React app. All of those answers you got were cargo-culted from the community. Can you really look at where the community is, the perception that still exists that React+Redux is necessary, project…

Can we blame all the bloggers who take upon themselves to explain what the best practices is? Absolutely. There are also projects (like React Forms and React Router) that clearly led down a path of confusion. But it's hard to blame the developers who read those blogs and try to figure out what they should be doing. I never got the impression, even from the start, that setState() was a good solution, by the way. But i…

> Can we blame all the bloggers who take upon themselves to explain what the best practices is?

It's not really about blaming bloggers.

It's really on software team leads and senior engineers to not just follow blog posts blindly. They should be pushing back on bad advice like redux-all-the-things, because to a senior software engineer the tradeoffs of something like Redux should be fairly obvious.

> The good design is to be found in Relay and GraphQL.

Nah again, good example to question what you read/hear.

GraphQL is great from a front-end point of view but complex to implement in the backend, so it really depends on your use-case whether that backend complexity is worthwhile.

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

#135

Post by jazoom » Thu, Jul 05, 2018, 11:45 PM UTC

voltagex_ wrote: post #124

jazoom wrote: post #101

Earlier quoted context omitted.

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

Hi voltagex, thank you for your input.

I don't think this is the kind of website where I "help someone to use it". Instead of speaking in the abstract I may as well show you so you can see what I mean:

https://pricehipster.com

As you can see, the whole point of it is designed around quickly glancing at prices. And I don't think it makes sense to tell people other places they can find prices if they can't see well enough to use this website.

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

#136

Post by bananadonkey » Thu, Jul 05, 2018, 11:50 PM UTC

atombender wrote: post #97

allover wrote: post #33

Earlier quoted context omitted.

> If plain, idiomatic React so great, why does every semi-complex React app end up bringing in a separate state management framework like Redux or MobX? Sadly it seems that's mainly been cargo-culted. It's not the case that React+Redux is the equivalent to say Angular, but by some unfortunate accident due to Facebook's announcement of Flux, and then the hype around Redux as a 'better Flux', people started assuming Re…

There's unfortunately a thin line between cargo-culting and attempting to follow the mainstream. As developers we can't all be building tools. We choose tools that others build for us, so that we can get our job done. Soemtimes I'm interested in going "one layer down" and build tools, but it's almost always a distraction; we want off-the-shelf products like React and Redux. We need to pick stable tools that promise s…

As one of a small group of maintainers of the build tools of our most complex app, I can concur with this. Yesterday I spent 4 hours fixing a single build/parse issue between dev and prod.

I also spent just 1 hour completing multiple RFCs in another app built with create-react-app using redux/connect as a purely syntactic-sugar state propagation layer.

I love the complexity and feeling of fulfillment for triumphing in the former scenario, but it is definitely much more of a distraction than anything else.

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

#137

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

qudat wrote: post #56

ilovecaching wrote: post #2

I really like a lot of things about Vue. I was apprehensive about using JSX when I first started using React, and I also did not like setState. I think the real issue, though, was that I wasn't thinking functionally. I now rarely write a stateful component, and when I do, it's usually once, for the entire application, or maybe for a few large subtrees if the app is very large. State kept alive by parameters is extrem…

It saddens me that JSX became so popular in the React community. I find the syntax verbose and hard to read ... similar to HTML. At my last company we used `react-hyperscript` which was a simple wrapper around `react.createElement`. Ultimately, the React developers made the mistake of making `createElement` so annoying to work with, I assume because they bought into JSX. Granted, JSX might have been necessary when Re…

If you care about compile-time checking (you would, if you work on medium to large applications) then JSX (or the TypeScript variant, TSX) is much better because it catches invalid or mistyped attribute names etc.

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

#138

Post by NathanCH » Thu, Jul 05, 2018, 11:54 PM UTC

I think both React and Vue become difficult when working with complicated UIs. If you're already using Vue or React, these simple articles are not comprehensive enough to be convincing.

React and Vue basically manage state the same way, which is 90% of what you'll be doing in these libraries.

And just like in React, default state management is insufficient in Vue.

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

#139

Post by nepeckman » Thu, Jul 05, 2018, 11:54 PM UTC

qudat wrote: post #56

ilovecaching wrote: post #2

I really like a lot of things about Vue. I was apprehensive about using JSX when I first started using React, and I also did not like setState. I think the real issue, though, was that I wasn't thinking functionally. I now rarely write a stateful component, and when I do, it's usually once, for the entire application, or maybe for a few large subtrees if the app is very large. State kept alive by parameters is extrem…

It saddens me that JSX became so popular in the React community. I find the syntax verbose and hard to read ... similar to HTML. At my last company we used `react-hyperscript` which was a simple wrapper around `react.createElement`. Ultimately, the React developers made the mistake of making `createElement` so annoying to work with, I assume because they bought into JSX. Granted, JSX might have been necessary when Re…

Agreed. Personally, I much prefer ClojureScript's approach to react, which is to use native vectors combined with keywords. So a component could be declared like this example from the re-frame framework. [:div.garbage-bin :on-click #(re-frame.core/dispatch [:delete-item item-id])] Easier to read, no need for an extra compile step or any non-native syntax.

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

#140

Post by ilovecaching » Thu, Jul 05, 2018, 11:57 PM UTC

smackay wrote: post #25

stupidcar wrote: post #17

Earlier quoted context omitted.

If plain, idiomatic React so great, why does every semi-complex React app end up bringing in a separate state management framework like Redux or MobX? The reason is that while you may be able to break up your HTML into a composable hierarchy of purely-functional components, the actual data and state you need to distribute to them has a structure that is completely unrelated to how its laid out in the DOM. In a comple…

For me (Vue + Vuex) the choice was simple: you get undo for free. Having a shared store really does change the way you look at web apps - it's almost a completely different paradigm. If you can avoid re-loading the data for a view if you already have it then then opening a new view to edit a subset of the data instead of dealing with popup makes life so much easier - you get a lot more freedom with the UX and going b…

You can have undo for free using React as well. React doesn't care about how you manage your state changes, and it will selectively render only the parts of your app that changed.