[RELEASE] GlueDOM: JSX alternative to make non-trivial components easier to read and maintain

Following this article, here it is:
https://github.com/gluecodes/gluecodes-glue-dom

Comments

[neoan]

This solves a problem we should not have. This is the JavaScript ecosystem in all it's insanity! Think about it: the first step was moving from imperative to declarative syntax (remember AngularJS 1.x).
Then we violated separation of controller and view by building component based, making it necessary to compile a interpreted language into another version of itself !? Eventually React came along and for no good reason whatsoever - I cannot stress this enough: without facebook behind it nobody would have picked it up - it took the lead over way more superior solutions. So now we have tools that completely abolish markup to overcome the insanity of JSX we should have never dealt with in the first place. Why don't we solve the actual problem instead of providing tools as band-aids. Meanwhile we have built so many layers that we need a multiple of the computing power that brought us to the moon just to have our webpack deal with the billions of packages we through at it to whip up the most basic React hello world.

[Aneudys Amparo]

My hate to React JS is JSX, remember those time when people judge PHP because view a business logic was in same file. Now we have it with React, there are not official architecture or folder structure on how it must be organized. Many of them came from Angular. Another comes with Styled-component: don't get me wrong, they are cool' but more sh*ts.

[neoan]

Indeed, that's the problem. I have seen clean React code. But sadly, it's the exception. If the lib/framework doesn't force developers into a structure, it easily becomes a unmaintainable catastrophe. There is a reason why "opinionated" has a positive connotation when it comes to coding.

[chris-czopp]

Well said, that's why apart from this little lib, I've been working on something that may provide alternative to the whole React one day ;) Especially when writing data management apps.

[neoan]

Be sure to let us know if you have a MVP. I applaud the boldness to look at the status quo and dare to question itin order to come up with true innovation. It's a big task, but somebody will succeed. It might as well be you

[chris-czopp]

Sure, here is a website: glue.codes and MVP: ide.glue.codes The docs are still pretty weak so there will be stuff that is not very apparent. Until the docs aren't ready, I'm happy to walk ppl through if interested.

[neoan]

I played around a little and indeed am a bit lost without solid docs. I was especially confused about where the plugins get inserted and how the providers work. Assuming you will post when you are ready, I'll follow up when that happens.

[Seanmclem]

I really like jsx.

[chris-czopp]

In my view it works well when writing a function component that doesn't contain conditional logic (especially nested). Then, instead of HTMLish it becomes hard to read due to overused logical and ternary operators. If you want to use if statements, it becomes a mix of HTML and JavaScript and it doesn't look like a markup language anymore.

[neoan]

Agreed! The most common tasks any templating must fulfill is conditional rendering and iteration. Both aren't solved well in JSX.

[Seanmclem]

Neither trouble me at all in jsx. There are very easy ways to implement both things

[neoan]

Okay. And in comparison to what alternatives do you prefer it? I am asking as in my opinion people tend to know little alternative approaches.

[Seanmclem]

As opposed to working with regular HTML, razor pages, AngularJS or Angular's HTML implementations, and vue's. I've used them all. Not just in hobby projects but pretty extensively in my career. After spending much time with each I definitely prefer jsx the best

[neoan]

Okay. And why is that? What does JSX solve nicer in your mind?

[Seanmclem]

I so consistently need to control my html with Javascript. Feel like the separation of HTML and JavaScript doesn't really make any sense in modern Frameworks. Angular and Vue both try to shove a half-baked attempt at integrating js into their HTML and it comes off very difficult and limited. Something like v-for="video in playlist" inside html makes a lot less sense to me than using a js map to loop over an array to return markup

[neoan]

Feel like the separation of HTML and JavaScript doesn't really make any sense in modern Frameworks

These concepts are about separation of view and controller, not JS and html. And with monitors becoming bigger and frameworks compiling into components anyway, I personally hope the trend of holding both of these concerns in one file dies again. I would prefer having the view and the business logic next to each other, rather than stacked or worse - like often seen in React code - intertwined. So my perspective is a completely different one: declaration should happen in the view but state managed in the controller. And then "limiting" the view to bindings, iterations and conditions simply makes a way cleaner application.

That said, one can of course have different opinions on how markup for these cases should look like. But I would boldly and unapologetic claim that wanting to "not separate" is not an informed opinion and that clean and testable React components don't do that either. Or am I misunderstanding your point?

