Here are the numbers
min+gzip 26k
gzip 90k
original 450+k
And React doesn't have many features in it's documentation. Why is it so big?
I have a feeling that it's the implementation of lightweight DOM. But I want to be sure.
React does quite a bit! The biggest nonobvious part of React is probably the events system -- not only does React implement its own event dispatching and bubbling, it normalizes common events across browsers so that you don't need to worry as much about it. For example, SelectEventPlugin is a built-in event "plugin" which provides an onSelect event which behaves the same way in all browsers.
The virtual DOM implementation does take a decent amount of code as well; a lot of effort is spent on performance optimization, which is why the unminified version includes ReactPerf, which is a tool for measuring rendering performance. In updating the DOM, React also does some convenient things for you like maintaining any input selection and keeping the current scroll position the same.
React also has a few other tricks up its sleeve. One of the coolest is that it fully supports rendering a component to an HTML string even if you don't have a browser environment, so you can send down a page that works even before JS is loaded.
What are you comparing React against? react-15.0.2.min.js is 43k (gzipped), but jQuery is 33k while ember-2.6.0.prod.js is 363k (also gzipped). Obviously these frameworks don't do exactly the same things but they do have a lot of overlap, so I think the comparison is reasonable.
If you're worried about download size, I wouldn't worry too much about JS code contributing to that. Here's an ad which I see on the right side of my Stack Overflow page right now:
Its download size is 95k -- I wouldn't think twice about including an image like that in a page because (even if I was worried about performance) there are usually so many other performance-related things to fix that are more lucrative.
In short, I don't think React is that big, and what size it does have comes from the many small things it does to help you out. You cite React's small API as a reason that React's code should be small, but a better question might be, "How is React's API able to be so simple given all the things it does for you?"
…but that's a totally separate question. :) Hope I answered your question -- happy to expand if I didn't.
A couple of thoughts.. I had some of the same concerns with it's size, but after using it, no joke, I would use it if it was 5MB in size. It's just that good. That said, I did decide to reduce as many dependencies on other libraries as possible. I was using jquery for two things.. ajax and the automatic ajax response and request handling (beforeSend, etc) that would handle when a token was in a response after login, and then make sure every ajax request added it to the Authorization header before sending. I replaced this with a super small simple bit of native javascript. Works great. Also, I was trying to use _underscore. I've replaced it with lodash, which is smaller and faster, although presently I am not using it so may remove it altogether.
Here is one article, of many on google, that I found that has some alternatives using native JS over jquery.
http://www.sitepoint.com/jquery-vs-raw-javascript-1-dom-forms/
Related
We have a database containing HTML code and we are displaying that on a web page using React, but it needs to be parsed.
I initially used html-react-parser but after a code review was asked to use dangerouslySetInnerHtml instead because it doesn't have any dependencies.
I wasn't able to articulate any advantages of using html-react-parser other than it doesn't use dangerouslySetInnerHtml, but is that an advantage and if so why? Does it somehow avoid the dangers or are they just hidden?
Many thanks,
Katie
I've recently been studying this issue for a Headless CMS project I'm working on. From what I understand:
dangerouslySetInnerHtml creates DOM elements outside of ReactDOM.Render() method, so it's not dynamically maintained by the React library. This basically defeats the purpose of using React in the first place (displaying and maintaining virtual DOM).
More concerning, though, is that it's vulnerable to Cross-Site Scripting (XSS) attacks, which is where it gets its name. These are a very common form of attack on the web. You can read about that here: https://reactjs.org/docs/dom-elements.html#dangerouslysetinnerhtml
If you want the app to be less prone to attacks, you'll have to use a sanitization library like DOMPurify for dangerouslySetInnerHtml, so you're likely to have another dependency either way. Once you compile the app for production (npm build) the minimization process makes the codebase extremely compact, and you can do some optimization beforehand with techniques like code-splitting, which makes each section of your page load only if requested, instead of all at once: https://reactjs.org/docs/code-splitting.html
I wouldn't worry too much about a few dependencies, personally - they're a fact of life on the modern web. I've been leaning towards using html-react-parser, but I caveat that by saying I have not investigated whether it reduces XSS vulnerability. However, even if both are vulnerable to XSS attacks, at least html-react-parser introduces the elements through ReactDOM.render() so they don't make the DOM all catty-wompus - that sounds like a recipe for disaster down the road.
I have been using both in my projects and sometimes I find the need to use a Material UI component within a bootstrap component and the UI displays as I would expect. I have been advised though not to use this approach. Is there any reason why since both are using the grid and can be flexed?
I tend to be verbose so I'll put the concise answer up top here:
Conclusion:
Whoever said it was bad to use both might just be expressing their
opinion, in reality saying it's bad to use both really lacks context
in what you're designing. #user3770494 made a very good point- but the
point, while valid and truthy about the build size, it does depend on
the scope of the application. If it's an intraoffice application with
everyone on a fiber network local it'd all be cached in memory
anyways... but (not that you know me) I would not judge you negatively
if you mixed them together-- unless it was for a MAJOR million user
application to run on mobile (an very low devices), desktop, and other
devices around the world requiring real(ish) time updates, and
streaming dynamic content with 10000s of active users at any givin
time 24/7.
In all truth- if it's not life or death-- I'd say use both- and also
do your own. The experience of understanding more then one thing is
better then just "committing to a single solution" for personal
growth.
The rest of this reading is optional - you're welcome :)
I personally have used both in production applications (both together, and independently)... I've also done it all from scratch... (CSS is my least favorite part of job things I do - luckily I have a coworker who is great at it) Here are my thoughts:
Warning: I tend to be verbose.
Disclaimer:
As someone who likes function over form, form is an afterthought that is nit picky for clients to ask about tenuous little changes. I am going to try to leave my opinion on "how each option looks for feels" out of this as much as I can.
Also I'm looking at your question in a current choice I'm making- which is using ReactJS / create-react-app to make "demo" projects for touch screen embeaded systems- so I am going to roll out half a dozen mock programs for demos nothing that really does anytihng exactly (CCscanner, barcode scanner, gps, webcam integration, fun stuff like that). So I'm researching what will be easist for me to just commit to for this "beacuse I'm bored and got a pi3b+board for fun).
Answer:
If you have the time, dedication and resources, there is really
nothing wrong with mixing them together. But you just need to think
about the time/cost/benifit of it. DIY to make the end user happy-
even if you mix them. Totally yourself is remaking the wheel- but you
can always pull in boostrap styles etc.
The inherent risks is that if you use both- make sure you don't "Mix them" to much- because then you will always have issues with trying
to ever do version changes on either one.
I like a lot of MaterialUIs things, but I honestly dislike how a few things look (style wise by default)- functionally I like it better
then bootstrap, but at the same time, I do not like MaterialUIs React
programming style (as a purist who hates CSS But knows how important
it is- having to use !important ever ever ever ... is big big big
nonononononononon) compared to whatever way my coworkers and I use
for conventions. Not saying it's better or worse then my own
preference- but a few things about it really irk me (even if they are
done for good reasons).
Bootstrap has a lot of choices to use for- I like how it looks better, I like how it plays with ReactJS better- but there is
reactstrap vs. react-bootstrap (which is why I found your post trying
to figure which one to use for this demo thing I'm doing).
Most recently (for production projects) I do try to stick just with one but normally I'm making systems that are function over form. So
they don't really care that much about the UI elements, it's about
how to use it not make it pretty. So I stick with using a single one
just to make my job easier- and usally still override styles myself
... if the original styles piss me off. But I do not stick with one
because "It's bad form to use both" I just stick with one for that
reason mentioned above. I'd actually say if bandwidth is not an
issue- it's quality to use both- but only use the parts of them that
you actually use.
(I noticed someone once importing full jQuery when the only thing that they used from it was $.ajax (all be it a lot but still) ... I was like... is that not overkill?!) -- So if you use both and want to keep things slim- just make sure on compilation you're only importing what you're using. Pythonically I'm saying- never use import * from module (however you express that in Javascript as a concept - webpack/gulp/whomever should take care of most of that for you). Assuming you're using ES6/7 style Javascript.
I encountered this scenario recently and opted to use both but for specific tasks. With it being a responsive web app Bootstrap made the most sense to use for the layout and Material UI for the widgets (just my personal preference).
You can definitely use both but you should be aware of the following:
There will be a lot of overlap in offered features unless you take time and effort to manage it by carefully picking elements from each of those libraries. And even then you will face situations where you can't avoid overlap. This basically results in a bigger bundle.
You will have to maintain theming variables for both systems to have a consistent presentation across your app. Even then, there will be situations like where your table checkboxes look different from your form checkboxes because they are from different libraries.
You have to learn and understand both of the systems. It means sometimes it'll be harder to find what's causing a certain bug. You'll also be spending more time deciding which library to use for which component.
Overall, it's more work for you to work with two different systems and a higher chance of things looking inconsistent. That said, mixing in things like a grid system with limited theming might not be too bad.
If possible, I highly encourage you to choose one system and stick with it.
Using both will increase your production js size.
Material Ui and bootstrap both provide components with basic styles like buttons so choose one.
You can use bootsrap grid for structure only or even go with flex.
There are lots of SO questions and blogs on the internet attempting to explain what virtual dom is, but this question is about why this kind of optimisation has to be to implemented in JavaScript/as part of a framework, rather than by the browser itself.
Virtual DOM, as I understand it, is a tree composed of Javascript Objects, with parents/children etc. but without most of the "heavy" features of the real DOM. Frameworks (e.g. React/Vue) respond to changes of model state by creating a virtual DOM from scratch and then do a diff on the last version of their virtual DOM to work out what real DOM to change.
Many of the things I have read, claim that virtual DOM is faster because real DOM has to re-layout (or even re-paint) every time there is a change, but this isn't true - re-layouts are only needed when some piece of JS code explicitly asks for some style/text-flow dependant value (such as a height/width etc.). And presumably most of the frameworks that use virtual DOMs cannot do any better at this - except ensuring developers don't accidentally do it.
Also, at some point recently browsers were considering providing event hooks for DOM-mutation, but that idea has been abandoned, meaning there shouldn't need to be any events fired at the point DOM is mutated.
So my question is, what does that leave in terms of benefits? What extra information, or extra freedom, does the JS framework have that gives it the "logical" power to perform the virtual DOM optimisation?
Virtual DOM is something like a workaround for the current situation. The W3C are working on re-building the DOM and make the current "virtual DOM" native to the browser. But you know how slow this goes - it has to be drafted, talked over, accepted, and then starts the fun part - implementing it in different browsers. They still have issues with CSS3 and flexbox model - every browser has it's own terms and standards for working with those.
And it's the same with the Virtual DOM - they still haven't accepted it to be a cross-browser solution. This will eventually happen in the future, but until then - we use the JS option.
If you follow the JS world - it was pretty much the same with Promises - we got the bluebird and jQuery implementations, but at the end Promises went native and all those libraries and frameworks are no longer needed.
I've been tasked with developing an application for internal use in our company, the end-users being the operators of the call center and their superviser.
There would be therefore be two types of users: operator & supervisor.
The operator view would be purely passive: ability to see their monthly goals (calls taken, calls answered etc) as well as those of their "cell"(group of operators+supervisor) and other "cells" and that's it.
The supervisor one however would be able active: they need to be able to set monthly goals for their subordinates as well as view them.
The application needs to live in the browser, and that browser is...sigh, either IE6 or IE7. So my question is, should I use something client-side like backbone.js, or something server-side like, say, Code Igniter?
I need to be able to develop it in a short time frame and add features as requested.
Any advice is greatly appreciated.
Thanks.
Firstly, IE6 is very old. It is still supported but support will end fairly soon (about a year, I think), so your company needs to have an upgrade plan in place. IE7 has a bit longer to run, but will also fall out of support at some point. Your company must make plans for an upgrade process. And you need to make sure that anything you write today will continue working on upgraded browser versions when they come.
Okay, that aside, today you need to support these browsers.
The first advice I would give is to use jQuery for all your Javascript needs. It is specifically targeted at being compatible with IE6 and above, and it hides a lot of the complexities with cross-browser and old-browser support from the developer, but also works well with newer browsers too.
IE6/7 do have a number of serious bugs and omissions in their Javascript support, but these can generally be worked around. Using jQuery will mean you can forget about most of them.
In the main, I would recommend against using a client-side framework like Backbone. Stick with server-driven simple HTML pages. Maybe a bit of ajax using jQuery, but nothing too much more than that. IE6 and IE7 are very very slow browsers, so the less work you make them do, the happier they'll be. Put too much Javascript on the front end and you could wind up with a system that is too slow to be usable. Also, a lot of modern JS libraries don't support IE6 at all. I'm not sure about Backbone, but even if it works now, you can't be sure that later versions will continue supporting it. (even with jQuery, some developers are starting to push for IE6 to be dropped. I don't think it'll happen just yet though)
Make sure you specify a valid <!DOCTYPE> for all your pages. Without it, IE will drop into quirks mode. This will make it very difficult to upgrade your site to a newer browser later on. There are many valid doctypes, but it doesn't really matter which one you use, as long as it's valid. Therefore, I suggest using the HTML5 doctype, simply because it's valid and it's short and simple: <!DOCTYPE html> -- that's all there is to it.
CSS is where you'll really have some pain if you're used to working with modern browsers. IE6 in particular has terrible CSS support. For IE6/7 CSS compatibility, I recommend using the Quirksmode.org compatibility charts to find out what does and does not work in those browsers.
Finally, make sure you read up on the well known IE6 bugs. There are a lot of them, and they often cause weird and wonderful rendering errors on perfectly valid code. Knowing about them in advance will help you avoid them, and help you recognise them when you (inevitably) hit them.
Hope that helps.
Oh, and good luck -- it sounds like you'll need it! ;-)
Developing websites or web applications for Internet Explorer 6 is possible as long as you do not use things such as HTML5 Javascript functions.
As for the live part, maybe you could use AJAX long polling or something similar. Example: http://techoctave.com/c7/posts/60-simple-long-polling-example-with-javascript-and-jquery
Hope this helps!
which one is better for screen scraping? simple html dom or snoopy ??
i use simple html dom and find it comfortable..
does snoopy has any advantage over simple html dom?
my requirements : if i wanna scrape contents from a page(after login)..
simple html dom is easy but it takes a lotta time to print the results..
Is Snoopy that well known / mature of a package?
If it's not, then all other things being equal, I'd probably go with generic HTML DOM code - especially if the scraping is somewhat simple.
But only you know when your code is starting to get too big, unmanageable, etc., at which point it might be better to look at another tool out there like Snoopy.
(Which, admittedly, I don't have experience with; it's apparently at http://sourceforge.net/projects/snoopy/ for those not familiar with it - "Snoopy is a PHP class that simulates a web browser. It automates the task of retrieving web page content and posting forms, for example.")
The real reason I'm posting, even though I don't know Snoopy per se and thus can't definitively answer your question, is to ask if you've considered using Selenium (http://www.seleniumhq.org/) instead of Snoopy.
Selenium is a fairly well-known testing tool, and it occurred to me that one of the nice things about using that for what you're doing (if you can) is that it has built in tests.
The reason that's good is that screen scraping is kind of an inherently brittle task - if the target site changes something, blam, your scraping fails. So it's kind of a nice design to have an automated scrape/test-that-scraping-worked system.
Something to think about, anyway.
I've stumbled into BeautifulSoup, which is Python-based. I suppose there are a bunch of others too.
Looks like Snoopy is PHP-based, and hence can be run server-side only. Is this what you are really looking for? What are your requirements? Please elaborate on that.