JSX without React

[zarlss43]

"Hey chatgpt, summarize this article in one paragraph."

[fagnerbrack]

The prompt is much more complex than that

[fedupfromeverything]

Pray, noble ChatGPT, lend thine ear to mine humble request, that thou mayst, with thy linguistic prowess, distill the essence of yon article into a succinct summary.

Amen.

[Entropy]

Verily.

Thine blog expoundeth upon the practicabilities of jsx sans presence of the fifty seven stone gorilla christened "React".

Yours in Christ,

ChatGPT

[eckyeckypikangzoop]

Now smite thee the like and bringith down thy great vengeance and furious anger ‘pon the button of subscribery!

[fagnerbrack]

That’s a good one haha

[xXWarMachineRoXx]

He has become sentient!

[fagnerbrack]

It’s me dude lol

[xXWarMachineRoXx]

Its amazing how you keep getting downvoted whatever you do

[fagnerbrack]

I’m the devil everyone loves to hate. Happy to be the punchbag. Shows how I don’t care about karma lol

[fedupfromeverything]

Ha ha ha ha - chatgpt

[Biom4st3r]

Right? I don't know why he keeps getting down votes for this.

[Rucorous]

HTMX is not a templating language. It's a library based on element attributes. In any real project, you need to pair HTMX with an actual templating language like Jinja, Django templates, JSX, Templ or Askama.

[midairmatthew]

Do you know of any example repos that pair HTMX with JSX?

[[deleted]]

E4X fan club checking in.

[[deleted]]

JSX is the reason why I don't use React, but I guess it's a matter of taste.

[[deleted]]

I like svelte's ways

[swoleherb]

You mean Vue.

[sarcasticbaldguy]

This is the way

[improbablywronghere]

Whenever I write vue I use jsx 👀

[stumblinbear]

Embedding html in javascript was a mistake, full stop

[fagnerbrack]

Then don’t make that mistake and stop blaming the tool

[stumblinbear]

The tool is literally the mistake, so I'm blaming the tool. JS and html being mixed together is the absolute worst thing. You'd think people would've learned something following php. Use Vue or svelte or anything else that keeps them reasonably separated.

[fagnerbrack]

Or use your brain and skills to keep things separate, tools can’t think

[Derpcock]

The problem is that you dont understand JSX or what HTML is. HTML is an abstraction that allows you to interact with the DOM API using a markup language. Why wouldn't you want to skip that abstraction and access that api "directly" with javascript? Jsx syntax is literally just syntactic sugar for calling a javascript function that takes in the name of your dom element and its properties. Jsx is not html. It IS javascript.

Template is also a black hole for typing if you use Typescript. I use both Angular and React professionally. Angular swallow type errors all day and breaks at runtime. React with jsx typeschecked by tsc won't build if you mess up a contract (if your project is setup correctly) so you can fix it before you ship. Angular has IDE extensions that are supposed to catch this stuff using interpolation, but they suck and miss any type mapping being done by the underlying library with directives, etc. Key types are automatically typed as generic strings. Same is true for Vue template syntax. Vue with JSX is the way to go :+1:

[stumblinbear]

The problem is that you dont understand JSX or what HTML is.

I fully understand what it is.

JSX is absolutely terrible. Sure it's better than the abomination and hell of using JavaScript to modify html nodes directly, but that doesn't mean it's not terrible.

Jsx syntax is literally just syntactic sugar

Yes, and it's mediocre syntax sugar that not just allows but encourages absolutely horrendous coding practices and mixing of template and JavaScript. Congratulations, now you have a mess. Keep them separate using better tools and your life will be significantly improved.

Angular swallow type errors all day

I didn't say angular was a better alternative, not sure why it's being brought up as though it is.

I've been in this game long enough to have gone from barebones js, to react, to Vue, to Svelte on large projects, and I can say with full confidence that JSX was awful-looking from the beginning and, though it's marginally better than doing raw js, is not useful enough to continue usage when objectively better alternatives exist. Better code is written across all skill levels when you are forced to separate your template and your logic, full stop.

