Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #34691 > unrolled thread

A simpler DOM in JS

Back to article view | Back to comp.lang.javascript

Contents

  A simpler DOM in JS "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-02-03 14:24 -0800
    Re: A simpler DOM in JS Martin Honnen <martin.honnen@gmx.de> - 2018-02-04 14:26 +0100
      Re: A simpler DOM in JS Julio Di Egidio <julio@diegidio.name> - 2018-02-04 06:18 -0800
        Re: A simpler DOM in JS Ken Tilton <kentilton@gmail.com> - 2018-03-05 08:14 -0800
          Re: A simpler DOM in JS Julio Di Egidio <julio@diegidio.name> - 2018-03-08 00:43 -0800
            Re: A simpler DOM in JS Ken Tilton <kentilton@gmail.com> - 2018-03-08 05:57 -0800
              Re: A simpler DOM in JS Julio Di Egidio <julio@diegidio.name> - 2018-03-08 07:56 -0800
      Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-05 06:15 +0100
        Re: A simpler DOM in JS "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-02-04 23:15 -0800
      Re: A simpler DOM in JS "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-02-04 23:06 -0800
    Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-05 05:50 +0100
      Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-05 06:26 +0100
        Re: A simpler DOM in JS "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-02-04 23:33 -0800
          Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-05 11:19 +0100
            Re: A simpler DOM in JS Julio Di Egidio <julio@diegidio.name> - 2018-02-05 04:16 -0800
            Re: A simpler DOM in JS "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-02-05 10:23 -0800
              Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-05 19:42 +0100
                Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-08 01:46 +0100
                Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-08 01:47 +0100
                  Re: A simpler DOM in JS "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-02-11 10:27 -0800
                    Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-12 04:38 +0100
                      Re: A simpler DOM in JS "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-02-15 12:19 -0800
                        Re: A simpler DOM in JS Julio Di Egidio <julio@diegidio.name> - 2018-02-15 12:43 -0800
                        Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-25 19:22 +0100
                Re: A simpler DOM in JS "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-02-07 12:51 -0800
                  Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-08 02:27 +0100
                    Re: A simpler DOM in JS John G Harris <niam@jghnorth.org.uk.invalid> - 2018-02-08 19:21 +0000
              Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-05 19:58 +0100
      Re: A simpler DOM in JS "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-02-04 23:30 -0800
        Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-05 19:11 +0100
          Re: A simpler DOM in JS "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-02-11 10:16 -0800
            Re: A simpler DOM in JS Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2018-02-12 04:48 +0100
    Re: A simpler DOM in JS Ken Tilton <kentilton@gmail.com> - 2018-03-05 08:07 -0800
      Re: A simpler DOM in JS "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2018-03-06 17:40 -0800
        Re: A simpler DOM in JS Ken Tilton <kentilton@gmail.com> - 2018-03-07 12:09 -0800

Page 2 of 2 — ← Prev page 1 [2]

#34727

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> > As in, if I rotate the screen and I want LinearLayout to become
>> > RelativeLayout, what do I do?
>> [suffixed resource directories, build layouts from fragments to DRY]
> 
> Sounds far worse than what CSS+HTML provides (flex and grid). I know
> JavaFX supports CSS for layouts, but I can only imagine what a combination
> of "hbox" and "flex-direction: row" would do...

You have not thought this through.  Flex and Grid are not nearly
as flexible as, e.g., ConstraintLayout.  And there are no includes
in HTML (natively).
 
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#34736

Thomas 'PointedEars' Lahn wrote:

> You have not thought this through.  Flex and Grid are not nearly
> as flexible as, e.g., ConstraintLayout.  

Admittedly. I'll have to spend more time looking at their approach to layout.

> And there are no includes in HTML (natively).

Chrome supports HTML Imports [1], but it's still an open question if it'll be a standard ultimately, and even so that competitors will implement it. Mozilla has expressed they won't [2].

[1] <http://w3c.github.io/webcomponents/spec/imports/>
[2] <https://hacks.mozilla.org/2015/06/the-state-of-web-components/>

[toc] | [prev] | [next] | [standalone]

#34737

On Thursday, 15 February 2018 21:19:32 UTC+1, Michael Haufe (TNO)  wrote:
> Thomas 'PointedEars' Lahn wrote:
> 
> > You have not thought this through.  Flex and Grid are not nearly
> > as flexible as, e.g., ConstraintLayout.  
> 
> Admittedly. I'll have to spend more time looking at their approach to layout.
> 
> > And there are no includes in HTML (natively).
> 
> Chrome supports HTML Imports [1]

In HTML5, "natively", one can use script elements to embed even content
of type text/html...  Knockout.js, just to say, not only (and just to begin
with) eliminate *all* need for DOM manipulation, it also supports HTML5
script-based templates out of the box (even hierarchical templates), which
is anyway just a bit of logic accessing the nodes under the script element.

