6 ms·

Seeing those quasi-JS expressions in HTML attributes is enough to put me off Vue. I understand why people feel overwhelmed with the whole React/Redux/Router/Sa

Seeing those quasi-JS expressions in HTML attributes is enough to put me off Vue. I understand why people feel overwhelmed with the whole React/Redux/Router/Saga stack but you really don't need most of that when you're just getting started and React itself is quite simple and elegant.

no1youknowz 8y ago
> 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.
- sunilsandhu 8y ago
  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 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.
  - nojvek 8y ago
    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 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.
    - ChristianGeek 8y ago
anonytrary 8y ago
To add, you can get very far without Redux! There's a significant subset of Reacticians who think React + Redux are an inseparable whole, and that setState is evil. I really liked Meteor's approach using live-collections in the browser for handling data. The action/dispatch (or whatever) paradigm that Redux forces upon the user feels slightly over-engineered for the problem it solves, and I think it's a source of additional complexity for new users.
- cageface 8y ago
  Yeah exactly. You can build some fairly complex apps with React alone. Redux itself is also not too hard to understand IMO even if it does add a lot of boilerplate but once you bring in redux-thunk or redux-saga to deal with async actions the learning curve gets very steep. I haven't tried it yet but I'm definitely going to investigate mobx for my next react app.
- abledon 8y ago
  What are some good tutorials to learn building apps without redux (in your opinion)?
  - anonytrary 8y ago
    I'm not sure about specific tutorials, but you could look into MobX, Apollo, Minimongo, and other reactive client-side data stores. I thought Meteor collections had a simple API and I think separating reactive-Minimongo from Meteor might still be an unsolved problem. IIRC there were a few people from React working on it a few years ago.
oatmealsnap 8y ago
I'm the opposite. 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. I think a much nicer way to work with templates is to see your markup with the same structure it will have once rendered, and attributes that describe those elements (just like real HTML attributes). When it comes to accessibility, and creating predictable interactions without elements snapping around, I find it easier to visualize the end result when the markup isn't littered with text that won't be rendered.
- dmitriid 8y ago
  JSX is not markup
  - bmarkovic 8y ago
    JSX is PHP-mix-HTML templates and JSP all over again. Those that fail to learn from history are doomed to relive it.
    - dmitriid 8y ago
      It's not. It's nothing but a `React.createElement` function call. It's a paper-thin XML-like DSL over real unadulterated JavaScript code. HTML-in-PHP wasn't PHP. HTML-in-JSPwasn't Java. JSX in JavaScript is JavaScript. And that is a whole world of difference.

no1youknowz 8y ago

> 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.

sunilsandhu 8y ago
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 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.
- nojvek 8y ago
  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 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.
  - ChristianGeek 8y ago

anonytrary 8y ago

To add, you can get very far without Redux! There's a significant subset of Reacticians who think React + Redux are an inseparable whole, and that setState is evil. I really liked Meteor's approach using live-collections in the browser for handling data. The action/dispatch (or whatever) paradigm that Redux forces upon the user feels slightly over-engineered for the problem it solves, and I think it's a source of additional complexity for new users.

cageface 8y ago
Yeah exactly. You can build some fairly complex apps with React alone. Redux itself is also not too hard to understand IMO even if it does add a lot of boilerplate but once you bring in redux-thunk or redux-saga to deal with async actions the learning curve gets very steep. I haven't tried it yet but I'm definitely going to investigate mobx for my next react app.
abledon 8y ago
What are some good tutorials to learn building apps without redux (in your opinion)?
- anonytrary 8y ago
  I'm not sure about specific tutorials, but you could look into MobX, Apollo, Minimongo, and other reactive client-side data stores. I thought Meteor collections had a simple API and I think separating reactive-Minimongo from Meteor might still be an unsolved problem. IIRC there were a few people from React working on it a few years ago.

oatmealsnap 8y ago

I'm the opposite. 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. I think a much nicer way to work with templates is to see your markup with the same structure it will have once rendered, and attributes that describe those elements (just like real HTML attributes). When it comes to accessibility, and creating predictable interactions without elements snapping around, I find it easier to visualize the end result when the markup isn't littered with text that won't be rendered.

dmitriid 8y ago
JSX is not markup
- bmarkovic 8y ago
  JSX is PHP-mix-HTML templates and JSP all over again. Those that fail to learn from history are doomed to relive it.
  - dmitriid 8y ago
    It's not. It's nothing but a `React.createElement` function call. It's a paper-thin XML-like DSL over real unadulterated JavaScript code. HTML-in-PHP wasn't PHP. HTML-in-JSPwasn't Java. JSX in JavaScript is JavaScript. And that is a whole world of difference.