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 <[email protected]> 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 <[email protected] > <mailto:[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] > <mailto:[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] > <mailto:[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] > <mailto:[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] > <mailto:[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] >> <mailto:[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] >> <mailto:[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] >> <mailto:[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 >> <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 >> >> <https://github.com/mozilla-b2g/gaia/blob/master/apps/settings/elements/root.html#L140> >> 3. https://github.com/jsoverson/preprocess >> <https://github.com/jsoverson/preprocess> >> >> regards >> -- >> Fred >> >> >> >> _______________________________________________ >> dev-fxos mailing list >> [email protected] <mailto:[email protected]> >> https://lists.mozilla.org/listinfo/dev-fxos >> <https://lists.mozilla.org/listinfo/dev-fxos> >> >> >> _______________________________________________ >> dev-fxos mailing list >> [email protected] <mailto:[email protected]> >> https://lists.mozilla.org/listinfo/dev-fxos >> <https://lists.mozilla.org/listinfo/dev-fxos> > > > _______________________________________________ > dev-fxos mailing list > [email protected] <mailto:[email protected]> > https://lists.mozilla.org/listinfo/dev-fxos > <https://lists.mozilla.org/listinfo/dev-fxos> > > > > _______________________________________________ > dev-fxos mailing list > [email protected] <mailto:[email protected]> > https://lists.mozilla.org/listinfo/dev-fxos > <https://lists.mozilla.org/listinfo/dev-fxos> > > > > _______________________________________________ > dev-fxos mailing list > [email protected] <mailto:[email protected]> > https://lists.mozilla.org/listinfo/dev-fxos > <https://lists.mozilla.org/listinfo/dev-fxos> > >
_______________________________________________ dev-fxos mailing list [email protected] https://lists.mozilla.org/listinfo/dev-fxos