Julio

[toc] | [prev] | [next] | [standalone]

#34747

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> And there are no includes in HTML (natively).
> 
> Chrome supports HTML Imports [1], but it's still an open question if it'll
> be a standard ultimately, and even so that competitors will implement it.
> Mozilla has expressed they won't [2].
>  
> [1] <http://w3c.github.io/webcomponents/spec/imports/>
> [2] <https://hacks.mozilla.org/2015/06/the-state-of-web-components/>

The article is old, but in light of it I find it very unfortunate that, even 
more so since Mozilla.com was established, apparently we have to put our 
hopes in *companies* like Google and Apple instead of organizations like 
Mozilla for innovation in Web development.

To Mozilla/Gecko the choice for a feature always appears to be binary – do 
or don’t, with a tendency to the latter – while in WebKit and forks, and 
browsers that use them, you do find experimental features to play with that 
often become standard later.  

I was just reading through the old WebKit blog, “Surfin’ Safari”, and 
realized with awe how many cool CSS features they introduced that are now 
standard or close to becoming one *because they submitted them as proposals 
to the W3C*.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#34722

Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:
> 
> > Thomas 'PointedEars' Lahn wrote:
> >> [...]
> >> [Android layout XML] 
> > 
> > While I like the declarative nature, the use of layout containers I find
> > iffy. How you do manage dynamic layouts?
> 
> Depends.  “Dynamic” as in…?

As in, if I rotate the screen and I want LinearLayout to become RelativeLayout, what do I do? 
 
> Hmmm.  HTML5 validation is actually more strict than HTML < 5 validation, 
> enabled by a grammar that is algorithmic instead of declarative.  But this 
> also makes it more difficult to implement.

s/algorithmic/procedural

[toc] | [prev] | [next] | [standalone]

#34723

Stefan Ram wrote:

> "Michael Haufe (TNO)" <tno@thenewobjective.com> writes:
>> As in, if I rotate the screen and I want LinearLayout to
>> become RelativeLayout, what do I do?
> 
>   One can save XML files into one's project folder like
> 
> res/
>     layout/
>         main.xml (Default layout)
>     layout-port/
>         main.xml (Specific layout for portrait mode)
>     layout-land/
>         main.xml (Specific layout for landscape mode)

This is nonsense!  The directory suffix is supposed to be *more* *specific* 
as the suffixed directories are preferred.  As a result, if you have all 
three of those directories and files, there is *dead* *code* in 
layout/main.xml as the screen mode is either “portrait” or “landscape”, and 
the default is “portrait”.

