<h5 dir="auto">Description of the problem</h5>
<p dir="auto">When using webpack and babel  in compiled code I see a lot of duplicated code mostly because of inconsistent import paths, so some modules are imported more than once.<br>
<a target="_blank" rel="noopener noreferrer nofollow" href="https://user-images.githubusercontent.com/20562545/83895807-7f6a0480-a753-11ea-986a-1427cbe278b5.png"><img src="https://user-images.githubusercontent.com/20562545/83895807-7f6a0480-a753-11ea-986a-1427cbe278b5.png" alt="obraz" style="max-width: 100%;"></a><br>
For eg. <code class="notranslate">Matrix4</code> is imported twice and it takes a lot of space. I'll investigate it further, it may be mainly problem with loaders I took from examples. Because some of them import directly modules (how it should be done to minify output bundle) and some import the modules from <code class="notranslate">src/three.js</code> what causes importing everything.<br>
These are all three imports in my project:<br>
<a target="_blank" rel="noopener noreferrer nofollow" href="https://user-images.githubusercontent.com/20562545/83897427-e1c40480-a755-11ea-8c7e-63a7c34fb3e4.png"><img src="https://user-images.githubusercontent.com/20562545/83897427-e1c40480-a755-11ea-8c7e-63a7c34fb3e4.png" alt="obraz" style="max-width: 100%;"></a></p>
<h5 dir="auto">Three.js version</h5>
<ul class="contains-task-list">
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox" checked=""> Dev</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox" checked=""> r117</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox" checked=""> ...</li>
</ul>
<h5 dir="auto">Browser</h5>
<ul class="contains-task-list">
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox" checked=""> All of them</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> Chrome</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> Firefox</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> Internet Explorer</li>
</ul>
<h5 dir="auto">OS</h5>
<ul class="contains-task-list">
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox" checked=""> All of them</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> Windows</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> macOS</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> Linux</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> Android</li>
<li class="task-list-item"><input type="checkbox" id="" disabled="" class="task-list-item-checkbox"> iOS</li>
</ul>
<p dir="auto">This is an interest query for a PR.</p>
<p dir="auto">Basic idea: The program specifies the data of interest and the renderer feeds it - no exceptions.</p>
<p dir="auto">Consequences: -1000 LOC or more, easier to maintain/extend renderer, no more obscure updating bugs in the (then no longer) hard to trace interna, more good stuff (I leave it an exercise to the attentive reader).</p>
<p dir="auto">Program inputs would specify a data source and a property name.</p>
<p dir="auto">Examples for data sources are:</p>
<ul dir="auto">
<li><code class="notranslate">material</code></li>
<li><code class="notranslate">object</code></li>
<li><code class="notranslate">camera</code></li>
<li><code class="notranslate">renderState</code> (I invented this one for all the free-floating stuff currently in local variables)</li>
</ul>
<p dir="auto">Typical properties for each of them:</p>
<ul dir="auto">
<li><code class="notranslate">map</code></li>
<li><code class="notranslate">receiveShadow</code></li>
<li><code class="notranslate">projectionMatrix</code></li>
<li><code class="notranslate">fog</code></li>
</ul>
<p dir="auto">These bindings exist right now - they are hard-coded in the renderer.</p>
<p dir="auto">Moving them into the program description, the renderer can process these bindings in a loop. More importantly, the data dependencies can be resolved on a by-case basis (there are eight, as detailed below), instead by hard-coded binding (there are dozens, and piling up with every new feature that is being added).</p>
<p dir="auto">There exist two fundamental kinds of inputs: Compile time inputs, currently implemented via <code class="notranslate">#define</code>s emitted into the GLSL source, and run time inputs; <code class="notranslate">uniform</code>s in case of GLSL (note that a software renderer may very well create and parametrize JavaScript functions by the same mechanism).</p>
<p dir="auto">A distinct case exists for every input type per data source = 8 cases. Some of them are currently not handled correctly, but I'm confident that I can make it happen.</p>
<p dir="auto">There is currently a large amount of redundant code that just pumps data through the renderer. So how about teaching the renderer how to pump data (in general, once and for all) and have it scale?!  Since built-in materials have a fixed program, which then knows exactly what it wants from the material (and the other data sources), all built-in stuff can also be removed - it would live on in very much condensed form in the descriptions of the built-in programs.</p>
<p dir="auto">I have an implementation sketched out, but I wouldn't want to waste my time coding it down without sufficient interest in merging it. Please let me know what you think!</p>