Question: Reason behind spinning up a new UI framework

[mainrs]

Has there been specific needs or other reasons on why you decided to create a new UI framework from scratch rather then using something like VueJS or React that already provide a lot of functionality by third party packages (like windowing)?

The only reason I could think of would have been performance, seeing that a lot of the code is written in an "older-styled" way. I am just curious :)

Have a great day!

[mr21]

Well this is a big question..

First thing first, the gridsound's code is 20 000 lines in total composed by:

• 14 000 lines of JS
• 5 000 lines of CSS
• 1 000 lines of HTML

I didn't recode any framework but i've coded a compilation of vanilla components. This is really different.
I don't need a framework if i'm ready to do all the DOM operations by hand: element.textContent = "toto" instead of <span>{"toto"}</span>. The MDN documentation is so well written it's a pleasure to learn how to do it from scrath and the JS is so flexible that you can easely chose your own design pattern to handle exactly how you want to store your data and how to code your undo/redo.

Even if i took a framework at the begining i would have to do all the components needed by myself (except maybe few, you have talked about the windowing? which package are you talking about?)

I will say the only advantage i see to use a framework, it's consistency.
I have to admit in gridsound there are too many different conceptions started in different area, but because i have separated the entire project into many small pieces, we can redo any section independently of the rest (like watertight compartments), so i'm not too afraid for the moment :D

However i see 3 reasons to not use a framework.

The main one is because angular/react/vue and the unnamable css-in-js concept are not standard.
The W3C's response for the framework problem is the custom element and this is really far from what react/redux looks in general.
Like the old Flash, React give you a frame, a new world, new laws INSIDE a current web lead by completely different rules.
So yes i think it's completely not optimized, and the fact that react thinks only DOM operations are heavy and uses the shadow DOM every where at every moment risks to lead to have an app being slower and slower depending of the amount of render() inside each others...

The second reason is the fact that react/vue itself (cf. without npm packages) will helps you to do simple things faster yes, but will slowdown your process at the moment of doing more complex mechanics.
In vanilla i could always plan a strategy to avoid some lags, avoid some calculations etc. with a framework, if the given solution doesn't work enough i'm done.

The third reason is that i give to gridsound a longer lifetime estimation than react. What will happen when Facebook will see that nobody use IE11 for the web anymore (and not only for intranets somewhere)? They could redo their entire websites with standard and faster code. Then they will drop the support of react. React will lose its hype and this will be the real technological debt because no new engineer will want to work on a deprecated technology.
There is even a scenario where React native could be drop too, Google wants to make the webapps installable right? what if Google Android let the devs create full native apps with only HTML5? Then react native will only be used for iOS?

For all those reasons plus the fact that i knew all the fundamentals of JS/CSS i chose to go on the native vanilla path.

Thanks for your curiosity and your interest :)

[anthumchris]

Great project! Is lit-html being used or has it been considered? It's a very performant, lightweight, non-framework template/rendering library that could augment the current vanilla path while giving massive performance boosts. Leveraging Incrementality for Faster Web UI is a good video to watch to see the perf benefits (lit-html can be used without lit-element (W3C Web Components))

[mr21]

Hi :) thx for your interest

I understand the solution of lit-html/element but i don't understand the problem. They say they don't do VDOM diffing, but they have still to do diff on data or on the string or idk what, but they have to call some functions, some loop, use some ifs etc.
Why using all this complex ideas instead of simply element.classList.toggle() or element.textContent = ''?

It's written that only what's change will be updated, that's great but what is the other scenario? Why some people would update some HTML if there is no change?
Does the js dependency authors imagine that without them with are blocking to do something like this:

setInterval( () => {
    document.body.innerHTML = `all the app`;
}, 1000 / 60 );

All the data that have to be changed has some ID or are in a liveNodeList somewhere etc. all those library/framework try to be optimized like if you did it by hand.

I see in the lit's code s.lastIndexOf('<!--'); this is not normal to me. Where do you need to parse an HTML string yourself? i will not lie, i don't understand anything. The HTML is on the index.html at the start of the application (after a cat *.html > index.html or whatever) and after we should play with the DOM only by references. I don't know who brings the idea of HTML in a string but i am really outside of this idea.

[mr21]

Where is the problem of doing something like this :

