6 ms·

Vuejs is adding it's own tags to html like if and for. Which requires another DSL to learn when i use simple js(not advanced js) in react. Which leads me questi

Vuejs is adding it's own tags to html like if and for. Which requires another DSL to learn when i use simple js(not advanced js) in react. Which leads me question if they are other tags to be learn to simply display components. I also like my components to be tightly coupled. Having a template just for a single component is not useful I learnt that from my backbone js experience. Declarative syntax is very good win for reactjs. Most can eaily understand the component code. It requires few basic life cycle to be learnt rest is just JavaScript.

unculture 10y ago
You can drop down to JSX or plain JS render functions with Vue if you like, but JSX (which brings with it all the potential complexity of JS) is harder for many people to understand. The constraints of a (very!) simple templating DSL make things easier to read in the long run.
- hesarenu 10y ago
  For me it's easier to understand the lifecycle then to learn methods to simply do a boolean check or loops. In that way vuejs is more complex.
arnorhs 10y ago
>Vuejs is adding it's own tags to html like if and for. Which requires another DSL to learn when i use simple js(not advanced js) in react. I'm not familiar with the concept of simple js vs advanced js in react. But your statement about Vue's tags being its own dsl holds true for jsx as well.
- barrkel 10y ago
  JSX doesn't have control flow. Therein lies all the difference. Javascript's void-typed statements are a problem, though.
  - Touche 10y ago
    JSX has do expressions, which don't exist in JavaScript, so it's a DSL.
    - magic_quotes 10y ago
      No, it doesn't have do expressions.
    - barrkel 10y ago
      As far as I'm concerned, a language doesn't need control flow, much less Turing completeness, to be a DSL. I don't deny that JSX is a DSL. But when an embedded template language grows control flow, it creates two different ways to do things. The outer language has control flow, and the DSL. The choices increase complexity. TMTOWTDI is not actually a great idea. (AFAIK JSX only has 'do' by way of Babel. But it's just syntax sugar for creating a function and calling it. So you can get your control flow that way; but it'll be Javascript control flow.)
drieddust 10y ago
This might be a viable alternative for companies who don't want to agree to React's licensing terms[1]. They also claim significant performance improvements over React. On the flip side Native rendering will require learning yet another framework[2]. EDIT: You are not limited to using the templates, JSX is also an option[3]. [1] https://news.ycombinator.com/item?id=11270213 https://news.ycombinator.com/item?id=11270213 [2] https://alibaba.github.io/weex/ https://alibaba.github.io/weex/ [3] https://youtu.be/pBBSp_iIiVM?t=721 https://youtu.be/pBBSp_iIiVM?t=721
- Lazare 10y ago
  > This might be a viable alternative for companies who don't want to agree to React's licensing terms[1]. The concern over React's licensing terms is that: 1) Facebook might have a patent on some aspect of React (such as the virtual DOM). 2) You might get into an unrelated patent dispute with Facebook. 3) This would allow Facebook to terminate the patent grant. 4) A court might hold that the implicit patent grant usually assumed to be in the BSD license was superceded by the explicit patent grant. 5) Facebook can now sue you over your violation of their virtual DOM patent. That's a fairly tenuous chain of events, but sure, it's possible. So let's say instead you pick Vue. Assuming Facebook does have that virtual DOM patent: 1) Facebook can sue you over your violation of their virtual DOM patent (since Vue also uses a virtual DOM). That doesn't really seem better? Actually, it seems much much worse! Of course, I have no reason to think Facebook has any such patents, and if they don't, then the entire discussion is hypothetical. But still, it is interesting to try and figure out what patent they might hypothetically have which applies to React but clearly not to Vue or other similar framework...
papaf 10y ago
I also like my components to be tightly coupled. Ah Javascript programmers, you are a source of constant entertainment: https://en.wikipedia.org/wiki/Loose_coupling
- hesarenu 10y ago
  Not familiar with reactjs? You need to have loosely coupled tight components.
  - walterstucco 10y ago
    mixed with something looking like HTML that is NOT HTML. I love React it's the first js framework that doesn't make me wanna puke, but Jsx it's just the iPhone of template languages. It's fine and eveeybody understand it but it's far from great
- girvo 10y ago
  While I saw that comment coming a mile off, "tight coupling" of your components to their templates is not quite the same thing as tightly coupling completely seperate classes with completely different datasets and responsibilities.
- barrkel 10y ago
  When a component only ever has one template that defines its markup, and the template is only ever used by a single component, and the template needs to change when the component changes, and the component needs to change when the template changes: if these are all true (and they often are for UI components), then there's little to no upside to separating them physically or linguistically.
- fbonetti 10y ago
  OP did not mean "tightly coupled" in the traditional OO sense. They meant that they prefer their presentation to be coupled with their logic, which is how React components work.
vladimir-y 10y ago
> I also like my components to be tightly coupled. It makes project not maintainable. So using plain JS is not an option for the large long term projects.
- hesarenu 10y ago
  I am working on a multiple large reactjs project for more then a year. You need to think in terms of components.
  - vladimir-y 10y ago
    > You need to think in terms of components. reply Why do you think I need to think in terms of components? I'd say you need to see a bigger picture not limiting yourself by only components approach. Components/modules is an essential thing of any complex project in general, ie not specifically related to the web development, but that's not enough. Try to realize that for example using praised by hipsters mixins for inheritance makes it very complicated to track down from where things came into the final object.
    - hesarenu 10y ago
      Think in terms of components. Design small components which would be used by larger components. As I said I am already using the approach. If you could not then maybe you need a better architecture. Components are just one part. State management is another.