[Seanmclem]

but they are not separated. The respective frameworks have pseudo JS in the HTML anyway. Since it's not actual JS -it's not as useful or flexible. Other frameworks html often feels like a hacky, unstable way to try and be plain HTML but be dynamic.

But typically, there is still separation anyway in frameworks like React. Separate UI components live separately from each other. The UI logic of a component makes sense to be right alongside the UI view of a component. There's no reason they need to pass data between 2 files to each other when they are only ever concerned with each other.

You are completely flexible to join or separate anything you want anyway. I prefer the freedom, and I love that JSX has become its own thing completely separate from just being a Facebook thing. It works very well to be parsed into an AST. Which allows it to have great intellisense, linting, other IDE plugins, transformations, transpiling to other languages, etc etc.

[neoan]

Let's maybe start by defining what separation of concern is. You seem to make the destiction based in what you consider JS and what you consider HTML. Strictly speaking, JSX is not HTML. It's a template engine. And a template has certain things it should "take care of" and things it shouldn't. And of course you can and should separate these concerns with React just like when using anything else. The only reason to argue for the "freedom" of mixing up business logic and templating is if you don't want to follow this separation.
What you consider "pseudo JS" in other frameworks is the binding between markup and JS. As a simple example:

...
const [val, setVal] = useState('')

return (
   <input value={val} onChange={ev =>setVal(ev.target.value)/>
)
...

Here our "HTML" binds to our state which is absolutely okay for templating and belongs there. The markup is a question of taste, of course, but nothing wrong with this.

...
return (
   <div className="some">
     {props.condition ? (
         const parseCondition = ()=>{
            // Let there be mess
            ....
         }
         ...
      ):null}
   </div>
)
...

In this extreme example we start mixing business logic and templating. And that will have issues with scope next to being a mess in itself. And I am sure you wouldn't write like that, bringing us back to the question: what freedom are you missing in alternative solutions?

JSX and other solutions need to be compiled. So wether or not business logic and template are in the same source file is again completely irrelevant from a functional perspective. It would just force clean code hence I would personally prefer it.
Linting is also completely irrelevant as all popular frameworks have a solution for popular IDEs (and only Vue when used as UMD would have valid markup without bundlers and IDEs taking care of things).

Lastly, being only concerned with one isolated UI component is not achievable in reality. At the end of the day, you will always have a page/route handling props, listening to events or passing down callbacks. Especially because we want to limit coupling separation of concern is so important.

Anyway, all if that doesn't mean that JSX isn't a nice solution. It just happens to be the worst when comparing it to Angular or Vue. And it is always hard to believe for me when people say they have spent extensive time as professionals with all these solutions and then say that JSX is most solid. In all honesty - and I really don't mean to offend - I tend to believe that either the complexity of the applications they built wasn't high enough or they are exaggerating the amount of time spent on different solutions.

[chris-czopp]

Angular and Vue both try to shove a half-baked attempt at integrating js into their HTML and it comes off very difficult and limited

I agree with @seanmclem . I'm a big fan of separation of concerns and keeping UI as dummy as possible. And the templating languages provide kind of API/contract. I even had a chance to develop one and I soon realised I need to provide more flexibility. My problem with templating languages is that they are still mix of HTML and pseudo JS (e.g. loops and conditionals). I understand using attributes in a declarative way (passing strings) to tell renderer what is what, but having kind of inline JS in them is just too much. Therefore, I decided to develop a pure JS syntax which is always consistent, even in edge cases and can be easily generated from HTML (codepen.io/Czopp/pen/zYKRrXo). How to constrain it so developers (especially less experienced) don't make a spaghetti out of it might be done by linting or at transpiling.

[Seanmclem]

We can agree to disagree then. JSX works best for me in everything that I do. I would caution passing judgement on everyone who doesn't agree with you..

[neoan]

Didn't mean to judge, it's more of a disbelief that one can come to that conclusion. So sorry if that sounded too harsh

[Seanmclem]

Well I have worked with many other formats and I take pride in my informed decision of preference

[chris-czopp]

Absolutely, you should take pride of your informed tech decisions. The nice thing about this industry is a large choice of tools which I believe drives the progress and innovation.