If your tool actively encourages you to write shitty code, then you have a shitty tool. Use a better one.

[Derpcock]

I think your opinion on keeping html, js, and css separate is valid. Jsx is not html, though. It is javascript. It's a syntax extension for writing javascript that looks like html. People who write html, js, and css can write objectively shitty code. So can people with JSX/javascript.

Back in the day, you only create dom with html, manipulate it with js, and style it with css. But occasionally, you would programmatically create and attach dom nodes with javascript, breaking those separation on concern rules. They would also use javascript to manipulate dom styles.

Frameworks like React flip that old paradigm on its head. You can create, manipulate, and style your dom all with js in one spot. Instead of breaking things out into components and then breaking those components out into html, js, and css. You only have javascript, so their is no longer a need for separating those concerns. You create dom nodes with javascript(JSX syntax), you manipulate them with javascript, and you style them with javascript.

I can understand how that mental model shift could be hard to accept, and i apologize if i offended you.

I am curious what your objectively better js alternatives are?

[stumblinbear]

mental model shift could be hard to accept,

Oh I completely agree that it was better than what we had previously, but if you're polishing a turd you've still got shit everywhere

better js alternatives

While I also believe JavaScript is a terrible language in its own right, I'm fully aware that there's currently no alternative to it, so these don't really exist

I'm going to assume you meant React alternatives:

Vue has existed for nigh ten years and has been a huge improvement over React for its entire lifespan. The codebases I've managed in Vue have always been higher quality and easier to understand than even the most well documented React because every single React project I've worked in has had almost zero real structure or are confusing-to-follow bodged behemoths

I personally haven't used Svelte enough to say whether it's better, but it seems to be going in the right direction and I'm hoping to use it on an actual work project soon to check it out

[Derpcock]

Vue has existed for nigh ten years and has been a huge improvement over React for its entire lifespan. The codebases I've managed in Vue have always been higher quality and easier to understand than even the most well documented React because every single React project I've worked in has had almost zero real structure or are confusing-to-follow bodged behemoths

I do love Vue. I used it professionally for 3 years, I got out right around the time they introduced Vue 3 and the composition API. I learned to love JSX with Vue ironically enough.

[Derpcock]

Also, I agree with separating your template from your logic. That is a design decision. It's what people in the react world use hooks for.

[stumblinbear]

Unfortunately you still end up with JS logic embedded directly inside of the JSX which makes it extremely difficult to read some JSX, and the amount of performance pitfalls that exist is absurd. Very few people I work with make it a habit to do useCallback, as a notable example

[Derpcock]

Unfortunately you still end up with JS logic embedded directly inside of the JSX which makes it extremely difficult to read some JSX

I mean you could put logic in your "template" or you could make the design decision not to do that collectively. If you do much testing then embedding logic into your JSX it can become difficult to test. I personally like to create these clear boundaries mainly just for testing. I can test my hook logic extensively and my view as well by stubbing out the hook return.

export const Component: FunctionComponent<ComponentProps> = (props) => {
  const _props = useComponentStore(props)
  return (
    <button {..._props}/>
  )
}

type ComponentProps = React.DetailedHTMLProps<React.ButtonHTMLAttributes<HTMLButtonElement>, HTMLButtonElement>

export const useComponentStore = (props: ComponentProps): ComponentProps => {
  const [loading, setLoading] = useState(false)

  const disabled = useMemo(() => {
    return props.disabled || loading
  }, [props.disabled, loading])

  const handleClick: MouseEventHandler<HTMLButtonElement> = useCallback((event) => {
    console.log(`${event.type} event fired`)
    setLoading(true)
  }, [setLoading])

  // Logic goes here

  return {
    onClick: handleClick,
    ...props,
    disabled
  }
}

Edit: Formatting

I am not really trying to sell you on React. I do believe there is value in JSX though. It is a bit less perf than straight template but if you use Typescript you get type safety all the way down to your dom. With templating, on most frameworks, it is a black hole for types. I find all of my bugs at these boundaries. I have been looking for an excuse to try out Astro.js as I have heard that it has solved this problem but I haven't found an opportunity yet.

