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

361–370 of 382 posts

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

#361

Post by ixtli »

biggerfisch wrote: post #334
ixtli wrote: post #291

One of the gems in this that i think might be getting overlooked: > This trend of using chats for questions is plaguing open source projects and I think it needs to end. There is no collective learning anymore. This is a very important notion not least of all from an archival pov.

I see why many people consider this to be a problem, and it does severely limit the ability of knowledge to persist, but I think there are some benefits to it, namely that the answers can always be up-to-date. I don't know how many times I've found answers for versions of my libraries/toolkits that are so old that they're useless. There's little point these days in persisting answers to questions about Node 0.4.0, fo…

For sure! The fact is that IRC has existed parallel to the development of this entire industry so the desire to hang about in a chat room is real and should be served, but the modern incarnations of this are causing some people to stop cataloguing the small bits of necessary info about complex systems which i think is bad.

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

#362

Post by kalkut »

acemarke wrote: post #353
kalkut wrote: post #350

Earlier quoted context omitted.

You really are helpful and you try to fix this so I really want to say yes but I am currently grinding for my own startup so I know that a lot of time will pass before I actually do it so I don't promise anything. A good way to test it would be to make a simple websocket server that simulate n users each sending n' fake xyz position and rotation data per second. This data updates a Redux store in a React app made wit…

Gotcha. I've made a note of this in https://github.com/reactjs/react-redux/pull/898 for future reference. If you ever do have some free time to throw together an example app that demonstrates this behavior, please feel free to link it in that issue, or ping me directly (Twitter and Reactiflux are usually best).

I ended up hacking a benchmark. I couldn't beat that itch !

I mentioned it in the pull request, here it is : https://github.com/Kalkut/redux-data-frequency-benchmark

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

#363

Post by ethbro »

mattmanser wrote: post #268
avinium wrote: post #257

Earlier quoted context omitted.

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

I was having trouble earlier, but have tracked it down: https://thedailywtf.com/articles/Sketchy-Skecherscom The featured comment at the bottom is from the original devs. One of the early comments is that it only worked properly on Firefox, which is wrong. IE6+ had excellent, extremely fast XSLT support. The company I worked for at the time actually had an enterprise app that didn't work properly on FF as it relied o…

> It did make me realise how infrequently you actually re-use specific data queries and a lot of people over-egg how much data re-use there is or logic sharing that is actually required in a real-world app.

Agreed. Possibly a microsymptom of the "business only does boring things, developers do interesting things" mindset.

In my experience, one needs to constantly guard against thinking anyone else is mindlessly turning a crank. In fact, they're likely doing just as complex and interesting stuff as you, only with different tools.

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

#364

Post by aidenn0 »

nepeckman wrote: post #139
qudat wrote: post #56

Earlier quoted context omitted.

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.

about 30 seconds after learning react, I wrote a parenscript wrapper for it because I find the SGML syntax to be super annoying.

A translation from the JSX example that was the first (only?) example on the React homepage at the time:

https://github.com/jasom/parenscriptx/blob/master/example/co...

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

#365

Post by aidenn0 »

panoply wrote: post #298
_bxg1 wrote: post #79

I've used React full-time at work for a year and a half now, and I did a personal project in Vue for a while to try it out, before converting it to React. There are some things I really, really hate about React. It is not kind or accommodating (Vue is both of these things), but it gives you control. I was head-over-heels for the first few days of using Vue; "breath of fresh air" is exactly the phrase I'd use. But the…

I choose Mithril.js regardless of the apps complexity nowadays. I've built apps in React and Vue and do agree that Vue is the logical choice over React but I don't see it as ground breaking or magical. I see Vue for what it is, A JavaScript framework that gained popularity by being included by default in the Laravel framework and now has good financial backing. Mithril.js is a framework that is truly "magical" in my…

I also use Mithril, and in my opinion, it's less "magical" than React in the sense that the GP is using[1].

When I ran into an issue using React, tracking it down was extremely difficult (by the end it was just "difficult" due to improved tooling around react). Mithril is small largely because of its simple implementation, which makes debugging a joy.

1: They seem to mean magical in the sense if "I'm never going to understand how it works"

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

#366

Post by drunknhik »

acemarke wrote: post #349
mosdl wrote: post #343

Earlier quoted context omitted.

You can achieve all of that with a singleton that is shared and some events (and do some of your own batching). No need for another dependency and you save bloat size.

Well, the whole app is built around Redux in the first place :)

To me this underscores the most unspoken point. Redux is meant for when you specifically want to build your app around redux. It's not meant to tack on some global store to an existing UI. It is UI agnostic way of separating your business logic and side effects from the UI iself (which could be react, vue, angular, whatever)

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

#367

Post by likeclockwork »

