Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Vue.js vs. React

vuejs.org

Post reply on HN
Print view View original

421–430 of 486 posts

Re: Vue.js vs. React

#421

Post by meredydd »

unclebucknasty wrote: post #270
thomasDE wrote: post #196

Earlier quoted context omitted.

> It's like writing shitty PHP code without templates. For me, it's the other way around. I feel like you can still separate the logic and markup, but instead of the template engine syntax you can just JavaScript. From the top of my head, I can at least remember six template engines' syntax I've learned: Smarty (PHP), Mustache, Blade (PHP), EJS, Angular and another custom template engine. When I tried React I was so…

> I can at least remember six template engines' syntax I've learned... TBH, in 2017, I'm not sure why we're still hand-generating HTML with any template language. Instead, I'd really like to see a framework that gets away from the idea of HTML templating altogether and presents a true component/properties model on top of a canvas with flexible, property-driven layout options. I think the intense UI-demands of progres…

This is exactly what we're aiming for with https://anvil.works.

We have a components+properties model, driven in Python, which gets translated to HTML+JS+CSS. We also have a visual editor, and abstractions over a bunch of the client-server stuff that's typically icky on the Web.

The challenge of such a system is that the web platform is so huge and sprawling, and constantly growing - and all of it's written in JS/HTML. So we've made the pragmatic choice to prioritise usability by non-web developers, and open an "escape hatch" for doing layout etc in HTML if you really need to. But most of our users don't need it, and we're constantly working to extend the boundary of what you can do with simple properties and components.

Re: Vue.js vs. React

#422

Post by thecrazyone »

christilut wrote: post #272
a13n wrote: post #46

You'll see quotes in this thread like "The demand for both React and Vue.js is growing tremendously" thrown around. It's good to check out npm install stats to get an unopinionated comparison. https://npm-stat.com/charts.html?package=react&package=vue&p... In reality, React is downloaded roughly 4-5x more than angular and 7-8x more than Vue. In August so far, React has 75% market share among these three libs. Interes…

NPM stats are not representative at all because for every big project there are tons of NPM downloads. For every branch, every deploy, every pull request. This grows exponentially. Just like Github stars arent representative because only (active) Github users would add a star and when a project has critical mass, the amount of actual users will no longer correlate to the amount of stars. Anyway, I don't think there i…

Google trends are particularly difficult for this case because angular (the library) is not a "topic" there. React however is, though.

Stackoverflow tags comparison here: http://imgur.com/a/O3mSB

The tool used is here: http://data.stackexchange.com/stackoverflow/query/201360/que...

I felt happy looking at this. Angular has everything (the complete package of router, speed, and all the components you need), and was surprised why react was more popular

Re: Vue.js vs. React

#423

Post by ergo14 »

kevmo314 wrote: post #364
ergo14 wrote: post #256

Earlier quoted context omitted.

