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

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

#251

Post by m_fayer » Fri, Jul 06, 2018, 9:13 AM UTC

rraghur wrote: post #239

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 agree - the Typescript support isn't great... I was taking a look at vue + typescript and cobbled together something that worked but there was unpleasant weirdness. I wasn't aware that vue3 was going to be written in Typescript - that is very welcome news.

Yes the weirdness introduced by TS, especially around vuex, is really jarring. But then again, last time I tried a new medium-sized Vue project in plain old ES6, I went running back to TS, weirdnesses and all. And bit by bit, especially with the evolution of vscode, vetur, and TS itself, the weirdnesses are getting better.

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

#252

Post by pjmlp » Fri, Jul 06, 2018, 9:16 AM UTC

mattmanser wrote: post #234

bryanrasmussen wrote: post #221

Earlier quoted context omitted.

>Your tree of UI widgets, and >Your tree of data which feeds those widgets Not with a well-designed XML format and XSL-T! But hmm, nobody seems to use that anymore either.

Having done this in the wild a while ago, it seemed to be hard for most of the other developers to do anything complex with it. You either really got it and then could do wonderful things, or you sorta muddled along with it and it was ok but it was like they were wearing a straitjacket. I made a pivot table control out of it, with almost all the logic inside the XLST, it was amazingly fast compared to IE6's javascrip…

Once upon a time my web site was doing all the rendering via XML/XLST, and I looked forward to what might have been Web Components via the XML Components standards.

Oh well, at least Web Components seem to finally be around the corner, a decade later.

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

#253

Post by allover » Fri, Jul 06, 2018, 9:24 AM UTC

_hardwaregeek wrote: post #200

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…

Could you provide a source for the maintainers of redux-form admitting that Redux was a poor fit for forms? I'm inclined to agree and am kind of interested to see their reasons.

Yep, sorry I should have included the reference. This post is by the redux-form creator, in which he states why it was a bad idea, and announces its 'spiritual successor': https://codeburst.io/final-form-the-road-to-the-checkered-fl...

> Also, everyone high up in the React community, including both inventors of Redux [1], say that Redux is not the best place to keep form data. Oops.

[1] https://github.com/reactjs/redux/issues/1287#issuecomment-17...

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

#254

Post by davedx » Fri, Jul 06, 2018, 9:27 AM UTC

Ronsenshi wrote: post #206

blencdr wrote: post #198

Earlier quoted context omitted.

have you even tried to use TypeScript on a real project to say something like that ?

He's possibly meaning that if you completely rewrite framework it would lead to something like what happened to Angular when it was rewritten and promptly lost huge number of followers/users?

Angular didn't lose mindshare because of TypeScript, it lost mindshare because they completely changed the API of Angular, meaning a bunch of companies had to do expensive ports/complete rewrites/switch to new tech. A lot of companies are still stuck on Angular 1 for this reason.

Most Angular devs I know are happy to use TypeScript. (In fact going out on a limb, most JS devs I know).

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

#255

Post by dmitriid » Fri, Jul 06, 2018, 9:36 AM UTC

rawTruthHurts wrote: post #232

sbjs wrote: post #199

Earlier quoted context omitted.

Also Vue is multiple languages. There's a pseudo-HTML language. There's a loop language inside v-for, a special assignment language. React is just JavaScript and HTML.

I'm not sure attributes named as "ref" or "className" qualify either as Javascript or HTML

They qualify as JavaScript because className etc. are exactly how you work with HTML attributes from Javascript: https://developer.mozilla.org/en-US/docs/Web/API/Element/att...

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

#256

Post by dmitriid » Fri, Jul 06, 2018, 9:37 AM 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…

You don't need JSX to work with React. JSX is a paper-thin DSL on top of `React.createElement`. Use that, if you want.

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

#257

Post by avinium » Fri, Jul 06, 2018, 9:54 AM UTC

mattmanser wrote: post #234

bryanrasmussen wrote: post #221

Earlier quoted context omitted.

>Your tree of UI widgets, and >Your tree of data which feeds those widgets Not with a well-designed XML format and XSL-T! But hmm, nobody seems to use that anymore either.

Having done this in the wild a while ago, it seemed to be hard for most of the other developers to do anything complex with it. You either really got it and then could do wonderful things, or you sorta muddled along with it and it was ok but it was like they were wearing a straitjacket. I made a pivot table control out of it, with almost all the logic inside the XLST, it was amazingly fast compared to IE6's javascrip…

Wouldn’t happen to have a link to that DailyWTF would you? Would love to read the discussion.

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

#258

Post by Vinnl » Fri, Jul 06, 2018, 10:13 AM UTC

pcstl wrote: post #228

Vinnl wrote: post #214

Earlier quoted context omitted.

> Your application state should be kept separately, Is Redux not exactly that?

It can be used for that, but it quickly becomes cumbersome. Redux, in my opinion, should be used for complex UI state in applications with complex interfaces where interactions with one part of the UI can change very different parts ("spooky action at a distance", so to say). But it shouldn't be used to keep all your application's state. Your application's state should live outside of React, and be passed in as the r…

I agree w.r.t. what you should Redux for. That said, if you store application state in Redux, is that nout "outside of React", passing it in as props? (Though not necessarily the root's props.)

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

#259

Post by MaxBarraclough » Fri, Jul 06, 2018, 10:15 AM UTC

Vinnl wrote: post #213

hvidgaard wrote: post #212

> Vue is really fast. Maybe not the fastest, but its performance is overkill for the vast majority of web projects. When was the last time you needed to render and update thousands of DOM elements per second? Rubs me the wrong way. Better performance is always a net gain, and a high performance website provides miles better UX than the same website with waiting all the time.

> Better performance is always a net gain, I think that's easily disputed: it's always a trade-off. A 0.001 ms improvement in performance is a net loss if makes code 10x less readable, because that means programmers are more likely to introduce bugs, which would be a net loss. For example, I one worked with someone who changed all i++'s in a codebase to ++i's, even though they were not in performance-critical codepat…

The poor performance of web technologies (despite the incredible wizardry that's going into our browsers) are a large part of the reason that so much mobile-device interaction fails to run at 60FPS, no?

It's 2018, we're all walking about with supercomputers in our pockets, and yet we're putting up with The impact of UI performance on user experience is serious enough that Netflix wrote their own rendering engine. https://medium.com/netflix-techblog/crafting-a-high-performa...

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

#260

Post by Vinnl » Fri, Jul 06, 2018, 10:15 AM UTC

hvidgaard wrote: post #222

Vinnl wrote: post #213

Earlier quoted context omitted.

> Better performance is always a net gain, I think that's easily disputed: it's always a trade-off. A 0.001 ms improvement in performance is a net loss if makes code 10x less readable, because that means programmers are more likely to introduce bugs, which would be a net loss. For example, I one worked with someone who changed all i++'s in a codebase to ++i's, even though they were not in performance-critical codepat…

I was speaking in the context of two different frameworks, not code, but I suppose the clarification is nessesary. > I one worked with someone who changed all i++'s in a codebase to ++i's Did you use the previous value of i, or did you just intent to increment it? ++i communicate that I'm not interested in the old value, where as i++ does the opposite. I actually use it as such, because my intent to a future reader o…

> Did you use the previous value of i, or did you just intent to increment it? ++i communicate that I'm not interested in the old value, where as i++ does the opposite. I actually use it as such, because my intent to a future reader of the code is more clear.

I would consider that a valid reason to use ++i. In this case, however, he indicated performance as being the reason. Furthermore, this was for a school assignment demonstrating that we could properly implement a particular algorithm, so the performance difference was absolutely irrelevant.