class MyComponent {
	constructor() {
		this.elRoot = MyComponent.template.cloneNode( true );
		this.subElement = this.elRoot.querySelector( ".MyComponent-subElement" );
		this.subElement2 = this.elRoot.querySelector( ".MyComponent-subElement2" );
		this.subElement3 = this.elRoot.querySelector( ".MyComponent-subElement3" );
	}
	
	open() {
		this.elRoot.classList.add( "MyComponent-open" );
	}
	close() {
		this.elRoot.classList.remove( "MyComponent-open" );
	}
}

MyComponent.template = document.querySelector( ".MyComponent" );
MyComponent.template.remove();

It can't be more optimised right? so what is the problem? is it not readable enough not maintenable enough?
Does the people wants to see the HTML with the ${data} inside a nice indented string? They want that at any cost? even if it require to the user to DL an additional javascript file?
I never see a tech.js confronting this ^, it's only confronting the body.innerHTML in a loop or at each action.

A mistery.

EDIT: i just though that many people think if we don't use react then we have to recode react, so, do you think the code above is a framework?

[mr21]

I am afraid to look as someone toxic, i'm really not, thanks you to propose me some concept, some ideas, i'm really thankful

I considere this issue here as a technical debat ^^ then i'm sharing with you the fact that i'm annoyed to never see the opposite arguments on these tech pages.

You send me a video of Google, they are probably the best web devs in the world, and they are saying to us (devs outside of GAFAM) that we are not oblige to update all the DOM? How Google was coding their Google Sheet before the framework era? are they saying when you edit one cell the entire app is redraw? no obviously not.

Then how were they doing it? it's looks like they think that if you are not at GAFAM already then you can't code like them.
They should teach us instead of giving us tools, the MDN is teaching us.

And it's on the MDN that i've found the custom element (or web element like you said), and this is where i would like to go, for 2 reasons:

• the standard don't force you to use the HTML in a certain way.
• the dis/connectedCallback

[anthumchris]

My apologies, I didn't mean to suggest that any particular problem currently exists. I personally try to avoid frameworks myself. Just came across this GitHub issue and wanted to recommend lit-html if anyone was interested. I personally like to use A/B performance tests before choosing something new, but lit-element's async rendering with Promises could potentially be useful in certain situations. I do know that it takes advantage of the new <template> Element, which was not previously available in browsers.

[mr21]

No need to you to be sorry, it's on me i'm too direct on this subject, i have many things to say/ask...

But i have to admit, lit-html looks a lot more like a library than a framework you're right. And by framework i mean also React, they sale it as a library but i've never see anyone doing more than one ReactDOM.render() per project :/

I have read several lit's example to see how it's works with DOM events, this looks cool, i understand why you wanted to propose this. But i still think we should not mix HTML with logic, so i don't feel the need to have the template really inside the code.

Also would it be possible to send back to lit only what have changed? imagine if in the template there are an A and B text values, do i need to pass A and B each time even if only one of theme has a new value?

A/B performance tests sounds great, how do you do that? How can we be sure the browser will not find a pattern to optimized when we call 10_000 times the same code in a loop? I love those questions but sadly the frameworks have moved the debat from what is fast for CPU to what is fast to code.

Anyway here the main problem is still the recalc/redraw, it's the reason why i've made the UI's FPS flexible and this makes change the CPU % drastically.

[MartyWind]

Hi @mr21, these are just my two cents on this topic:
Using a framework (UI or build system alike)

• enables more developers to jump on the code in little time, because concepts and structure are standardized.
• saves time, because you can leverage an existing ecosystem of libraries/components instead of doing everything by hand.
• makes the code more portable. Not every browser behaves the same way when manipulating the DOM directly.
• makes the app bigger.
• will probably at some point introduce a fight against the framework.

Doing it by hand

• provides a great learning experience of fundamental web technologies.
• may be more performant.
• is probably smaller.

While I admire your hands-on DIY mentality, I (as a possible contributor) would not start to learn something that I can not reuse in other projects, be it commercial or private. For closed-source one man projects (like eg. photopea) this is perfectly fine, but for open-source software (and such a cool one ;)) and the sake of collaboration, I (personally) would try to be highly standardized.

What would I do?
I'd probably go with flutter, because I find it very intuitive and modern. Dart is very cool and it compiles to numerous target systems, including the web. It would be interesting to see, if it's possible to, do but I highly expect it to.

Just my thoughts on that topic :)
Greetings from germany!