On Wed, Nov 25, 2015 at 12:51 PM, Justin D'Arcangelo < [email protected]> 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 < [email protected]> 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 <[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]> > 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