<https://developer.android.com/training/basics/supporting-devices/screens.html#create-layouts>

    I feel obligated at this point to recommend to everyone to just ignore
    everything that Stefan Ram says regarding IT.  He is a folk high school¹
    teacher² impervious to criticism who has repeatedly demonstrated that he
    has no clue what he is talking about, and probably has not worked so
    much as one hour in IT.  For all the time that I have been reading him
    in the German-speaking Usenet (several years now), he has just been
    posing; he has never acknowledged any mistake nor engaged in so much as
    one discussion to defend his usually ill-advised ideas :-(

_______
¹  
<https://en.wikipedia.org/wiki/Folk_high_school#Germany,_Switzerland_and_Austria>

²
You are not required to have any formal education or degree to teach there.  
If suffices that you can convince the school administration that you know 
what you are talking about.  Which is of course a joke as the administration 
usually does not understand the topic themselves, and thus cannot make an 
informed judgement.  As a result, while the education is comparably 
inexpensive, you can also find all sorts of crackpots "teaching" there.

[de] <https://www.akademie.de/wissen/freiberufler-an-volkshochschulen>
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#34724

On Thu, 08 Feb 2018 02:27:02 +0100, Thomas 'PointedEars' Lahn
<PointedEars@web.de> wrote:

  <snip>
>he has never acknowledged any mistake

Writes the person who insists he cannot be proved wrong just because
the Standard says he's wrong.


  <snip>
>You are not required to have any formal education or degree to teach there.  
  <snip>

Most English universities do not require lecturers, even professors,
to have a PhD. And then there was Michael Faraday.

  John

[toc] | [prev] | [next] | [standalone]

#34717

Stefan Ram wrote:

> "Michael Haufe (TNO)" <tno@thenewobjective.com> writes:
>>While I like the declarative nature, the use of layout
>>containers I find iffy. How you do manage dynamic layouts?
> 
>   You can create and configure objects of all widget and
>   container classes (which also can be subclassed) directly
>   in Java code without the XML approach.

But that is *strongly* recommended *against* as it does not work well (it 
would be a PITA to maintain, if it even worked) with different form factors, 
display resolutions, and screen modes.  Instead, includes and suffixed 
resource directories ought be used.

How come that you virtually *always* recommend the *least* recommended 
approaches or the ones recommended *against*?
 

PointedEars, Google Android Dev Challenge Scholarship alumnus
-- 
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#34700

Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:
>
> > I'm not a fan of JSX, nor was I a fan of E4X before it.
> 
> E4X would have made building trees a lot easier, but it had flaws.

Indeed, as referenced earlier. 

> [...]

> <https://github.com/PointedEars/JSX/blob/27be459b2da4d2b8052c293d6930d0c020821de4/dom.js#L504-L663>
 
> (The name “JSX” is coincidental; I used it first, but only the people in 
> Usenet, SELFHTML.DE, and maybe Twitter, knew about it.)

I had forgotten about this as you don't advertise much. Do you have some off-the-cuff examples of usage? And from a quick look, it still holds on to a significant amount of legacy IE management (not a criticism). Is there anything you would change in retrospect at this stage?

> > Here's what we have to contend with for the equivalent:
> > 
> > <script type="JavaScript">
> 
> Not Valid.

I'm surprised you didn't pick on <script type="C#">.

This was being used for demarcation, not for implying use in some web page. 

> >   var root = document.createElement("root")
> > 
> >   for(var i = 1; i <= 6; i++) {
> >     var child = document.createElement("child" + i)
> >     child.textContent = i
> >     root.appendChild(child)
> >   }
> 
>     var root = jsx.dom.createNodeFromObj({
>       type: "root",
>       childNodes: Array.apply(null, {length: 6}).map(
>         (e, i) => {
>           return {
>             type: "child" + i,
>             properties: {textContent: i}
>           };
>         })
>     });
> 
> >   console.log(root.outerHTML)
> 
> Tested on <http://PointedEars.de/>, which uses JSX:dom.js.

Ah, here is the example I was asking for earlier.

>     [<child$i>…</…> is insane markup.]
> 
> > [tl;dr]

To quote Willy Wonka: "A Little Nonsense Now and Then is Relished by the Wisest Men" [1]

[1] <https://www.youtube.com/watch?v=MS5_cIwzkII>

[toc] | [prev] | [next] | [standalone]

#34712

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> [...]
>> 
<https://github.com/PointedEars/JSX/blob/27be459b2da4d2b8052c293d6930d0c020821de4/dom.js#L504-L663>
>  
>> […] from a quick look, it still holds on to a significant amount of
>> legacy IE management (not a criticism). Is there anything you would
>> change in retrospect at this stage?

Certainly.  My code is not set in stone.  To what exactly are you referring?
 
>> > Here's what we have to contend with for the equivalent:
>> > 
>> > <script type="JavaScript">
>> Not Valid.
> 
> I'm surprised you didn't pick on <script type="C#">.
> 
> This was being used for demarcation, not for implying use in some web
> page.

In this *newsgroup* you should have expected *that* to be misunderstood.
 
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#34725

Thomas 'PointedEars' Lahn wrote:
> Michael Haufe (TNO) wrote:

> >> […] from a quick look, it still holds on to a significant amount of
> >> legacy IE management (not a criticism). Is there anything you would
> >> change in retrospect at this stage?
> 
> Certainly.  My code is not set in stone.  To what exactly are you referring?

1. ESNext =[compilation]=> ES Target
2. Move IE specific checks and compatibility into a babel plugin [1]
3. npm packaging (which don't have to be published and can be installed directly from a git repo)

> > This was being used for demarcation, not for implying use in some web
> > page.
> 
> In this *newsgroup* you should have expected *that* to be misunderstood.

The subtle prejudice of low-expectations I guess

[1] <https://babeljs.io/docs/plugins/#transform-plugins>

[toc] | [prev] | [next] | [standalone]

#34728

Michael Haufe (TNO) wrote:

> Thomas 'PointedEars' Lahn wrote:
>> Michael Haufe (TNO) wrote:
>> >> […] from a quick look, it still holds on to a significant amount of
>> >> legacy IE management (not a criticism). Is there anything you would
>> >> change in retrospect at this stage?
>> Certainly.  My code is not set in stone.  To what exactly are you
>> referring?
> 
> 1. ESNext =[compilation]=> ES Target

Probably not.  I envision a testing nightmare.

> 2. Move IE specific checks and compatibility into a babel plugin [1]

No thanks, but I have a compatibility infrastructure already.

> 3. npm packaging (which don't have to be published and can be installed
> directly from a git repo)

Yes, I am considering Bower.  There are more important tasks first.
 
>> > This was being used for demarcation, not for implying use in some web
>> > page.
>> In this *newsgroup* you should have expected *that* to be misunderstood.
> 
> The subtle prejudice of low-expectations I guess

Not at all.  The “script” element was designed to insert code written in the 
languages discussed here.
 
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#34758

On Saturday, February 3, 2018 at 5:24:27 PM UTC-5, Michael Haufe (TNO) wrote:
> I'm not a fan of JSX, nor was I a fan of E4X before it. Embedded DSLs require code-switching [1] for understanding, or require the DSL to be a black box to the host language in the case of template strings [2].
> 
> Dealing with the DOM APIs directly are terribly verbose though as we know. Should we not do better? 
> 
> In System.XML.LINQ [3] the approach is to construct XML elements and their contents by nested constructors:
> 
> <script type="C#">
>   var root = new XElement("Root",
>     new XElement("Child1", 1),
>     new XElement("Child2", 2),
>     new XElement("Child3", 3),
>     new XElement("Child4", 4),
>     new XElement("Child5", 5),
>     new XElement("Child6", 6)
>   );
> 
>   Console.WriteLine(root);
> 
>   /*
>   <Root>
>     <Child1>1</Child1>
>     <Child2>2</Child2>
>     <Child3>3</Child3>
>     <Child4>4</Child4>
>     <Child5>5</Child5>
>     <Child6>6</Child6>
>   </Root>
>   */
> </script>
> 
> Should we not do similar for the dirty DOM we have to deal with? Here's what we have to contend with for the equivalent:
> 
> <script type="JavaScript">
>   var root = document.createElement("root")
> 
>   for(var i = 1; i <= 6; i++) {
>     var child = document.createElement("child" + i)
>     child.textContent = i
>     root.appendChild(child)
>   }
> 
>   console.log(root.outerHTML)
> </script>
> 
> And that is for a very trivial use-case.
> 
> My proposal is that a library be created to promote the approach of System.XML.LINQ to the HTML DOM. The result being not simply the emulation of the C# example but additionally the ability to warn of deprecated attribute usage and illegal compositions such as placing a button element inside of an option element.
> 
> I am curious to the community's thoughts on the topic.
> 
> 
> [1] <https://en.wikipedia.org/wiki/Code-switching>
> [2] <http://2ality.com/2015/01/template-strings-html.html>
> [3] <https://msdn.microsoft.com/en-us/library/system.xml.linq.xelement(v=vs.110).aspx>

I just wrote up my system, which supports pure JS because, well, it is all JS all the time. A reactive HTML-workalike JS  library silently maintains the DOM for us, with point efficiency because it always knows what changed.

The write-up is in the form of a CodePen: https://codepen.io/kennytilton/pen/mXQNYR

hth, kt

[toc] | [prev] | [next] | [standalone]

#34762

Ken Tilton wrote:

> I just wrote up my system, which supports pure JS because, well, it is all JS all the time. A reactive HTML-workalike JS  library silently maintains the DOM for us, with point efficiency because it always knows what changed.
> 
> The write-up is in the form of a CodePen: https://codepen.io/kennytilton/pen/mXQNYR

With black box DSLs here as well it seems. From your CodePen:

<script>
defcode( 'preface',
    "All tag functions have the signature:\n\
  <i>tag</i>([<i>HTML attributes</i>, [<i>custom properties</i>,]] <i>children*</i>)\n\
\n\n\
section({class: 'todoapp'},\n\
   header({class: 'header'},\n\
      h1('todos'))),\n\
\n\
   p('The working app will appear here.')");
</script>

[toc] | [prev] | [next] | [standalone]

#34763

On Tuesday, March 6, 2018 at 8:40:24 PM UTC-5, Michael Haufe (TNO) wrote:
> Ken Tilton wrote:
> 
> > I just wrote up my system, which supports pure JS because, well, it is all JS all the time. A reactive HTML-workalike JS  library silently maintains the DOM for us, with point efficiency because it always knows what changed.
> > 
> > The write-up is in the form of a CodePen: https://codepen.io/kennytilton/pen/mXQNYR
> 
> With black box DSLs here as well it seems. From your CodePen:
> 
> <script>
> defcode( 'preface',
>     "All tag functions have the signature:\n\
>   <i>tag</i>([<i>HTML attributes</i>, [<i>custom properties</i>,]] <i>children*</i>)\n\
> \n\n\
> section({class: 'todoapp'},\n\
>    header({class: 'header'},\n\
>       h1('todos'))),\n\
> \n\
>    p('The working app will appear here.')");
> </script>

No, that defcode/defchat/defbit DSL is just for this elaborate CodePen, ie, nothing to do with the framework per se. In the "Preface" panel I mentioned we would be building an app within an app. The larger app presents panel after panel within the pen, and over time as I elaborated the larger app I found it a bit (but not much) more manageable to cook up that DSL.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.javascript

csiph-web