unculture 10y ago

You can drop down to JSX or plain JS render functions with Vue if you like, but JSX (which brings with it all the potential complexity of JS) is harder for many people to understand. The constraints of a (very!) simple templating DSL make things easier to read in the long run.

hesarenu 10y ago
For me it's easier to understand the lifecycle then to learn methods to simply do a boolean check or loops. In that way vuejs is more complex.

arnorhs 10y ago

>Vuejs is adding it's own tags to html like if and for. Which requires another DSL to learn when i use simple js(not advanced js) in react. I'm not familiar with the concept of simple js vs advanced js in react. But your statement about Vue's tags being its own dsl holds true for jsx as well.

barrkel 10y ago
JSX doesn't have control flow. Therein lies all the difference. Javascript's void-typed statements are a problem, though.
- Touche 10y ago
  JSX has do expressions, which don't exist in JavaScript, so it's a DSL.
  - magic_quotes 10y ago
    No, it doesn't have do expressions.
  - barrkel 10y ago
    As far as I'm concerned, a language doesn't need control flow, much less Turing completeness, to be a DSL. I don't deny that JSX is a DSL. But when an embedded template language grows control flow, it creates two different ways to do things. The outer language has control flow, and the DSL. The choices increase complexity. TMTOWTDI is not actually a great idea. (AFAIK JSX only has 'do' by way of Babel. But it's just syntax sugar for creating a function and calling it. So you can get your control flow that way; but it'll be Javascript control flow.)

drieddust 10y ago

This might be a viable alternative for companies who don't want to agree to React's licensing terms[1]. They also claim significant performance improvements over React. On the flip side Native rendering will require learning yet another framework[2]. EDIT: You are not limited to using the templates, JSX is also an option[3]. [1] https://news.ycombinator.com/item?id=11270213 https://news.ycombinator.com/item?id=11270213 [2] https://alibaba.github.io/weex/ https://alibaba.github.io/weex/ [3] https://youtu.be/pBBSp_iIiVM?t=721 https://youtu.be/pBBSp_iIiVM?t=721

Lazare 10y ago
> This might be a viable alternative for companies who don't want to agree to React's licensing terms[1]. The concern over React's licensing terms is that: 1) Facebook might have a patent on some aspect of React (such as the virtual DOM). 2) You might get into an unrelated patent dispute with Facebook. 3) This would allow Facebook to terminate the patent grant. 4) A court might hold that the implicit patent grant usually assumed to be in the BSD license was superceded by the explicit patent grant. 5) Facebook can now sue you over your violation of their virtual DOM patent. That's a fairly tenuous chain of events, but sure, it's possible. So let's say instead you pick Vue. Assuming Facebook does have that virtual DOM patent: 1) Facebook can sue you over your violation of their virtual DOM patent (since Vue also uses a virtual DOM). That doesn't really seem better? Actually, it seems much much worse! Of course, I have no reason to think Facebook has any such patents, and if they don't, then the entire discussion is hypothetical. But still, it is interesting to try and figure out what patent they might hypothetically have which applies to React but clearly not to Vue or other similar framework...

papaf 10y ago

I also like my components to be tightly coupled. Ah Javascript programmers, you are a source of constant entertainment: https://en.wikipedia.org/wiki/Loose_coupling

hesarenu 10y ago
Not familiar with reactjs? You need to have loosely coupled tight components.
- walterstucco 10y ago
  mixed with something looking like HTML that is NOT HTML. I love React it's the first js framework that doesn't make me wanna puke, but Jsx it's just the iPhone of template languages. It's fine and eveeybody understand it but it's far from great
girvo 10y ago
While I saw that comment coming a mile off, "tight coupling" of your components to their templates is not quite the same thing as tightly coupling completely seperate classes with completely different datasets and responsibilities.
barrkel 10y ago
When a component only ever has one template that defines its markup, and the template is only ever used by a single component, and the template needs to change when the component changes, and the component needs to change when the template changes: if these are all true (and they often are for UI components), then there's little to no upside to separating them physically or linguistically.
fbonetti 10y ago
OP did not mean "tightly coupled" in the traditional OO sense. They meant that they prefer their presentation to be coupled with their logic, which is how React components work.

vladimir-y 10y ago

> I also like my components to be tightly coupled. It makes project not maintainable. So using plain JS is not an option for the large long term projects.

hesarenu 10y ago
I am working on a multiple large reactjs project for more then a year. You need to think in terms of components.
- vladimir-y 10y ago
  > You need to think in terms of components. reply Why do you think I need to think in terms of components? I'd say you need to see a bigger picture not limiting yourself by only components approach. Components/modules is an essential thing of any complex project in general, ie not specifically related to the web development, but that's not enough. Try to realize that for example using praised by hipsters mixins for inheritance makes it very complicated to track down from where things came into the final object.
  - hesarenu 10y ago
    Think in terms of components. Design small components which would be used by larger components. As I said I am already using the approach. If you could not then maybe you need a better architecture. Components are just one part. State management is another.