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 <[email protected]>
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 <[email protected]> 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 <[email protected]>
>> 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 <
>>> [email protected]> 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 <[email protected]>
>>>> 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 <[email protected]> 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 <
>>>>> [email protected]> 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 <[email protected]> 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
>>>>> [email protected]
>>>>> https://lists.mozilla.org/listinfo/dev-fxos
>>>>>
>>>>>
>>>> _______________________________________________
>>>> dev-fxos mailing list
>>>> [email protected]
>>>> https://lists.mozilla.org/listinfo/dev-fxos
>>>>
>>>>
>>>
>>> _______________________________________________
>>> dev-fxos mailing list
>>> [email protected]
>>> https://lists.mozilla.org/listinfo/dev-fxos
>>>
>>>
>>
>> _______________________________________________
>> dev-fxos mailing list
>> [email protected]
>> https://lists.mozilla.org/listinfo/dev-fxos
>>
>>
>
> _______________________________________________
> dev-fxos mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-fxos
>
>
_______________________________________________
dev-fxos mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-fxos