Not really (I'm not even sure of a feature of "what" would it be?)- it is not like you have to use any of that - you could make same criticism for NPM, pypi etc. Webcomponents.org is just a repository, nothing more. If you want quality then you just use components backed by reputable authors - I guess that is the universal rule for development in general.

That's sort of my point. Having ten different implementations of, for example, a data table, each using its own variant of what button template it prefers seems like exactly the kind of hole npm dug itself into. That doesn't seem very desirable for a UI framework that is shipped to clients and demands polish. Sure, you don't have to use it, but it's the main selling point of polymer. It seems nice in theory but npm a…

Polymer is NOT UI framework - its "jquery for webcomponents". Companies like Google, General Electric or Vaadin release their own component catalogs with elements - if you want consistency you use that.

But I do agree that too much fragmentation can be a problem.

Re: Vue.js vs. React

#424

Post by ergo14 »

jacquesc wrote: post #343
ergo14 wrote: post #104

Another option that is interesting right now is Polymer 2.x if you haven't tried it recently, give it a shot. https://vuejs.org/v2/guide/comparison.html#Polymer There are some similarities shared between polymer and react/vue (personally only used react and angular 1.x before). I've built applications with it using polyfills and things worked just fine with legacy applications on IE10 + jquery interacting with web co…

I used Polymer 2 to build a couple of highly used internal web components recently. And I'm currently in the process of ripping it all out. Why? It's not technically Polymer's fault, but the performance and stability on iOS and Safari are complete crap. Often crashes the browser on both desktop and mobile. Also, the Shadow DOM is one concept that I liked in theory and hated in practice. Made it very difficult to do v…

I got into same problem you had - the trick is to have view/parent components not use Shadow DOM - then you can use normal css styling, or alternatively prepare a `shared-styles` file that will contain styles shared across elements.

IMO having everything inside Shadow DOM is an anti-pattern.

I use my own pipeline based on gulp so I don't know much about polymer bundler, webpack support was recently added though, I haven't used it yet.

Re: Vue.js vs. React

#425

Post by gcoda »

vladimir-y wrote: post #359
gcoda wrote: post #352

Earlier quoted context omitted.

Also you can do with just JavaScript. With render-function. h('ul', [ h('li', 'one'), h('li', 'two') ]) And use native array methods instead of v-for v-if and filtering data with component methods

> With render-function. This is even worse as for me. Generally the JSX/React.createElement approach itself and the fact that many people like the idea make me cry. Do people like it just because it's given by FB?

This thread is about 'yet another templating engine'. With Vue you can use JSX or even without any templates.

Sometimes it might be useful, for small components,something like

   render: this.menu.sort().map(item=>h('li', item.title))
But i am using Vue with Pug and Stylus, i am fine with it.

Re: Vue.js vs. React

#426

Post by wdb »

pier25 wrote: post #232
peller wrote: post #203

Earlier quoted context omitted.

I'm not sure I follow. To use the basic example from the link, as opposed to this: const listItems = numbers.map((number) => {number} ); return ( {listItems} ); What's wrong with looping this way?: return ( {numbers.map((num, i) => {num} )} )

> What's wrong with looping this way? The problem IMO is that it's harder to read and write than: {{num}} That's Vue's syntax, but any other templating language is more readable to me than JSX.

Yes, this much easier to read. Only `v-for` is a bit of a black box so you need to find it's implementation in the Vue code to find out what's exactly happening

Re: Vue.js vs. React

#427

Post by thecrazyone »

Bahamut wrote: post #194
eibrahim wrote: post #176

Earlier quoted context omitted.

I have been building web apps for 19+ years. I like many of the frameworks out there but for some reason I HATE React. I think JSX is a huge turnoff for me. I just can't get past html in javascript. It feels wrong. With that said, there are so many VERY smart people embracing React, so I am always questioning my "hate". Maybe one day I will change my mind. I haven't use Vue but watched/read about it and seems very co…

Interestingly, I had recently joined a team that was using Ember, and we found that Ember hampered our productivity. We switched to React and was able to rebuild 4 months of Ember work in about 3 weeks of work in React (not sure how many developers were working on the Ember app originally, but it was mainly 2 of us who built the React app), including requisite tests. I’m of the opinion that Angular is much better tha…

Very well put. This has helped me crystallize my own opinions about react.

There's something very unlikeable (to me) about basic things like a router not being in the library (or should I say framework) I'm choosing.

I like the way how you articulate your thoughts about keeping dislikes aside and focusing on architectural issues more.

Re: Vue.js vs. React

#428

Post by tripzilch »

twhb wrote: post #324
Bahamut wrote: post #198

Earlier quoted context omitted.

To be fair, JSX has its own idiosyncracies too for templating, such as className, htmlFor, and the obnoxious attribute name for dynamically inserted html. It is not immune to the criticism that it requires learning.

Those names have nothing to do with JSX or React, they're the actual properties you're setting. JS properties don't map 1:1 to HTML attributes: while for example the "src" attribute is controlled using the "src" property, the "for" attribute is controlled using the "htmlFor" property, and the "class" attribute with the "className" property. All React is doing is setting the properties you tell it to. (The reason for…

ah so you only need to memorise the list of js "reserved" keywords and it's intuitive as a banana :)

mistakes were made. then copied, repeated and finally, standardised :)

Re: Vue.js vs. React

#429

Post by tigershark »

infensus wrote: post #408
tigershark wrote: post #387

Earlier quoted context omitted.

I cannot really understand how today mixing logic and presentation in JSX is considered a good thing. The first principle when writing complex systems should be to completely separate the logic from the presentation layer. Nowadays people seem happy with intermingled monstrosities like the one shown in the JSX code upstream.

Because you don't really understand separation of concerns

I think I understand it quite well having worked for more than a decade on complex systems. I can't say the same for you if you think that putting some logic in the presentation layer like the example above is a good thing. I would always transform my domain in the model object while the presentation layer should only present the transformed model. Using a map function directly in JSX is a sure recipe for disaster in a complex system. But I seriously doubt that you can understand this looking at your answer.

Re: Vue.js vs. React

#430

Post by tripzilch »

twhb wrote: post #393
tshaddox wrote: post #334

Earlier quoted context omitted.

I agree. Those examples have nothing to do with learning a new template syntax, it's simply the API of React.Component. Granted, there is still some syntax you need to learn for JSX, but it's very little. If you already know HTML's syntax, the only new things I can think of are the curly braces for using JS expressions as prop values (you also need to know what a JS expression is, lest you try to use an if statement)…

I think you misunderstand. The names are unrelated to React as well, they are native. Defined by the same standards bodies that define JavaScript itself, implemented by the browsers themselves. On a blank HTML page that includes neither React nor anything else, the line `document.body.className = "foo";` sets the body's class to "foo". (And `document.body.class = "foo";` does not.) All JSX is doing is transforming `…

not quite, the list of reserved keywords was made up by the committee that designed the first version of ecmascript in 10 days (or however the exact story goes).

many years later, the workarounds like class -> className were designed by whatever party exerted most control over the JS DOM API (which is not really part of "Javascript itself") at the time, and who also brought you inconsistent camelcasing such as "onclick" ...

it's neither quite "native", nor is "defined by the same standards bodies" much of a sign of good design or worthy of copying.

feels more like if someone were to build, say, a modern high perf numerical library that includes necessary workarounds tributed to the eax/ax/ah/al peculiarities of x86 assembly.

Post reply on HN