dmitriid wrote: post #290
ipntu wrote: post #286

Earlier quoted context omitted.

This is patently not so. Maybe if you are used to JSX. - three different html-like attributes : and @ are just shorthand for v-bind and v-on attributes. v-bind and v-on (and v-if) accept regular javascript, and it's not just expressions... you can use `active = true` to change a data value, for instance. The only exception is v-for, as you mentioned, but it is close enough to ES6 for syntax to make sense, at least IM…

> just shorthand > accept regular javascript... The only exception is... but it is close enough to ES6 So you basically validated all I've said. And it's also incomplete. Because the amount of gotchas and things that you have to constantly keep in mind in Vue is mind-boggling compared to JSX. Because JSX is a paper-thin wrapper on top of React.createComponent, and goes out of its way to keep everything in Javascript.…

> Let's see how this is false:
> This is not Javascript. If it was, it would assign the result of the function call to @click. It doesn't. It's a Javascript-like scripting language that has magical binding into regular Javascript.

You're wrong. The contents of the event handler is JS, the whole snippet is obviously HTML.

    Say Hi.
This is also plain regular HTML and has been since HTML4 (1997). The value of the onclick attribute is a string of JS. There's no assignment of the result happening. It registers a click handler. The only difference between the two, on a surface level, is that the Vue example has things in scope (edit and todo) that aren't globals.

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

#368

Post by acemarke »

drunknhik wrote: post #366
acemarke wrote: post #349

Earlier quoted context omitted.

Well, the whole app is built around Redux in the first place :)

To me this underscores the most unspoken point. Redux is meant for when you specifically want to build your app around redux. It's not meant to tack on some global store to an existing UI. It is UI agnostic way of separating your business logic and side effects from the UI iself (which could be react, vue, angular, whatever)

For the most part, yeah.

Now, the other app my team works on is built with Backbone/Marionette. We've introduced React and Redux to it, and are progressively refactoring over time. It works, although we've got some rather ugly code in several places (some data is in Backbone collections, other data is in Redux, and occasionally some bits of data are mirrored in both places).

I wrote about some of the techniques we're using to integrate them here: https://blog.isquaredsoftware.com/2017/07/react-redux-backbo...

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

#369

Post by drunknhik »

dmitriid wrote: post #290
ipntu wrote: post #286

Earlier quoted context omitted.

This is patently not so. Maybe if you are used to JSX. - three different html-like attributes : and @ are just shorthand for v-bind and v-on attributes. v-bind and v-on (and v-if) accept regular javascript, and it's not just expressions... you can use `active = true` to change a data value, for instance. The only exception is v-for, as you mentioned, but it is close enough to ES6 for syntax to make sense, at least IM…

> just shorthand > accept regular javascript... The only exception is... but it is close enough to ES6 So you basically validated all I've said. And it's also incomplete. Because the amount of gotchas and things that you have to constantly keep in mind in Vue is mind-boggling compared to JSX. Because JSX is a paper-thin wrapper on top of React.createComponent, and goes out of its way to keep everything in Javascript.…

Have you ever made a graphql server with apollo-tools? Do you complain that SDL is a "new syntax" that you have to learn when you can just use regular javascript?

> > This is not Javascript. If it was, it would assign the result of the function call to @click. It doesn't. It's a Javascript-like scripting language that has magical binding into regular Javascript.

Great, so it's not javascript.

To a lot of folks it looks a lot nicer than

this.edit(this.state.todo)}>

There's a lot less noise, and it's _much_ friendlier for (most) designers.

I have never felt that I had to keep hundreds of gotchas in my mind while using vue. The syntax is extremely intuitive (unlike angular). Takes maybe one hour to read through the docs, and you have it.

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

#370

Post by _Tev »

sametmax wrote: post #272
k__ wrote: post #85

Earlier quoted context omitted.

Vue reminded me so much of Ember that I could not understand how people could think of fresh air...

Embed is more complicated than vue to use. Vue has components. Updating the dom is mostly mutating your component attributes. That's it. Nothing else. With ember you got controllers, models, inheritances, many special methods... The VueJS documentation also makes it easier to get in. The Ember beginer tutorial starts with a full fledge app with a cli to install and use and features routing and addons O_o

> Vue has components. Updating the dom is mostly mutating your component attributes. That's it. Nothing else.

How long have it been since you at least looked at Ember?

> With ember you got controllers, models, inheritances ...

You use those now only when you choose to or not at all.

> ... many special methods

= adding features Vue does not have.

> The Ember beginer tutorial starts with a full fledge app with a cli to install ...

Ember-cli is something everyone is desperately trying to copy. Even Vue!

Sorry, but this sounds like generic anti-JS-hate: tons of misinformation to bash something you have no clue about.

Post reply on HN