Live data from Hacker News

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

medium.com

261–270 of 382 posts

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

#261

Earlier quoted context omitted.

have you even tried to use TypeScript on a real project to say something like that ?

He's possibly meaning that if you completely rewrite framework it would lead to something like what happened to Angular when it was rewritten and promptly lost huge number of followers/users?

Typescript is very similar to plain JS. The type annotation is purely optional. I really bought into the optional type annotation pattern when I learned and used Julia for a project. Typescript is also like that. It's extremely unintrusive to use and I'm quite sure such a huge shift as the one that happened in Angular won't happen.

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

#262

I really like a lot of things about Vue. I was apprehensive about using JSX when I first started using React, and I also did not like setState. I think the real issue, though, was that I wasn't thinking functionally. I now rarely write a stateful component, and when I do, it's usually once, for the entire application, or maybe for a few large subtrees if the app is very large. State kept alive by parameters is extrem…

If plain, idiomatic React so great, why does every semi-complex React app end up bringing in a separate state management framework like Redux or MobX? The reason is that while you may be able to break up your HTML into a composable hierarchy of purely-functional components, the actual data and state you need to distribute to them has a structure that is completely unrelated to how its laid out in the DOM. In a comple…

redux isn't a framework, it's a very small library

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

#265
post #66

The ugly in this article isn't really the ugly, it's the good. Nobody's holding you back from writing a simple ES6 module that handles API requests for you. Vue is a view layer, nothing more and nothing less.

To be fair, being used to full frameworks such as angular, you think that you have to do it in some kind of vue-way or react-way. I even made the mistake of using a vue-specific HTTP library when I started. Only later I learned that Vue and react give you the freedom to do whatever you want.

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

#266

I think both React and Vue become difficult when working with complicated UIs. If you're already using Vue or React, these simple articles are not comprehensive enough to be convincing. React and Vue basically manage state the same way, which is 90% of what you'll be doing in these libraries. And just like in React, default state management is insufficient in Vue.

And just like in React, default state management is insufficient in Vue. That hasn't been my experience at all. The medium-sized app I worked on used what is apparently called the "store pattern": a state class with data and methods that mutate it, and components that read the data but only update it by calling its methods. This provides the major benefits of Redux ("functional" components whose only state is purely…

Redux is only a little more work/complexity than the "singleton state class" approach but brings a lot more benefits: timetraveling debugger, serialization of the state (i.e. to localStorage to allow multi-tab operation or resume after tab was closed) and separation of pure HTML/Visual Components versus Container components.

Oftentimes beginner would create just a single React component that references the state - which immediately couples the visual parts of your Application to your data, making it harder to introduce automated testing later on. When using the smart/dumb pattern together with react-redux it is very straightforward to come out with a good architecture, that does not mix ui and business logic/data handling.

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

#267

Earlier quoted context omitted.

If plain, idiomatic React so great, why does every semi-complex React app end up bringing in a separate state management framework like Redux or MobX? The reason is that while you may be able to break up your HTML into a composable hierarchy of purely-functional components, the actual data and state you need to distribute to them has a structure that is completely unrelated to how its laid out in the DOM. In a comple…

> the actual data and state you need to distribute to them has a structure that is completely unrelated to how its laid out in the DOM. It took me many years to realize this. I think very few front end developers understand this. And more problematically: very few framework devs seem to understand it. Stated another way.... Your tree of UI widgets, and Your tree of data which feeds those widgets ... are two orthogona…

I think this is the issue Relay tries to solve. It basically just allows components to declare which part of the data tree they are concerned about without having to have knowledge about the data that other components need.

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

#268

Earlier quoted context omitted.

Having done this in the wild a while ago, it seemed to be hard for most of the other developers to do anything complex with it. You either really got it and then could do wonderful things, or you sorta muddled along with it and it was ok but it was like they were wearing a straitjacket. I made a pivot table control out of it, with almost all the logic inside the XLST, it was amazingly fast compared to IE6's javascrip…

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 on some IE only functionality, some sort of VBScript controls you could embed in IE that I forget the name. They dropped support for them in IE8 or 9. The app was otherwise excellent, basically a sort of dropbox + basecamp for the construction industry before dropbox + basecamp were even made, users loved it. The founding developer was the best developer I have ever known (his quirk was that he'd often forget to rename his functions after prototyping something so a lot of his methods were called Something or Thing or Something2 and we'd have to rename them later to make it clear what they did).

We had a SQL helper that would allow you to write XPath in the SELECT names something like this (I have totally forgotten xpath by now, but hopefully you get the jist):

    SELECT c.CompanyId [@companyId], c.Name [@companyName], 
      o.OrderId [/orders/order/@orderId], o.Name [/orders/order/@name], o.Quantity [/orders/order/quantity]
    FROM Orders o
    JOIN Company c ON o.CompanyId = c.CompanyId
    ORDER BY c.CompanyId
And it would spit out appropriately nested and structured XML like:

    
      
        
          
            1
          
          
            1
          
        
      
      
        ..etc
       
    
     
It was actually pretty nifty, you only got exactly the data you needed for the page, but meant often our business logic was in SQL statements. 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.

Because you had the XSLT on the page, you could make it dynamic, just post back for the new XML on a drop-down change, button-click, etc.

Another story from there is that they made their own version of jquery just before jquery rose to prominence. It was a nightmare to debug, that fully got me onboard the jquery train.

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

#269

It is just my feeling that Vue.js is almost like Ember.js, the only differences that Ember.js is more matured?

VueJS has a lower API surface than Ember: you just have components. Not a specific type of object for your model, and the a controller on the side, and specific methods, etc.

You have one component with data. You may bind it do a template. You insert it in the DOM, or in another component, and if the data changes, everything rerender automatically.

That's it. There is nothing more to it.

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

#270
post #108

I can vouch for the author's points on the good parts of vue.js. We've built our single page application (SPA) web app with vue.js and are very pleased with the results -- https://checkoutclip.com . We were able overcome most of the stumbling blocks by looking up https://vuejs.org/v2/guide/ , https://github.com/vuejs/vue/issues and https://forum.vuejs.org . For server side rendered (SSR) pages, we're using nuxt.js, w…

Five (5) megabytes of JavaScript for a basic brochure site... I assume 99.9% of that is only necessary after signing up and signing in, not while unfortunately viewing the page on a less-than-flagship mobile device and metered data plan?

Not to mention the images. The home page background image alone is 600ko ! More than the entire HTML.

Saving the site on the hard drive gives me a wooping 10Mo for a home page. with a menu, a few pictures and some text.

This is insane.

Post reply on HN