CUTCODEDOWN
Minimalist Semantic Markup

Welcome Guest
Please Login or Register

If you have registered but not recieved your activation e-mail in a reasonable amount of time, or have issues with using the registration form, please use our Contact Form for assistance. Include both your username and the e-mail you tried to register with.

Author Topic: Elementals 4  (Read 1711 times)

makotoshishio

  • Junior Member
  • *
  • Posts: 9
  • Karma: +0/-0
Elementals 4
« on: 20 Jun 2021, 08:08:37 am »
Hey,

wanted to know if Elementals 4 is still a thing and progress is getting on.

I have dabbled with Elementals 3.7 for a few small private projects and really enjoyed it.
I was pondering on using for a production project and saw a few posts on here about Elementals 4.

Anywhere chance of sneak peak?

Thanks

coothead

  • Sr. Member
  • ****
  • Posts: 390
  • Karma: +89/-0
  • I smile benignly
    • coothead's stuff ~ an eclectic collection
Re: Elementals 4
« Reply #1 on: 20 Jun 2021, 08:31:06 am »
Hi there makotoshishio,

have you read this post...


Elementals 4, should I drop IE support entirely?


coothead
~ the original bald headed old fart ~

makotoshishio

  • Junior Member
  • *
  • Posts: 9
  • Karma: +0/-0
Re: Elementals 4
« Reply #2 on: 20 Jun 2021, 10:34:09 am »
Hi coothead,

I have read it, however it still leaves me in dark about the progress and direction of the project.
What features, if any are coming with it?
What will the upgrade path look like? etc.

Would love to find out more

coothead

  • Sr. Member
  • ****
  • Posts: 390
  • Karma: +89/-0
  • I smile benignly
    • coothead's stuff ~ an eclectic collection
Re: Elementals 4
« Reply #3 on: 20 Jun 2021, 10:42:39 am »
Hi there makotoshishio,

Quote
Would love to find out more.

You will have to wait for Jason to perhaps supply further information.  ;D

coothead
~ the original bald headed old fart ~

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 1049
  • Karma: +188/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: Elementals 4
« Reply #4 on: 23 Jun 2021, 04:37:51 pm »
The Elementals JavaScript project has been shelved for perhaps too long. I've had paying clients, a hospital stay, my medium writing, and a host of other issues get in the way of my working on it.

E4 was mostly abortive in that by the time I was done creating it, it was IMHO already out of date. I've in fact already moved on to what I might as well label version 5. Code-wise it's mostly ready for beta testing, what's really holding it up is creation of a new website with all-new documentation... as well as hammering out some details/methodology for "view-like" behaviors.

The biggest changes in 5 is that I'm telling a lot of the "crybaby practices" to sod off. They're not good practices, they're worry-wart nonsense that fails to leverage several advantages you can find in JavaScript's alleged "failings".

Such as the mutability of live objects -- including the system library ones -- via their parent's prototype. This can result in a cleaner syntax and LESS namespace conflicts despite the wild protestations of the opposite.

There are many reasons people say you shouldn't do it, but the big two are:

1) Legacy IE (8/earlier) can't do it.

2) You risk namespace conflicts with other frameworks/libraries and possible future changes to the langauge.

The first one I just no longer give a damn about! My "support" for legacy is to now no longer send them any JavaScript or even CSS. They get my vanilla markup and if that's not good enough, OH FREAKING WELL.

The second one is more fear and paranoia than fact. It's used as an excuse for damned near everything when in practice it happens so rarely if you bother having a good naming convention, that it SHOULD be a non-issue. The best way is to not dive for the lame excuse and instead find a unique naming scheme. To that end E5 uses a double underscore.

Which is why the underscore object goes away. For example:

_.ajax === document.__ajax
_.cookes === document.__cookies
_.make === document.__make & element.__make

That last one, the latter method is used when you want to apply it to an element as a child. If the placement attribute in the command set says where to place it, defaulting to "last".

For example, let's say you've gotten hold of a node like a h1, and you want to remove it.

Code: [Select]
document.querySelector('h1').__remove();
Deletes the entire H1.

Let's say you wanted a cross-browser safe text-content.

let text = document.querySelector('h1').__textcontent

See why such a method even needs to exist here:
http://perfectionkills.com/the-poor-misunderstood-innerText/

Using defineProperties we can also make a number of simpler references to values.

Code: [Select]
let code = '<h2>Sample Text</h2>'.__htmlspecialchars;
Notice it's not () for a function. Since we need to send no properties, we can just extend string to have a getter. A LOT of things frameworks and even JS itself does as methods (for no good reason) I'm making as properties via getters and setters.

Other useful properties include:

String.__regexEscape -- make a string safe to plug into a regExp, 

String.__condensed -- does a trim and reduces all whitespace to single characters

Array.__remove -- removes a value, or values in an array, from the array.

