Comment by no1youknowz | Hacker News Reader

Comment by no1youknowz | Hacker News Reader

Parent Full thread

> Seeing those quasi-JS expressions in HTML attributes is enough to put me off Vue.

They are supremely useful. Ultimately, it's knowing how to use them to their maximum potential.

I've been coding since '02-ish. When I code with Vue, I have an App Developer mindset, rather than a web developer jQuery mindset.

When I use an attribute, it's just referencing a variable. It reacts to its own state in real-time.

I'm not the best at explaining. But with a legacy mindset, you have to interact with the DOM in some way. Whereas with HTML attributes in Vue, you can use the state in the local component to determine whether something is shown or even if a particular class is shown depending on what the state is of a variable.

Even better, that could be a computed variable or one that's watched. This functionality allows a bit of logic to then be run to determine how that variable behaves. This alone minimises the code I need to write in terms of legacy applications. Which also leads to less bugs.

Using if, for, show, and binding classes are very very powerful. I rarely interact with the DOM now and everything in state that is complex is an array. I can write way more complex apps with Vue, than I ever could with jQuery.

About the examples given here by the developer. You can still see that he's coding with a legacy mindset and that he hasn't internalised a lot of what Vue offers.

Some minor nitpicks:

- No need for this.$parent.$emit. There is a better way to use $emit.

- this.$on. <- What is this? An Event Bus? This should really have been a method.

- No need to use id attributes at all.

- Why not pass in the index attribute (which he is not using) to the delete function and then he can simply splice the array?

If he wanted to be real flash. He could have written the ToDo component as a JSX render function and taken the array from the parent and looped out the list. I know the Vue community looks down on it, but would have been a better way of going.

I don't really want to seem like I'm crapping over this. I'm not. I've only been using Vue since April myself. But there seems to be a lot of mistakes here and it's just not idiomatic.

Hi there - Thank you for taking the time to read and review, I really appreciate it. I wondered whether you would be interested in making an update to the git repository with the suggestions you have made. I'd be more than happy to update the article and credit you for your input. If so, the link can be found at: https://github.com/sunil-sandhu/vue-todo

As an aside, I thought I'd let you know that I've been a developer for just under one year, so admittedly do not have anywhere near the level of expertise that you have. I've also only been using Vue since April, but I guess that my level of overall experience, relative to yours, is lacking somewhat.

Back in the day before React was a thing, I got invited for an Uber interview. Their standard challenge is to make a sudoku app on GitHub before they even see your face.

I got ambitious and tried to do with Vue.js and learn the framework in the process. Magic state updates were nice when it worked but with deeply nested models it always failed and I had to hack around to force it to update. I spent a ton of time fighting vue magic. I was ambitious. I wanted to make a generic NxN sudoku game where N was a url param.

Overall vue was like angular, done slightly well but it still had angular like problems where the magic failed and you had to dig very deep in code. It was also very slow to update the Dom. I had to revert to DOM element mangling just to speed up initial shuffle algorithm. I believe vue2 got on the vdom bandwagon so that’s nice.

I finally got it done, with two loooong nights.https://github.com/nojvek/uber-sudoku/blob/master/README.md

Uber did meet with me face to face but I didn’t want to move SF at the time and they didn’t have a Seattle office.

Overall vue has great ideas, probably good for a small project, but if you want to do a big SPA, I would not recommend unless you are really prepared to learn the internal magic.

Nowadays I really prefer preact. It’s the React api, it’s small, fast (has a better license - before Facebook got its shit together). One can read the entire source code in an hour or two.

It does one thing, it does it really well. This is what I like to see in libraries.

Really nice job on the Sudoku!

Thanks

I'm pretty sure React was already a thing when Vue started out

> > Seeing those quasi-JS expressions in HTML attributes is enough to put me off Vue.

> They are supremely useful. Ultimately, it's knowing how to use them to their maximum potential.

Supremely useful for a typical full stack developer -- yes. Supremely useful for a dev team with members who specialize in web design (plain HTML, CSS, etc) -- not necessarily.

When your source code mixes a bunch of different web technologies it limits the types of developers who can effectively work on it.

Many commenters here regard React and Vue as "easy", but for many designers it's not easy. There are plenty of talented web designers who are just not interested or not capable of working efficiently with React/Vue.

Our company built an in-house JS component framework that is heavily inspired by React and Vue but that doesn't suffer from the intertwining of disparate web technologies. HTML, CSS and JavaScript stay separate from one another. As a result, our designers can independently iterate on UI without needing to touch a bit of JavaScript or quasi-JavaScript constructs.

If it is so good, why don't you open source it?

Edit: not sure why this is being downvoted, I am genuinely curious.

I'm not arguing that our framework is better than React or Vue -- our framework just works better for us.

We do plan to eventually open source it, but there's a lot of work to be done before a public release: better documentation, better tutorials, remove some constructs specific to our company, etc. We've open sourced some of our internal JS libraries before and it's worked out well -- the contributions submitted and bugs reported by others have been very helpful.

Coupling the CSS and JS and HTML isn't a random design choice. It came out of some very useful styleguides for AngularJS (and other guides too, I'm sure). These guidelines suggest grouping the CSS and HTML and JS together when they are related. It makes a lot of sense in larger applications, but maybe not so much for server-rendered static pages.

There are global styles, and there are styles that are relevant only to a particular component. Hoist styles up to a global (or more general) layer whenever you can, but I really appreciate the fact that I know the important styles I need will be in the same file/folder.

> These guidelines suggest grouping the CSS and HTML and JS together when they are related. It makes a lot of sense in larger applications.

I absolutely agree with you on that.

It's important to point out that grouping and intertwining are two very different things. If you are building a large client-side rendered JavaScript web app, then it is very beneficial to group together the JS, HTML and CSS for a particular component. That's what we do too. However, it is highly debatable whether the JS, HTML, and CSS should be intertwined together (i.e., literally mixed within the same lines) and controlled using framework-specific quasi-JS syntax. As I mentioned above, when you do the latter, you will unquestionably limit the types of developers who are able to work effectively with the code base.

If your team is comprised of a bunch of full stack developers, then you won't face much limitation. But if you're like us and your dev teams include web designers who are JS 'lightweights', then it's a problem.

Reading your other comment from above:

> I hate seeing code syntax mixed with markup syntax. You can end up with hard to parse views (reminds me of PHP and Rails), and abstracts the final HTML structure from the developer.

You hit the nail on the head -- I couldn't agree more.

If your designers aren't programming, they probably don't need to write HTML/CSS either.

Full disclosure: I'm a founder of Pagedraw, which lets designers make UIs as easily as they draw them in a design tool, but are production ready. The designers don't need any code, but programmers can connect it to Javascript data bindings/event handlers as needed.

No one has to write HTML/CSS by hand any more.

There is a reason for all those mistakes in react : it's more complex, it's harder to learn and getting it right. Also the documentation is nowhere as good.

Ease of use is a feature.

Reply on news.ycombinator.com