Back in the day, in the dojotookit we used a combination of feature
detection and a require.js alike module system to build feature-specific
sources. So rather than magic comments with preprocessor meaning, you got
real conditionals in the code that were optimized away given a feature-set
profile at build-time. In practice this was mostly done at a file/module
level though - very similar to what Marcus proposes.
On Wed, Nov 25, 2015 at 1:09 PM, Marcus Cavanaugh <m...@mcav.com> wrote:
> On Wed, Nov 25, 2015 at 12:51 PM, Justin D'Arcangelo <
> jdarcang...@mozilla.com> wrote:
>
>> There are cases where we need to include certain files **at build time**
>> conditionally.
>>
>
> That's a perfect match for the "build-step is a static site generator"
> part. At the file level, the build system can alter paths and resources,
> just like a web server could serve different content for different devices.
> I think most of our existing needs would fit nicely with this approach.
>
> There's an argument to be made for within-file substitutions in some
> cases, such as optimizing HTML includes in "index.html". But I don't think
> we should extend that need to including a full-blown conditional
> preprocessor running through all HTML and JS files.
>
> (forgot reply-all, sorry justin)
>
> On Wed, Nov 25, 2015 at 12:51 PM, Justin D'Arcangelo <
> jdarcang...@mozilla.com> wrote:
>
>> There are cases where we need to include certain files **at build time**
>> conditionally. Of course we should feature-detect at runtime when we can,
>> but there are many instances when we need to branch code paths
>> conditionally when building. Especially when we try to optimize our
>> application bundles and exclude resources that may not be needed for
>> certain devices, we similarly may need to include certain stylesheets,
>> scripts, etc. based on the device profile as well.
>>
>> -Justin
>>
>>
>> On Nov 25, 2015, at 3:36 PM, Marcus Cavanaugh <m...@mcav.com> wrote:
>>
>> Using a conditional preprocessor is an admission that the Web's support
>> for conditionals is not enough. The Web already supports IFDEF:
>>
>> if (window.feature) { }
>>
>> When feature detection isn't enough, hypermedia already has an answer. No
>> need for a module system. Our build system is a glorified static site
>> generator, positioned exceptionally well to write files based on build
>> flags:
>>
>> <script src="thing-for-specific-device.js"></script>
>> <script>
>> Thing.doSomething(); // no feature detection conditionals!
>> </script>
>>
>> Conditional preprocessors turn against many of the web's foundational
>> values (view-source transparency, hypermedia, open-source). The Web's
>> solution is already simple, sufficient, and widely-understood.
>>
>> From a grep of Gaia, IFDEF_FIREFOX_SYNC seems to be the only current use
>> case, which seems like a perfect candidate for a more webby approach. Less
>> magic, more open.
>>
>>
>>
>> On Wed, Nov 25, 2015 at 10:15 AM, Eli Perelman <eperel...@mozilla.com>
>> wrote:
>>
>>> I'd have to agree with the sentiments against C-style pre-processing.
>>> Anything that breaks linting or an IDE's static analysis would make
>>> development a pain.
>>>
>>> Eli Perelman
>>>
>>> On Wed, Nov 25, 2015 at 11:55 AM, Sam Giles <sgi...@mozilla.com> wrote:
>>>
>>>> I was surprised having worked in m-c that Gaia wasn't using the C
>>>> pre-processor fwiw.
>>>>
>>>> But I think the fact it will break syntax is a show stopper - unless we
>>>> pre-process before linting - but the problem is deeper than that, I think
>>>> the approachability of the code base will be affected by this. Not because
>>>> the C pre-processor is obscure, I don't think it is at all, but because the
>>>> syntax is just different to what you might expect. I'd also be worried
>>>> about how easy it is to set up the toolchain for Windows developers.
>>>>
>>>> I don't see what the problem with the third party pre-processor
>>>> proposed is, it at least covers what we already have in a better way and
>>>> despite encasing the conditions in comments, is practically offering the
>>>> same as the C pre-processor–without macros 🙌.
>>>>
>>>> Sam
>>>>
>>>> On Wed, Nov 25, 2015 at 5:31 PM, David Flanagan <dflana...@mozilla.com>
>>>> wrote:
>>>>
>>>>> If there is a pre-processing system that is already familiar to the
>>>>> majority of web developers, I'd buy this argument. But I don't think there
>>>>> is. So most web developers who encounter preprocessing in FirefoxOS will
>>>>> have to learn our system from scratch. If that is true, then I'd favor the
>>>>> solution with 40+ years of use over something that someone just made up
>>>>> and
>>>>> posted on github. And if `#ifdef FOO` scares away contributors then I
>>>>> don't see how `<!-- @ifdef FOO -->` is any less scary! Its not like I'm
>>>>> suggesting we use m4 here.
>>>>>
>>>>> If the argument is that we need a preprocessor that we can run in node
>>>>> without invoking the shell, then maybe we can find a cpp implementation in
>>>>> node.
>>>>>
>>>>> Maybe we want a syntax that uses comments so that the code remains
>>>>> valid even before preprocessing so that linters and other tools don't get
>>>>> confused. That seems like a reason that we need something other than cpp.
>>>>>
>>>>> Greg thinks that we need a preprocessor that can do template expansion
>>>>> and looping. I find that surprising and a little scary, but I don't know
>>>>> what the use case is.
>>>>>
>>>>> Anyway, my point is that the C preprocessor is venerable and well
>>>>> understood by generations of programmers. IT seems to me that any
>>>>> discussion of "what preprocessor should we use" should begin with the
>>>>> question "can we just use cpp?"
>>>>>
>>>>> David
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Nov 25, 2015 at 8:14 AM, Justin D'Arcangelo <
>>>>> jdarcang...@mozilla.com> wrote:
>>>>>
>>>>>> We should use a preprocessor that is familiar to web/JS devs. We're
>>>>>> trying to grow contributors, not scare them away.
>>>>>>
>>>>>> -Justin
>>>>>>
>>>>>>
>>>>>> On Nov 25, 2015, at 11:08 AM, David Flanagan <dflana...@mozilla.com>
>>>>>> wrote:
>>>>>>
>>>>>> Why can't we use the standard C preprocessor (with #if, #ifdef,
>>>>>> #define, and even #include) for this instead of adopting a new
>>>>>> technology?
>>>>>>
>>>>>> David
>>>>>>
>>>>>> P.S. When we do adopt a preprocessor solution, I'm interested to
>>>>>> explore whether I can use it to include unit tests in the same file as
>>>>>> the
>>>>>> code being tested.
>>>>>>
>>>>>> On Tue, Nov 24, 2015 at 9:54 PM, Fred Lin <f...@mozilla.com> wrote:
>>>>>>
>>>>>>> Seems we have kind of common agreement to reuse the third-party
>>>>>>> preprocess library[1].
>>>>>>>
>>>>>>> Francisco has done some experiment port, and found the library has
>>>>>>> some node dependency.
>>>>>>> It also brings the request to have the node based build script.
>>>>>>>
>>>>>>>
>>>>>>> 1. https://github.com/jsoverson/preprocess
>>>>>>> <https://github.com/jsoverson/preprocess>
>>>>>>>
>>>>>>>
>>>>>>> regards
>>>>>>> --
>>>>>>> Fred
>>>>>>>
>>>>>>> On Wed, Nov 18, 2015 at 10:40 PM, Francisco Jordano <
>>>>>>> fjord...@mozilla.com> wrote:
>>>>>>>
>>>>>>>> +1 to this,
>>>>>>>>
>>>>>>>> several reasons to do it:
>>>>>>>>
>>>>>>>> - It support multiple languages (javascript, html, css, c, etc)
>>>>>>>> - You can combine as many options as you want.
>>>>>>>> - The options have value, which could add a complete new set of
>>>>>>>> cases, not just the binary one.
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> f
>>>>>>>>
>>>>>>>> On 18 November 2015 at 14:07, Fred Lin <f...@mozilla.com> wrote:
>>>>>>>>
>>>>>>>>> In Gaia currently we have preprocessor.js[1] that support some
>>>>>>>>> syntax[2] to exclude/include HTML/JS/CSS in build time.
>>>>>>>>>
>>>>>>>>> With this tool, developer can exclude files, code sections from
>>>>>>>>> origin HTML/JS/CSS files to shape the source to fit more kinds of
>>>>>>>>> devices.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> html code....
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> <!--IFDEF_FIREFOX_SYNC
>>>>>>>>> html code section
>>>>>>>>> ENDIF_SAMPLE-->
>>>>>>>>>
>>>>>>>>> The consideration during review is we can't put html related
>>>>>>>>> comments inside of <!-- -->, which make bad patten match and also
>>>>>>>>> make the
>>>>>>>>> editor cry.
>>>>>>>>>
>>>>>>>>> As my experience about other code mangler/optimizer, some of them
>>>>>>>>> support Ruby like start/end syntax, such as:
>>>>>>>>>
>>>>>>>>> <!-- @if NODE_ENV='production' --><script
>>>>>>>>> src="some/production/lib/like/analytics.js"></script><!-- @endif -->
>>>>>>>>>
>>>>>>>>> Which wrap target code section with start comment and end comment,
>>>>>>>>> therefore the origin source is still viewable in plain HTML. May we
>>>>>>>>> have
>>>>>>>>> something similar so we won't left orphan comments in HTML file?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Another thought is since we can use npm modules now (Not 100%
>>>>>>>>> sure), why we don't reuse existing preprocessor[3] and send PR to
>>>>>>>>> them to
>>>>>>>>> leverage efforts from outside talents?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 1.
>>>>>>>>> https://github.com/mozilla-b2g/gaia/blob/master/build/preprocessor.js
>>>>>>>>> 2.
>>>>>>>>> https://github.com/mozilla-b2g/gaia/blob/master/apps/settings/elements/root.html#L140
>>>>>>>>> 3. https://github.com/jsoverson/preprocess
>>>>>>>>>
>>>>>>>>> regards
>>>>>>>>> --
>>>>>>>>> Fred
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> dev-fxos mailing list
>>>>>>> dev-fxos@lists.mozilla.org
>>>>>>> https://lists.mozilla.org/listinfo/dev-fxos
>>>>>>>
>>>>>>>
>>>>>> _______________________________________________
>>>>>> dev-fxos mailing list
>>>>>> dev-fxos@lists.mozilla.org
>>>>>> https://lists.mozilla.org/listinfo/dev-fxos
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> dev-fxos mailing list
>>>>> dev-fxos@lists.mozilla.org
>>>>> https://lists.mozilla.org/listinfo/dev-fxos
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> dev-fxos mailing list
>>>> dev-fxos@lists.mozilla.org
>>>> https://lists.mozilla.org/listinfo/dev-fxos
>>>>
>>>>
>>>
>>> _______________________________________________
>>> dev-fxos mailing list
>>> dev-fxos@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-fxos
>>>
>>>
>>
>>
>
> _______________________________________________
> dev-fxos mailing list
> dev-fxos@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-fxos
>
>
_______________________________________________
dev-fxos mailing list
dev-fxos@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-fxos