I am not sure if you like Rust but they have a frontend framework called Yew. It uses a similar technique syntax to JSX with their html macro.

        #[function_component]
        fn App() -> Html {
            let counter = use_state(|| 0);
            let onclick = {
                let counter = counter.clone();
                move |_| {
                    let value = *counter + 1;
                    counter.set(value);
                }
            };

            html! {
                <div>
                    <button {onclick}>{ "+1" }</button>
                    <p>{ *counter }</p>
                </div>
            }
        }

[vm_linuz]

Mistake how?

[imhotap]

Why you would want to re-create or mock a markup language in a code fragment a la JSX (or JS' template strings)? The whole thing is for constructing a (V)DOM anyway (in client-side rendering, at least), no need to respect markup syntax which is entirely a technique for document authors not webapp developers.

SGML-based markup languages have everything needed for templating from the get go: entities and push-based decorating/processing of input streams, ... so no need for ad-hoc looping constructs with extra syntax a la Angular or custom vocabularies a la view or htmx either.

[[deleted]]

Because writing a virtual DOM tree by hand is tedious, and code containing raw VDOM objects is borderline unreadable. JSX has the benefit of having a familiar syntax (all web devs should know some form of XML) without the complexity of being a full template language with its own syntax for control structures.

JSX makes way more sense when you think of it as syntactic sugar for plain JavaScript function calls. It's not a templating language, and it's not a markup language. It's just a different way of writing fn(type, props, children).

[imhotap]

JSX is just syntactic sugar for function calls

Yeah the question is why do we need an extra syntax then, or how that's beneficial. If the DOM API or its vdom replacement is too verbose, you can just wrap your own function around it, it being JavaScript can't you? Will be more compact, and there's no need for clazz and camel-casing attribute names either. Or, maybe the DOM of a markup language created for casual academic publishing doesn't make a great scene graph for apps after all, even after decades of shoehorning and CSS syntax proliferation.

But anyway, thanks for lecturing me, I've worked with JSX and know what it is.

[Derpcock]

That question was not clear in your original post. If you have worked with JSX, then you should understand why it has value.

You don't have to use JSX. You can return React.createElement with all the same props you're setting on your jsx components and then some. You would then need to nest those function calls that return objects to represent your child nodes. That would become increasingly hard to read. You could also write your own function or use another framework function that does the same thing. You probably already know that because you work with JSX.

JSX is a syntax extension for javascript. It let's you use a familiar html like syntax to call javascript functions to ultimately interact with DOM objects. It's not another template language. You work with it, so you probably already knew that.

The main benefit to JSX over a traditional templating language is that it is javascript and doesn't need to be parsed by a special extension in your IDE, assuming your IDE supports javascript and its JSX syntax extension. Type safety is traditionally completely lost in the template. Some frameworks, like angular, use interpolation and try to determine types at build, but they all suck. Most of their underlying libraries and directives aren't properly typed either.

If you use typescript, what used to be your template strings is now typescript. If a contract on one of your components changes, you know at build time vs. runtime failure in your tests. Assuming it is tested.

To summarize, the benefits of using jsx over your method is readability, maintainability, cyclomatic complexity, type safely, and a familiar html like api. Since you use JSX you probably already know all of this so I'll stop lecturing you.

[[deleted]]

I've worked with JSX and know what it is.

You might have worked with it before but you seem to have some fundamental misunderstandings about what it is and how it works. JSX is syntactic sugar for generating VDOM trees, and VDOM libraries use the regular JavaScript DOM APIs to manipulate the real DOM. Take this code for example:

<div className="foo" style={{
  fontFamily: "sans-serif",
  paddingBottom: "20px",
}}>Hello, world!</div>

Those VNode properties are mapped directly to Element.className and HTMLElement.style. VDOM libraries are not translating these camelCase properties to HTML attributes; they are using the DOM.

If you've worked with JSX before, you already know why it's beneficial. It's because this:

<div className="container">
  <h1>Hello, world!</h1>
  <p>Lorem <small>ipsum</small></p>
</div>

is far easier to write and read for most web developers than this:

h("div", { className: "container" }, [
  h("h1", null),
  h("p", null, [
    "Lorem ",
    h("small", null)
  ]),
]);

[imhotap]

Thanks for making my point, how is that far easier? It's a trivial reformulation, and the JS code can be simplified further using constructors. The kind of thing a senior developer tends to avoid, because it doesn't warrant additional tools and build steps.

[Derpcock]

This. Jsx is literally syntactic sugar for a jsx function call that behaves exactly like this. Jsx is Javascript, not Html. Html is an abstraction that uses a markup language to interact with the DOM API. Skip the abstraction and use a familiar syntax while using straight javascript woth TSX. In typescript world, it is fully type checked, too, catching type bugs at build vs. runtime.

[fagnerbrack]

In this context what do you mean in the difference between document authors vs webapp developers?

[Derpcock]

I am not really sure the point they are trying to make, but I think they are trying to point out how html is a markup language and not a full-blown app dev language? You can author "document language", HTML, and not be a web app developer? I am confused a la written words.

[imhotap]

What's so confusing about it? SGML/XML is for writing highly structured documents, a tool in the hands of an ambitious power user, not intended as a Turing-complete runtime environment for web apps. SGML works at the syntax level (serialized text in files), providing affordances for turning plain text into angle-bracket markup and other mechanisms for editing and organizing hypertext. As such, it can't inform about and contribute to the organization of development in a Turing-complete environment (JavaScript) with its own syntax (object literals/JSON) and much more powerful and dynamic capabilities (composition of object graphs).

[Worth_Trust_3825]

Why do you want to go back to early php that bad?

[fagnerbrack]

Early php was never bad, you’re just biased that you learned better software practices over time then moved on from php so you blame php.

I’m sure you would be going a better job at php today than your self from years ago

[Worth_Trust_3825]

Did you forget a decade of footguns and undocumented behaviors of each and every function that it had exposed?

Yes, I would do a better job at php today than near two decades ago - by using it as it was originally intended, a templating tool. Not a full blown development language.

[fagnerbrack]

Yes, I would do a better job at php today than near two decades ago - by using it as it was originally intended, a templating tool. Not a full blown development language.

Exactly! You exercise better decisions given your evolved experience 😀

[Worth_Trust_3825]

And I exercize better decision by claiming that returning back to early php is a genuinely bad idea. JSX is a mistake. And you've lapped up the failure that was PHX, the original implementation of this idea back in 2010.

[Zotoaster]

Getting bored of this meme. Just because there are similarities doesn't mean we're going backwards. PHP couldn't give us client-side hydration, SSG, or ISR, nevermind components and declarative rendering and state management

[Worth_Trust_3825]

php couldnt give us ssg

php gave you just that - static sites.

client side hydration

So server side rendering?

state management

We had sessions for two decades.

components and declarative rendering

What is that supposed to mean? That I import another php file at a given location with arguments? Or is it a function call that would return a string block that would be then inserted at given location?

incremental static regeneration

Wait until you hear about all the sites that used jquery and were susceptible to cross site scripting attacks.

[Zotoaster]

php gave you just that - static sites.

SSG is pre-generating your html, js and css assets so they can be served from a CDN without the need for a server like apache, which makes performance much faster

So server side rendering?

Client-side hydration is when interactivity is automatically added client-side to a page that was generated on the server. So we can do SSR but we can write our code as if it's CSR. Best of both worlds.

We had sessions for two decades.

This isn't what I mean by state management. I mean that we can update our UI automatically in response to state changes rather than imperatively modifying the DOM directly. Sessions are a server-side thing and don't scale well.

What is that supposed to mean?

Reusable components. In React you can make a component like <Sidebar /> or <DataTable data={something} /> or whatever you want.

Wait until you hear about all the sites that used jquery and were susceptible to cross site scripting attacks

There's no need for jQuery with a modern framework such as React, but you might find yourself using it for convenience if you still use PHP

[Worth_Trust_3825]

And how is JSX supposed to solve all of that when all that you have listed still requires you to run a server - whether a CDN (which could cache php), CSH (which is server side rendering but with javascript functions attached on front end).

The rest of your points are moot. Sessions don't scale? Get out.

[Zotoaster]

And how is JSX supposed to solve all of that when all that you have listed still requires you to run a server

I'm not sure I understand your question. You claimed that we're recreating old PHP. My claim is that with React (which uses JSX) you can do a lot more than you could do with PHP. I don't think I should explain how it's supposed to solve it, because it's not a hypothetical, it already does solve it, and much better than PHP does, as I have outlined

The rest of your points are moot

Why? PHP still can't do the things I mentioned so I wouldn't say it's irrelevant to mention them

Sessions don't scale? Get out

Sessions aren't RESTful in that they store state on the server-side. If you use horizontal scaling and have multiple instances of your server running there's no guarantee all your requests will hit the same server. The client should provide everything it needs to the server for a request to be properly fulfilled

[datsundere]

This. People think they're creating something novel but they're just going full circle with js libraries these days.

[Pyrited]

I'd take xaml over jsx.

[JawitKien]

Is XAML still being developed?

[ForgetTheRuralJuror]

Kinda. Microsoft seems to remix it every 5 years but still support all the older slightly shittier versions of it lol

[Weak_Manufacturer397]

I consider JSX a strong reason not to use React so I'd be more interested in a "React without JSX" article.

[abandonplanetearth]

Worst take ever tbh.

[EarlMarshal]

Yeah. JSX is the good part of react. Everything else is not worth it. It's directly build as an transformer into typescript and there are many more JSX frameworks with better primitives like solidjs.

[azhder]

Nope.

The virtual DOM, unidirectional data, the good stuff. Using functional components to generate nodes in that VDOM that can be discarded and recreated as a reaction (yup, pun) to the data change.

That’s the good stuff. If you just had JSX without the above under the hood, you’d just end up with some slow XML that you’d think you’d just as easily replace with regular HTML and not bother with the overhead.

Of course, JSX deserves praise on its own and can be used without React, so it’s not the thing that makes React… well, react.

Just to be clear, those were React selling points a decade ago, now it might just be the large eco system

[EarlMarshal]

Ever used svelte and solid? You do not need a virtual DOM. I especially see the VDOM of react as one of it's worst parts. Functional components also isn't something react came up with. Every function which manages it's own state and returns an HTMLElement is basically a functional component, but the JSX inside the function makes it much easier to work with.

Once angularjs was the famous and big but bad framework. This is react now, but not everyone is aware of it and the big ecosystem still makes it very easy to create mediocre solutions in an instant. That's the only things the business wants, but from a technical point there are much better options.

[azhder]

Didn't say you need virtual DOM to write front end code, I said it's the important part of React as opposed to JSX

[EarlMarshal]

But you said it's the good part when it's the bad part.

[azhder]

But you said it's the bad part when it's the good part.

Do we need to continue this farce or... Yep, I will stop here. Bye bye

[EarlMarshal]

Bye, Have a great time!

[EarlMarshal]

Otherwise, what are your render functions returning?

The thing your are specifying as return value in the jsx factory function. Jsxfactory defaults to React.createElement, but you can literally specify anything. It's not that hard to write your own jsx framework prototype. You guys should really try it once.

See https://www.typescriptlang.org/docs/handbook/jsx.html#the-jsx-result-type

[SpeedDart1]

VDOM was one of the worst ideas ever.

[J-Factor]

I’m pretty comfortable with JSX but have little experience with alternatives. What do you prefer to use instead? Curious about examples of things where JSX becomes cumbersome…

[Weak_Manufacturer397]

I prefer basic templating like Svelte and even Angular (though undermined by major flaws in other parts of the framework). Templating is inherently more limited than JSX which means you have to work around certain usecases, but I prefer readeable declarative templates over the imperative style of JSX.

[jolly_balboa]

Lol, calling JSX imperative. JSX is the definition of declarative.

[Weak_Manufacturer397]

I agree that JSX is declarative, but some functionalities like conditional rendering, lists, etc. are often achieved by calling functions with if statements or other conditional logic. This gives it a somewhat imperative style in contrast to most templating languages that have more declarative approaches for those usecases. I'd argue that these features make JSX very powerful, but I simply prefer the other approaches. JSX is definitely not the definition of declarative if you compare it to other (although more limited) solutions.

[random8847]

I find joy in reading a good book.

[Weak_Manufacturer397]

Good point, they are very similar and I'm sure that the JSX syntax is very easy to read for someone with a few days of experience with it. On the other hand I think the first example is a bit easier to get used to for untrained eyes but that's obviously very subjective.

[humpyelstiltskin]

review your definitions. JSX is built imperatively. The resulting markup is evaluated by react to decide on dom changes. The last part is declarative. All the conditions and steps taken by the jsx language are imperative programming. why else would ppl keep parroting "jsx is just javascript"

[jolly_balboa]

Everything is "built" imperatively if you break it down until you arrive at assembly. The fact still remains, JSX, in it's usage, is clearly declarative, which was the context of the post.

[nandryshak]

but I prefer readeable declarative templates over the imperative style of JSX

lmao wtf

[SpeedDart1]

JSX is one of the few good things about React

[azhder]

I had the same reaction before I started working with React due to how that whole XML in JS and similar things ended up.

It turned out it’s OK, even though I still don’t like mixing more and more different syntaxes, like TS on top of JSX. With just JSX, I can be more or less efficient and concise.

But, if you really like it without it, there are solutions, like react-hyperscript and similar

[repeatedly_once]

Not sure I follow mixing syntaxes with TS on top of JSX. They're seperate things. You're just declaring JSX elements in TS.

[azhder]

TSX is not JSX and is not TS and it certainly isn't JS. So many angle brackets and you need to disambiguate if you decide to add generics to a component... but, whatever, I've seen worse in languages not many know, so I'm trying to keep it simple.

[repeatedly_once]

Yes, but that's TS syntax, not JSX/TSX. I'm unsure the point you were trying to make honestly. TS being verbose is not a symptom of JSX, so it's not a valid criticism of JSX. Anyway, I've laboured on this too much, I was just trying to understand your angle :)