Example:
Code: [Select]
let source = [1, 3, 9, 11, 17 ];
source.__remove([3, 11];
console.log(source); // [ 1, 9, 17 ]


One I really like that I've done?

Object.__entries -- an alias for performing Object.entries(targetObject).

So instead of doing:

Code: [Select]
for (let [key, value] of Object.entries(testObject)) {
I can write:

Code: [Select]
for (let [key, value] of testObject.__entries)) {
I really don't know why they keep insisting on making all these static methods you have to pass an object to, instead of just making it an accessible property.

There are also other "modernizations" I'm doing like using LET and CONST, even though I'm not a fan of either... and arrow functions which I find cryptic, but it's "expected" by others these days.  I have to remind myself this isn't about me.

 This has had an interesting advantage in that I'm able to replace the IIFE with just {}.

One of the biggest changes is that the "make" routine will no longer return the element, but an object where result.__element is the parent element, and the rest of the object contains references to "variables" you can set in the DOM-JON that when you change, also change the live DOM showing said "variable". Thus we get something akin to "views" but without any dom fragment / shadow-dom nonsense in the overhead.

So it is in the works, even though sadly I've not touched it since shortly before I went into the hospital in March.
« Last Edit: 24 Jun 2021, 02:38:43 am by Jason Knight »
We are all, we are all, we are all FRIENDS! For today we're all brothers, tonight we're all friends. Our moment of peace in a war that never ends.

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 1049
  • Karma: +188/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: Elementals 4
« Reply #5 on: 24 Jun 2021, 02:41:22 am »
Actually due to the prompting I've been playing with it this evening again... and I'm really not liking how I implemented "views". Trying to decide if perhaps I should make a custom property "data-variables" or __variables on the parent Elements instead of returning a complex object.

Though I'm also wondering if I should just have .__make only accept a fully qualified DOM-JON array instead of having the two separate parameters of DSS and DJ Commands. As it is I've been expanding the contents of the DOM-JON object...

So I guess now it's DOM-JON 2.0
We are all, we are all, we are all FRIENDS! For today we're all brothers, tonight we're all friends. Our moment of peace in a war that never ends.

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 1049
  • Karma: +188/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: Elementals 4
« Reply #6 on: 25 Jun 2021, 06:06:10 pm »
Side note, the "JOYS" of unit testing... I set aside today and tomorrow JUST to work on Elementals 5 getting the library itself ready for a public release. I've come up with a really good mechanism for "views" or "state" driven values.

For example:

Code: [Select]
let h2State = document.querySelector('main').__make(
"h2", [
"Your value is:",
[ "output", { name : "headingValue", value = 1 } ]
], true
).__state;

Generates

Code: [Select]
<h2>Your value is: <output>1</output>
Directly on the dom. If we were to say:

Code: [Select]
h2State.headingValue = 5;
That 1 would be changed to 5.

Code: [Select]
h2State.headingValue++;
And now it's 6.

 You can operate on the Element.__state properties as per normal variables, and they will auto-update their associated fields. They are tracked in normal variables not the DOM, so reads of their value behave normally instead of being forced to "string".  (admittedly, doing so by abusing function parameter retention)

If needed, Element.__state.$name refers to the tag. Thus in the above example h2State.$headingValue is the output tag itself.

Question for the public:

I have my AJAX handler to "simplify" things like handling the different status code, making sure requests have the correct mime-type, and most importantly passing the XMLHttpRequest object to the handler properly.

... but with now being able to hook the "load" event and event.currentTarget now being the XMLHttpRequest, should I even bother? I'm half tempted to rip it out wholesale. Particularly with XMLHttpRequest.response now giving me a parsed object when responseType is JSON.

I think I'll keep it but modernize slightly and remove the redundancies.

It's amazing how much of this I'm throwing on the cutting room floor just because JavaScript has "matured" implementing a lot of what we used to have to brute-force.

We are all, we are all, we are all FRIENDS! For today we're all brothers, tonight we're all friends. Our moment of peace in a war that never ends.

makotoshishio

  • Junior Member
  • *
  • Posts: 9
  • Karma: +0/-0
Re: Elementals 4
« Reply #7 on: 30 Jun 2021, 05:40:59 am »
If the language does something natively then let it be native. Until or unless you run into specific worthy issues.

If users of the library can get to work quickly whilst not having a steep learning curve it can boost adoption.

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 1049
  • Karma: +188/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: Elementals 4
« Reply #8 on: 1 Jul 2021, 05:04:12 am »
If the language does something natively then let it be native. Until or unless you run into specific worthy issues.

If users of the library can get to work quickly whilst not having a steep learning curve it can boost adoption.
I agree. To that end what I think I might try and do is add my extensions to the existing system object instead of replacing it. JavaScript is pervasively object driven, with extensibility being a core concept of its object model... so why not just extend it?

Give it a defined internal array of response types, so that when you define XMLHttpRequest.responseType it automatically sets the correct XMLHttpRequest.mimeType. Maybe even allow setting a XMLHttpRequest.__statusHandlers so the end user doesn't have to play with doing a switch() on event.currentTarget.status, using a setter model instead of manually writing their own onload event.

Code: [Select]
x.responseType = "JSON";
x.__statusHandlers = {
  "200" : successFunction,
  "404" : notFoundFunction,
  "unhandled" : unhandledErrorFunction
};

Seems a lot nicer. Might also change the constructor. Might be nice to be able to set:

Code: [Select]
var x = new XMLHttpRequest( {
  responseType : "JSON",
  __statusHandlers : {
    "200" : successFunction,
    "404" : notFoundFunction,
    "unhandled" : unhandledErrorFunction
  },
  send : {
    uri : "http://whatever.domain/ajaxRequest",
    method : "post",
    data : formObject
  }
});

Though I don't know if I can actually overload the constructor. Hmm. Puts me back to making a document.__ajax routine.
We are all, we are all, we are all FRIENDS! For today we're all brothers, tonight we're all friends. Our moment of peace in a war that never ends.

makotoshishio

  • Junior Member
  • *
  • Posts: 9
  • Karma: +0/-0
Re: Elementals 4
« Reply #9 on: 2 Sep 2021, 11:53:15 am »
Hoy hoy!

Hope all is well!

Just touching base to see how this is progressing?

JS Kelly

  • Junior Member
  • *
  • Posts: 31
  • Karma: +5/-0
Re: Elementals 4
« Reply #10 on: 3 Sep 2021, 03:05:00 pm »
what's really holding it up is creation of a new website with all-new documentation...

I would like to offer my editing services with regard to the creation of the 'new website and all-new documentation.' And my editing services in general -- I'd be happy to proofread any of your Medium articles before they are posted [in "Convincing People That Web Accessibility Matters," my two main comments would be that you often put punctuation outside quotation marks (“too expensive to waste money on for so few people”, should be  “too expensive to waste money on for so few people,”) and then also you use the word "gypped" which some people consider to be racist]. I also have a bunch of story ideas for you, if you are interested. Lately I spent a few days reading about these new-fangled "static site generators" and the whole time I was reading about them, I kept thinking "I wish Deathshadow had a rant about this!" No matter where I go and what I read, I always come back here to ccd to recharge my sanity in all things webby. This is by far my favorite site for html/css, and I thank you again for keeping it going.

In other news, my own little project is slooooowly progressing. One day soon I hope to have some html/css to post here for help.

Finally, in the paragraph below the one I quoted above, you use "worry-wart" -- it should be 'worrywort.'

Happy weekend everyone
--jsk

PS Deathshadow -- if you /are/ interested in editing help, you have my email address.

makotoshishio

  • Junior Member
  • *
  • Posts: 9
  • Karma: +0/-0
Re: Elementals 4
« Reply #11 on: 18 Oct 2021, 09:15:46 am »
Hey hey,

Just checking on Elementals.

Anything happened/happening?

Can we help?

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 1049
  • Karma: +188/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: Elementals 4
« Reply #12 on: 19 Oct 2021, 08:00:06 pm »
It got put on the back burner again thanks to two clients in a row that required more attention than they should have.... since AGAIN I had to go to war with the client's middle-management.

I'm also revamping how "views" / state are handled... which means some rewrites of the already incomplete documentation.

Also even more legacy code has been ripped out... because honestly if a browser doesn't support at least ECMAScript 6, I'm not bending over backwards to support it anymore.
We are all, we are all, we are all FRIENDS! For today we're all brothers, tonight we're all friends. Our moment of peace in a war that never ends.

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 1049
  • Karma: +188/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: Elementals 4
« Reply #13 on: 20 Oct 2021, 12:16:33 am »
For the morbidly curious, here's the current alpha about ready to go beta once I finish unit testing. It's a wee bit different a beasty from anything prior, though it partly returns to the roots of 1.x since we can now tell IE to suck it.

Again, not even fully unit tested yet, much less well documented.

https://elementalsjs.com/scripts/elementals.5.0.0e.js

If a letter is on the minor revision, it's an alpha. The beta will be .beta followed by the beta number, same for rc.

So for example Release Candidate 1 will be elementals.5.0.0.RC1.js

Generally I don't share my alpha's public, but it feels like I'm standing in mud on unit testing and documenting.
We are all, we are all, we are all FRIENDS! For today we're all brothers, tonight we're all friends. Our moment of peace in a war that never ends.

Jason Knight

  • Administrator
  • Hero Member
  • *****
  • Posts: 1049
  • Karma: +188/-1
    • CutCodeDown -- Minimalist Semantic Markup
Re: Elementals 4
« Reply #14 on: 20 Oct 2021, 12:21:48 am »
Oh, I'm also going to be adding a lot more error reporting at the console level to things in terms of type checking. You pass a string where an object should be expected, it should bitch about it with a console.error(), and a console.trace() to make the error report USEFUL.

Thus the internal use LOG object.  Still trying to decide if I should expose that or not given that the underscore object of the original elementals has gone the way of the dodo in favor of hooking existing elements.

Maybe make the internal "log" be Console.__elementals?
We are all, we are all, we are all FRIENDS! For today we're all brothers, tonight we're all friends. Our moment of peace in a war that never ends.

 

SMF spam blocked by CleanTalk

Advertisement