Hacker News new | ask | show | jobs
by porker 3667 days ago
Yup.

> If yes, why not use "vanilla" js?

I can't answer that, but I can answer "Why not use $Framework?"

My current project (a large admin system) is crying out for the more complex parts of the admin UI to be built in React, Angular etc. The problem is it's an all-or-nothing situation.

When picking up a new technology I want to add a little bit to the current project, a bit more to the next, and so on. Progressive Enhancement for the developer. jQuery lets me do that; the frameworks don't.

I have used KnockoutJS in 2 locations in this project; both for a single component on a page which needed to be very dynamic. I have been impressed that it doesn't try and take over, and lets me think of enhancing the experience (and my skills) one component at a time.

3 comments

Vue.js is a really great way to add progressive enhancement. Can add it to a single page or even a single element on a page and not effect the rest of the page.
Does Vue.JS cover all the features of React and handlebars and can just be used for small parts of the application?
Thanks, I keep meaning to play with Vue.js. You've spurred me on.
Why is it all or nothing?

We've been replacing certain parts of our vanilla js application with small React apps and it's worked brilliantly. There is a really good talk by Ryan Florence where he replaces backbone components (i think) with React components.

Yes, it's not too hard to replace one at a time. We run an extremely feature rich browser client application and have slowly been dropping in independent react components to replace legacy code as necessary.
> Why is it all or nothing?

Erm, because that's the impression I've got from the tutorials and demos. I guess a "Add $Framework to a bit of your app" isnt' sexy: the ones I've seen add their own routing and focus on SPAs. Rather than "Here's some incredibly complicated information to display, and we need to be fairly interactive over it (and how other data on the page affects it)".

Would it work if you didn't have a vanilla JS application but a traditional web app?

You're right that most tutorials dive in with both feet, but this is literally the very first text on https://facebook.github.io/react/

>Lots of people use React as the V in MVC. Since React makes no assumptions about the rest of your technology stack, it's easy to try it out on a small feature in an existing project.

Facebook.com is afaik replacing small more and more small parts with react components
I've seen a traditional server side rendered rails web app try to do this. The traditional pages are nice a usable and fast, and then you hit a page with a react component and you need to wait a second or more for react to boot up, or whatever it does. How do you handle that?
I don't know what you're referring to, if it's an actual case you've seen, or if people talking about React huge size gave you the idea that it behaved like that.

In any case this is an implementation problem. React base is around 30kb after min + gzip, and executing the code should take hundredth of seconds on page load unless you're on a really bad phone.

Maybe you've seen this behavior because of components designed to perform one or several high latency requests before they display data? If that's the case, then it's easily fixable by providing the initial data along with the page, or improve latency by many means.

It is an actual case I've seen, more than once. I didn't debug it, I just removed it. But the initial load and render of react components is not fast. Can you point me to a live site where it is (and serving an initial server side rendered page is cheating).
Every framework out there can be used on a small part of an app at a time.
That's grand, the tutorials and examples gave me the opposite impression (SPAs and own-everything)
They always seem to have an example of being used on a small part of the page, but nobody actually tends to do this and there isn't much in the way of blog posts about it.