It would be kind of nice if you could import modules directly from HTTP sources, like Go. For example: import _ from package 'github.com/lodash/lodash/tree/4.8.2'; import $ from package 'jquery.com/version/2.2.0'; Your browser would make the OOB requests and cache the results in a shared directory, which any JS code that's running locally can use. This way, HTTP requests for 3rd-party components shared across website…
Such style of dependency declaration creates unnecessary dependencies on remote sites, which are hard to fix when dependency is broken.
That's essentially what people are doing already with script tags, except they're not declaring their dependencies anywhere.
The referenced pull request for removing the s ( https://github.com/facebook/react/pull/5753 ) is terrific - a real paragon of open-source professionalism.
+1 to this. High-quality code from @mwiencek right out of the gate, and he was super responsive to my comments when I asked for changes. We're really grateful for the contribution.
That list of patents reads like an Onion article. Is there a joke I'm missing here?
Did you also read the patent's text, or just their title and high-level description?
Even the text of some are pretty much as expected. It seems that they have a patent on single page applications (SPAs) to-a-T [1], elaborating that an application may use mechanisms like XHR and append an identifier to the fragment portion of the URL to keep history.
Even if I subscribed to the idea that this was without prior art on the web in 2009, equivalent functionality already existed in desktop applications. To claim that it is a novel invention because it now works on a web page is disheartening. It's exactly this kind of behavior--claiming new ownership based on each abstraction--that leads to restrictions in some countries on patents which can only exist in software.
+1 to this. High-quality code from @mwiencek right out of the gate, and he was super responsive to my comments when I asked for changes. We're really grateful for the contribution.
Where should I start if I want to contribute ?
There is a tag on some Github issues "good first bug" that should be a good start.
When React is big pretty much all their selling points go out the window. I strongly disagree. If React's API were to get all big and complicated, that would be a concern. The tight scope and clean interface are definitely selling points for React compared to many larger (in scope and interface) frameworks and rendering libraries. But I really don't care about the file size, as it's far too small to be anything but n…
Additionally, React is intended for highly complex, highly interactive applications , time-to-content is less important than on, say, a news reader. It might take 2 or 3 seconds to get the first page, but once you're there your interactions will be quick. Even if you do code splitting, well-bundled code will have a "commons" chunk, so fetching a new page won't redownload React and other large libraries.
Finally...had to go so many comments down to find someone making a logical point. People will complain about anything. As someone who has made a massive app with React, well over 1000 components, people literally complain about a 43kb gripped file size... Most likely none of these people have built a large application with React and use it for stuff that a static site would be good for. Then they complain about loading time and rendering time... Also, on an app people ACTUALLY use and often...the files are cached anyway. The front/web/JS doesn't have a fatigue problem...it has a chronic bitching for no reason problem. Reacts benefits from a declarative api and such far out weigh file size...the people who complain about file size don't understand that and never will...again...probably because they haven't written anything used in production by real users ever. /rant
Just out of curiosity, why do you only consider gzipped size when determining bloat? Transmission size/time isn't the only factor, there's also the time it takes the JS engine to process the code. 43k gzipped is okay for the transmission, but the engine is still parsing/processing the unpacked version, no? 145k minified for a foundational library is not insignificant. jQuery 3.0 minified as a reference is ~86k.
You're not wrong, it's just that the time it takes to transfer something across a network is usually slower and a lot less deterministic than processing something locally on your machine. While I'm pretty sure it takes longer to evaluate more code than less code, I would imagine that the time differential is negligible compared to the time savings you get from gzipping JS/CSS assets for transmission over a network. O…
If you're aiming for a really snappy app, and you've made sure everything is fully cached, in a ServiceWorker even for totally instant loading, then JS parse/evaluation time becomes significant.
Just out of curiosity, why do you only consider gzipped size when determining bloat? Transmission size/time isn't the only factor, there's also the time it takes the JS engine to process the code. 43k gzipped is okay for the transmission, but the engine is still parsing/processing the unpacked version, no? 145k minified for a foundational library is not insignificant. jQuery 3.0 minified as a reference is ~86k.
Couldn't browsers keep a map of js-file-hash to cached AST?
It's not just parsing, it's evaluating all the code statement by statement, and the result of that is hard to cache.
It would be kind of nice if you could import modules directly from HTTP sources, like Go. For example: import _ from package 'github.com/lodash/lodash/tree/4.8.2'; import $ from package 'jquery.com/version/2.2.0'; Your browser would make the OOB requests and cache the results in a shared directory, which any JS code that's running locally can use. This way, HTTP requests for 3rd-party components shared across website…
Better idea would be to reference it via cryptographic signature. Then you could host your own copy of lodash for example, but still benefit if a client already has it downloaded from a different site.
I think it suffers from the same problem as other asset caching. Think of all the sites you visit and how much JS they load. 1000 websites with 1MB of JS will hit 1GB of storage.
1gb isn't huge on the desktop, especially if the cache expired LRU.
I don't think any of this concerns desktops anyway.