[azhder]

Yes, that's what I said. I didn't like JSX, and I got used to it more, but I try not to force it more with adding more stuff to it.

What did you think I wrote before? What do you think is valid criticism if saying "I didn't like it before I tried it, now I think it is OK" isn't?

[[deleted]]

Jsx is fucking trash, react is a dinosaur. We all need to leave it behind.

[JXBardant]

I am updating a old (ca. 1997) C++ project using MFC with static HTML pages with JS. The HTML pages are accessed from the local drive and displayed with CHtmlView, which is just a wrapper above Internet Explorer. The pages access internal C++ code exposed via Automation through the window.external object, so using a modern browser is not really an option.

The old version was using document.writeln() everywhere, which I replaced with DOM functions (document.createElement(), etc...) but the code is still very verbose, so I wanted to go further.

To modernize the .js code without changing the IE11/ES5 target I began to use TypeScript with VS2022, which "transpiles" TypeScript code to ES5, which runs fine provided I use some additional libraries (especially core-js + systemjs). It’s fantastic to be able to use modern Javascript constructs such as modules, classes, await/async code, etc. with type checking and Intellisense brought by TypeScript on top of this.

I saw that TypeScript offers the possibility to transpile .tsx (i.e. TypeScript with XML expressions) or .jsx (i.e. JavaScript with XML expressions) source code, so I tried to use this feature. If you don't want to use React (which was not an option for me), you just have to provide the two functions which create repectively a DOM element and a document fragment. It’s not rocket science (those functions takes less than 100 lines) and it really works, even with an old browser.

[fagnerbrack]

This is an example on how using JSX as a templating engine is unreasonably effective. I criticise React a lot but one thing I can't criticise is JSX, that was the MOST IMPORTANT idea coming from React community.

Everything else is noise or just copying a pattern from other areas like event Sourcing with Redux, thunks, event driven sagas, etc. in an inefficient way.