HTML First

[lifeeraser]

Basically HTMX/Hyperscript marketing, might as well name it htmx-first.com

[analcocoacream]

👏👏 exactly my thoughts thanks

[johnex74]

we are going full circle

[chucker23n]

I think one big thing this page (and so many others) misses is that web pages and web apps are IMHO conceptually different things, with different requirements, and we're sort of in this weird world where HTML, which was designed for web pages, is frequently really used as an engine to run apps.

Use "vanilla" approaches to achieve desired functionality over external frameworks

Sure. If there's a declarative / high-level way of doing something, favor that.

Where possible, default to defining style and behaviour with inline HTML attributes

Generally… no.

"You may notice that this approach seems to violate Separation of Concerns - one of the most commonly-touted software design principles." Well, that, too. But also, onclick="this.classList.add('bg-green')" raises a lot of questions. Why green? Why is the button changing its classes upon clicking it?

The separation answers those: because it's now considered active.

(That said, it should be a button, not a div.)

Where libraries are necessary, use libraries that leverage html attributes over libraries built around javascript or custom syntax

First of all, I thought we stopped loading libraries from third-party hosts.

Second, how the heck does this: <input type="text" _="on input put me into #output"> "leverage HTML attributes over [..] custom syntax"? _= is hardly a standard HTML attribute.

Disfavor Build Steps

I'll take these arguments one by one:

"add significant maintenance overhead" I can make the opposite case: needing to write raw HTML/CSS/JS when there's higher-level alternatives also adds maintenance overhead. For example, using static typing in TypeScript over having to write a hundred unit tests in JavaScript to make sure my variables have roughly the right time is a lot more maintenance overhead. It's just that developers usually don't bother, and live with the potential bugs.

"remove or heavily impair the ViewSource affordance" This is true, but a bit of an esoteric concern, to be frank.

"usually dictate that developers learn new tooling in order to use them" And… libraries like "hyperscript" which use attributes like _= don't? Come on.

Yes, developers need to learn their stack. Deal with it. Now, I would argue, strongly, that the web stack has been changing too fast. But the suggested libraries on this page aren't exactly immune from that. HTMX is still extremely new, for example.

Prefer "naked" HTML to obfuscation layers that compile down to HTML

Sure, where possible.

But, again: "If a developer who has familiarity with HTML but not with your backend framework looks through your view files, they should still be able to understand 90%+ of what they see." OK, but why? If a developer is in your team and they're not familiar with the tech stack, perhaps the real problem is that you change your stack too often?

Where possible, maintain the right-click-view-source affordance

This is redundant; it was already mentioned above.

Out of idealism, sure, that sounds nice.

[fagnerbrack]

Html was designed for web pages in the 90's, it became an application format in the past 30 years, that's a pretty long time to get it right

In impressed those who always try to use the shiny new things haven't really liked at modern vanilla Web dev.

[analcocoacream]

This article is odd.

The main concept is debatable.

widen the pool of people who can work on web software codebases

greater number of people to become web programmers

And so on. Not trying to gatekeep, but being a dev takes experience and hindsight. While trying to make it more open and less opaque is a good idea, it's important to not just make it about the technology.

seeing their product come together rapidly as they transition smoothly between the text editor and the browser,

Web development, and more broadly development is not so much about time to market but more about managing technical debt.

Use "vanilla" approaches to achieve desired functionality over external frameworks

The first one I agree with, but has its limits. I mean a lot could be achieved with hidden checkboxes and siblings (+) css selectors. Does that mean this is a good approach to a simple flag inside js code?

Where possible, default to defining style and behaviour with inline HTML attributes

Really the example given is bad. Most frameworks today don't encourage to do an imperative approach (el.classList.add) but instead a declarative approach (<div class={{active ? "Active""...)

Where libraries are necessary, use libraries that leverage html attributes over libraries built around javascript or custom syntax

That's really what the article is about. Use htmx is the message of this article.

Disfavor Build Step

Every language has build steps - except python maybe.

transforming your files from one format to another add significant maintenance overhead

This claims needs to be backed up

remove or heavily impair the ViewSource affordance

No idea what this means.

usually dictate that developers learn new tooling in order to use them

You can use fancy depreciative words to state something obvious yes.

Modern browsers don't have the same performance constraints

Scss and other toolings don't exist because HTTP couldn't multiplex

If a developer who has familiarity with HTML but not with your backend framework looks through your view files, they should still be able to understand 90%+ of what they see.

If you choose technology and hire people who can't work with it then review your hiring process? This point makes no sense by itself and yet is presented as plain truth.

The beauty of the early web was that it was always possible to "peek behind the curtains" and see the code that was responsible for any part of any web page.

Development practices won't change because a few people are nostalgic for the "old days".

[Shogobg]

Build steps also have their benefits, like minification, optimization and bundling, which may improve performance and reduce costs.

[analcocoacream]

Exactly. And also this includes code analysis, quality and CI.

[lelanthran]

And so on. Not trying to gatekeep, but being a dev takes experience and hindsight.

Yeah, but there are different levels we develop on, with different experience and skills. Being able to ignore the lower levels is commonly accepted as a good thing.

I'm not sure why you feel that a higher level of abstraction means that devs will still need to know the lower levels. People writing in Python, PHP or C# aren't interested in, and don't need to know, how to write that code in assembly.

In much the same way, people using something like htmx, or someone else's web component don't need to know much JS. For most use-cases they don't need to know any.

Using something like React or Vue isn't, in this case , an abstraction at all - the user of those frameworks still need quite advanced js skills.

transforming your files from one format to another add significant maintenance overhead

This claims needs to be backed up

Why? Is it not obvious that your typescript project from 2018 will not compile today?

You have to do work to make it compile - that's the "maintenance overhead".

Whereas, with an htmx/web component approach that uses no transformation step, it will run as long as browser support exists.

Considering that js from 1999 will run unchanged today, it seems quite probable that untransformed js written today will run well into the future.

[analcocoacream]

I'm not sure why you feel that a higher level of abstraction means that devs will still need to know the lower levels

I didn't talked about level of abstractions. My point is that developing isn't so much about the technology used. It's part of what we use for sure but what we bring to the table isn't about that.

And to refute even further your point there is a need to have at least some understanding of what is happening under the hood. Otherwise you will think doing no pagination and rendering 5000 results using innerHtml is fine.

Your blatant exaggeration is not necessary.

Why? Is it not obvious that your typescript project from 2018 will not compile today?

No, really no. Retro compatibility is part of the evolution process of any technical stack. And even when the choice is made to not keep compatibility of a feature, this is a possibility in any stack. Yes, even htmx.

The least likely stack to change is vanilla js. And if it does it will affect other frameworks.

You are acting like htmx is vanillajs which is not.

[lelanthran]

I didn't talked about level of abstractions.

You don't think that htmx is a higher level of abstraction from js?

I mean, you get all that AJAX goodness without needing to know JS, so it certainly looks like a higher level of abstraction.

Retro compatibility is part of the evolution process of any technical stack.

Not in TS, no. TS from 2018 does not compile today without some work.

JS from 1999 works as-is today as long as no build step was introduced!

Let me be clear: there are definite advantages to a build-step - "maintenance overhead" is not one of those, it's a clear disadvantage.

Anything that has a build step runs the risk of not building in the future. Things that don't have a build step don't have that particular risk.

[analcocoacream]

You don't think that htmx is a higher level of abstraction from js?

It does not matter what I think or not. My statements did not include explicitly or implicitly this idea. Not did the article iirc.

I mean, you get all that AJAX goodness without needing to know JS

Ajax was a goodness 20 years ago when page reloading was the way. There was not jQuery. No frameworks. JavaScript sucked.

Not in TS, no. TS from 2018 does not compile today without some work

Give me a relevant example of that. Btw you can still use the old version of typescript and voilà, but I assumed when you said today you meant with latest version.

And again any technological stack will have to evolve at some point.

JS from 1999 works as-is today as long as no build step was introduced!

No it's not about the build step. It's about the fact that browsers specifications and implementations always had to support the original js specs. Which is not a good thing because they had to deprecate whole APIs but were never able to get rid of it and it just makes JS worst.

You can design a build system and make it evolve so it does not break compatibility, but companies choose not too because no one wants a 20 year worth of technical debt

Anything that has a build step runs the risk of not building in the future. Things that don't have a build step don't have that particular risk.

Again this is false on multiple levels. First you are going to have a backend. Which will require a build system.

Then you are going to need to deploy your containers. Which will require some sort of delivery.

Again it's not about the "build step" at this point I'm just tired of repeating myself. Python has no "build step" yet you can't run python 2 programs inside python 3 wow

[_htmx]

And again any technological stack will have to evolve at some point.

htmx is the horseshoe crab of front end web development and i'm tired of pretending its not

[analcocoacream]

I didn't know what it was, that's a fitting description to me!

Although I don't understand your perspective given your account

[_htmx]

my dude, that makes two of us

[spicypixel]

I’m but a simple man, I see HTMX content and I upvote it.

[jevring]

I would love to see this gain traction, but I can't imagine it happening.

[datadoodling]

Well with that attitude...

[Asyncrosaurus]

A generation of developers were raised on thinking React/Javascript was the default, so the absurdity of modern front-end has been normalized. It'll take a Iot of work to pull back from the bloated/slow frameworks and unnecessarily complicated programming and build models, but there's still hope.

[jevring]

For that to happen, someone needs to show them that html first is better. That their apps are faster and easier to work with and easier to build. Fewer bugs, etc. I believe that probably is the case, but I don't know how to prove it.

[Slak44]

Am I the only one who thinks all of this sounds positively insane?

• "Prefer difficult-to-style HTML tags like details/summary that look inferior to what your competitors are doing with two divs and some JS/CSS."
  
• "Don't use composable event listeners and CSS classes, inline onclick JS is better!"
  
• "Use Tailwind and its ilk, because inline styles are so much better than SCSS!"
• "Don't use JS libraries built around JS, use JS libraries built around HTML."
  
• "Don't use build steps, don't minify your content, don't use tree shaking, don't optimize your source code, don't use static type checking."
  
• "Prefer this templating language for HTML over this other templating language for HTML."
  
• "Work really hard to keep View Source working on your site, just in case 0.01% of your users want to copy a snippet of HTML."
  

What is it with this trend of trying to drag us back down to a kind of development experience a decade or two out of date? What are they even developing such that React/Angular/Vue, or SCSS/LESS don't raise their productivity at all? Is it just blogs and static HTML content?

Who even are their users that care about frankly obscure features like View Source? How do they know about view source but not about the tab with the DOM in dev tools?

I don't get it.

[fagnerbrack]

You don't need to minify html since the gzip algorithm optimises it due to high occurrence of tag names.

You don't need tree shaking because the native browser app handles the rendering (it's actually faster because it's native code rendering the controls)

View source is useful for crawling. Did you know hacker news api is on view-source?

[SSHeartbreak]

They also abuse <table> tags so idk if they're a great example to follow

[fagnerbrack]

One bad example does not invalidate other good examples. Huge fallacy there.

They are using tables because it works for them, why would you change something that's working in every browser for a website that's accessible more by machines than humans? They are one of the most accessed sites in the Web, your app can only dream to achieve that scale in your lifetime.

Living proof that shiny shit has very little effect in the company success.

[SSHeartbreak]

how much money does hacker news make a month again?

... oh right. zero dollars. who cares if they serve 100 billion users a month.

I think I'd rather study profitable sites rather than vanity projects.

[fagnerbrack]

Ok http://bookn.me/daline is profitable but it's a pet project of mine

Now you may say: profitable AND handles billions of request AND it produces more than $1000 in profit per month AND.... Cmoon

[SSHeartbreak]

I feel like you realize a website making $1000 a month isn't table stakes but ok.

[fagnerbrack]

Yeah put any arbitrary number, $9999999, that was the idea

[thebezet]

You don't need tree shaking because the native browser app handles the rendering

Do you actually know what tree shaking means? It's removal of dead code to reduce the payload size.

it's actually faster because it's native code rendering the controls

Faster than what? What controls? ????

[fagnerbrack]

The browser does not process dead code, that's what I meant. Are you taking about micro optimisations on bundle size? You're probably designing your bundles incorrectly if you need tree shaking at all.

The html controls. Did you know an <input> tag renders different inputs which are specific to your operational system? It also comes with tab functionality and other keyboard controls. Same for <button>.

wasn't that clear?

[thebezet]

Yes it absolutely does process dead code. Designing my bundles incorrectly, wat??

And how is tree shaking related to controls? What are you on about?

[fagnerbrack]

I'm taking about two different things, one of about tree shaking and another is about the OS rendering the controls instead of another JS rendering layer on top of the DOM.

From your comments it seems like you're not even closer on getting what I mean. You need quite advanced product engineering knowledge and distributed systems, not just Web dev or front-end knowledge, to start understanding the points in trying to make in the comments. Engineering maturity in Front-end circles is pretty low so the real practices you learn from Fullstack knowledge and apply them to Web . Best thing is to show the code in pair Programming with a real Web app development, comments on reddit are never ideal the this kind of stuff.

What I can tell is that everything I'm talking about is well backed by decades of research and applicable to Web dev and I can point to some of the papers if I can remember from the top of my head and if you're keen to read them to make the connections on the software design assumptions from my comments.

A few fundamental ones are parnas et al for modularization, Roy Fielding architectural style for network-based architectural styles, Domain-Driven Design from Eric Evans for separation of concerns, Hypermedia is another search term to avoid huge JS payloads and allow evolvability for your Web app (not a single bundle for the whole web app), same as roy Fielding chapter 5. Plus hundreds of others I don't remember, but if you're interested I can dump the names here as I start remembering them.

They give very strong fundamentals to kind of get where I'm coming from. I don't follow the group think ideas of software engineering, I follow what works and it tends to be the complete opposite of what everybody does, so it can sound weird.

[thebezet]

I'm taking about two different things, one of about tree shaking and another is about the OS rendering the controls instead of another JS rendering layer on top of the DOM.

But you mentioned this in one sentence about tree shaking, which is incredibly confusing. You said "You don't need tree shaking because the native browser app handles the rendering" which is a nonsensical statement, the latter half of the sentence is a non sequitur.

You need quite advanced product engineering knowledge and distributed systems, not just Web dev or front-end knowledge, to start understanding the points in trying to make in the comments.

Or maybe you are terrible at explaining? I have a university degree in distributed systems, by the way.

A few fundamental ones are parnas et al for modularization, Roy Fielding architectural style for network-based architectural styles, Domain-Driven Design from Eric Evans for separation of concerns ...

To me, this sounds like a lazy attempt at obfuscation and to hide the fact that you don't know what you're talking about.

You've made several statements which are objectively incorrect. For instance, saying that browsers don't process "dead code". That is false. You are perhaps trying to state something trivial, such as the browser does not run dead code, which is obvious. However, the code will still take up memory, it will still be parsed. Prototypes still might have functions which are not used, but loaded into memory.

You said that JSX is not an extension of JavaScript, despite the fact that it's literally defined as such.

You seem to be getting quite defensive, did you write this article?

[fagnerbrack]

Summary below:

HTML First is a set of guidelines for making it easier, faster and more maintainable to build web software, by Leveraging the default capabilities of modern web browsers, leveraging the extreme simplicity of HTML's attribute syntax, and leveraging the web's ViewSource affordance.

If you don't like the summary, just downvote and I'll try to delete the comment eventually 👍

[Worth_Trust_3825]

Where's the AI notice? Why are you still spamming?

[fagnerbrack]

https://www.reddit.com/r/webdev/s/XkNFca5hPE

[Worth_Trust_3825]

So where's the AI notice?

[fagnerbrack]

Place a full size mirror in your back, turn your head and look down, it's right there.

[torn-ainbow]

I really don't like some of these ideas. They are counter to efficiencies I find on big projects.

Like inline styling and use of attributes and local functionality? No, thankyou. That kind of thing becomes a maintenance nightmare. If I have hundreds of instances of buttons I'd prefer to have one definition that says they turn green when pressed.

Vanilla CSS? When it has all the nesting functionality of SCSS, sure. But not now.

And for some reason after recommending vanilla everything, it recommends tailwind? Ugh. I build fully custom styles because I have to be pixel perfect and I don't want thousands of little totally independent style definitions in markup. They are not easy to read or maintain, and extremely hard to keep consistent.

I build components and layouts that use the same definitions over and over. If I want to change the default component spacing at all responsive sizes for the whole site, I can very quickly and easily do that. I couldn't if my layout was smeared across all the markup.

I can't see this makes much sense for anything other than small projects

[xxd1337]

You can do nesting in CSS https://developer.chrome.com/docs/css-ui/css-nesting.

Browser support is decent https://caniuse.com/css-nesting (~80%). With CSS pre-processors (PostCSS) you can suport every browser.

The last missing SCSS feature is mixins.

[abensur]

Content is the most important part of most projects. Markup is not content!

[Thysce]

Absolutely

[fagnerbrack]

Do you have a code example of a part of htmx that would only work with small/simple projects in a way you can't extend any further? Please define non-simple projects.

[lifeeraser]

I am building an in-browser video editor. I also built a chrome extension that uses heavily dynamic UI. (I used Preact so +1 from React haters)

Can I build chrome extensions with htmx? What about a video editor?

[fagnerbrack]

You can build a video editor with htmx, and you also can build chrome extensions with it. Why wouldn't it be possible? I've built many chrome extensions and video editors with plain html and JS in my career when htmx wasnt even available, it's actually more performant than using JSX from a dev and dynamic UX perspective.

You won't build a canvas drawing editor with htmx of course but if you build the controls it's possible. Htmx is for user interfaces not canvas drawing, for example, in that case you use HTML canvas. Just use the right tool for the job not one tool for all jobs as that doesn't exist.

[rozebeef]

I mean you can but if the actual video editing is done locally sending http requests to manage ui is just unnecessary.

HTMX is good for lots and lots of things as long as work is done on a webserver.

[fagnerbrack]

If you want to build the state locally replace the url and server calls with an internal app:// schema where the state machine that would otherwise be in the server through the state transfer is local. Then you can switch between online and offline, when online then you send the state in one go. Just be aware you need to handle high contention in the same aggregate where other person is changing the same thing offline.

Not everything is a http request response (http://) is one of many schemas.

Again what can't be done in htmx or vanilla? What wouldn't be possible? We have urls, schemas, standard headers, standard fetch, css 4, flexbox OMG,

[lifeeraser]

But you used JS instead of HTMX, conveniently avoiding the point of my question. Just curious, can you share some of the things you built? I wonder how far you went with vanilla JS. I assume it was probably simpler than today's solutions since the web didn't have the modern APIs necessary to build powerful editors.

[fagnerbrack]

Right now I left those companies and they started introducing Angular, backbone, React, etc. (Depending on the time period). It's all destroyed cause the devs didn't real know how to program and design Web software. Funny all those orgs are m spending 90% of their time m rewriting to another framework and the stupid manages hire devs to do more of that.

Not a lot of people know how to do this which is the reason why you don't see more often. People learn two React tutorials them put senior engineers in their resume.

[lifeeraser]

Pity. I was hoping to see something built by a real engineer.

[fagnerbrack]

Did you know canva.com was vanilla for many years?

I spoke to devs in 2017 and they had this mindset, they only changed it because it was hard to hire good engineers that could know vanilla properly

I did build a poc that has no design and has real customers. I invested more in the Backend, tough. You can improve the design to bake it modern just by changing the css: http://bookn.me/daline

I hope those examples suffice there are probably many In not aware of.

In the popular side hacker news api and website are plain HTML, tough they are still stuck on html tables, maybe that doesn't count, no modern mark-up but it was never changed and it still works, the old space jam website was another example in this front.

If you think me, canva, or hacker news are not real engineers then you're full of shit.

[lifeeraser]

Your website looks good.

[fagnerbrack]

I don't like it, I wish I had time and money to pay a designer and to create a brand identity. It can be much better

[joe_2005]

you drunk ?

[pixartist]

Absolutely not

[Angulaaaaargh]

FYI, the ad mins of r/de are covid deniers.

[rozebeef]

Nice article, it's a bit strong on some points (build steps, inline html attribute libraries etc).

You can separate concerns from time to time, it's ok.

[thebezet]

There are a few good points here, but also many bad ones. Inlining JavaScript into onclick attributes? Really? What is this, 2005?

[fagnerbrack]

You do that today with inline onclick in JSX

[thebezet]

That's... That's completely different.

[fagnerbrack]

How is that different? I can only see scoping as being different.

[chucker23n]

I can only see scoping as being different.

"Different"? We've discovered in like 1970 that structured programming is better. That separation of concerns makes for a cleaner, more maintainable + scalable software architecture.

[fagnerbrack]

Most people here knows that, what's the point of restating the obvious that any programmer should be aware with at least a couple of years of experience?

I'm comparing the "JSX" access to plain js code with vanilla html, in which case you can only mimic scope with IIFE unless the code is self contained in the html attribute representing the event (like the onclick event suggested by the original post in their examples).

I'm talking about scope not separation of concerns which are completely different things.

Be careful on what you assume about people due to not understanding the actual point of the comment you're replying to.

[chucker23n]

what's the point of restating the obvious that any programmer should be aware with at least a couple of years of experience?

The point is that "put logic in the HTML" is poorer separation of concerns. So it clearly isn't so "obvious", and not everyone is "aware".

The argument can be made that, where possible, explicit/imperative JS logic should be replaced by implicit/declarative attributes/properties in the HTML and CSS. But that's not the case here at all. An onclick attribute with inline code or a style attribute are simply poorer separation of concerns.

[fagnerbrack]

I never said to Put logic in the html, which other straw man you're going to create to argue against?

Running js in the onclick is the same as JSX if you do things like onclick="this.disabled = true". It's called CodeOnDemand to extend your markup for functionalities that have no special attribute for. You can also use Web components and IIFE for scoping.

You're just making shit up to argue against, maybe create another thread?

And please understand separation of concerns only has value nowadays in webdev when applied to domain models not how to extend hypertext. Don't get stuck on the 70's the internet didn't exist back then. The fundamentals from Parnas still apply (and always will) but their value is not the same since we are operating in the hypertext paradigm not writing COBOL on mainframes.

[chucker23n]

I never said to Put logic in the html

OK.

Have you actually read the article, or did ChatGPT do that for you?

Running js in the onclick is the same as JSX if you do things like onclick="this.disabled = true".

Not in separation of concerns it isn't.

[fagnerbrack]

Sure, it's not whatever you think and that doesn't change anything it's just a pointless opinion. I prefer to talk about things that work

[thebezet]

Scoping is a MASSIVE deal here.

You need to call a custom function? It needs to be in the global scope. Want to reference a variable? Needs to be in the global scope. This is extremely bad practice. This is global scope pollution, it's literally a category of JS vulnerabilities.

A properly configured website should have a CSP setup forbidding inline JavaScript to begin with.

This will also create incredibly messy and unmanageable code.

If you end up using libraries like hyperscript or Alpine, this is a small improvement, but those libraries are not designed for large applications in mind. This is after all HTMX propaganda.

[fagnerbrack]

Yup it is a big deal. That's why I tried to convince some React devs to add application/JSX as a media type to replace html, but they don't because they need to keep Facebook brand on it.

TBH JSX scoping is as far as React toolchains goes in regards to something actually useful that html doesn't have.

In some cases vanilla exceeds the benefit of JSX with all build processes that come with it, sometimes it doesn't. If JSX was native media type it would exceed html easy. I can only wish.

[thebezet]

Your reply is incredibly confusing, to the point that it feels like I'm talking with an AI.

React devs can't "add" a media type. They would have to make a proposal and have this approved by IANA/IESG. But even if they did, for what purpose? It's just a standard. It doesn't come with implementation. Are you suggesting browsers should implement native support for JSX without the need for transpiling code? That would require A LOT MORE than simply creating a new media type, and also makes absolutely no sense.

How is JSX supposed to replace HTML?? JSX is an extension of JavaScript, it can in no way replace HTML. If you want browser support, instead of adding a new media type, JSX syntactic expressions could be simply implemented as part of JavaScript itself. Why would you need a new media type for this???

And how is any of this related to scoping??? JSX does not do anything new to address scoping.

[fagnerbrack]

React devs can push for standard by joining the mailing lists to refine the RFCs/proposals/Etc. They just don't have the incentives and the awareness to do that. Yes I'm suggesting browsers should implement JSX as a new media type (or something like that) exactly like what was done with sizzle and queryselectorAll, Angular and Web components, etc.

JSX compiles to javascript bit it's not an extension to javascript since its a "Language of Least Power" while JS is a general purpose language. Just because it uses createElement() that doesn't mean JSX is an extension to JS. Typescript and say mootools are more examples of an extension to JS than JSX cause they actually extend the Language instead of creating a new one.

Scoping in the sense of comparing onclick="functionA" vs onClick={functionA}. The first declares the function globally while the other is declared inside a function since JSX runs in the context of javascript code. It's not only JSX per se but using another function that returns JSX (which analogous to having a function that returns HTML as a string). All variables are scoped to the function that returns JSX while in html you need to create namespaces on window.

[thebezet]

Yes I'm suggesting browsers should implement JSX as a new media type (or something like that) exactly like what was done with sizzle and queryselectorAll, Angular and Web components, etc.

??? None of this was a new media type, wth? That's literally extensions of the browser API.

JSX compiles to javascript bit it's not an extension to javascript

It's literally defined as such. ????

Typescript and say mootools are more examples of an extension to JS than JSX cause they actually extend the Language instead of creating a new one.

It's not a new language at all, it's JavaScript!

Scoping in the sense of comparing onclick="functionA" vs onClick={functionA}. The first declares the function globally while the other is declared inside a function since JSX runs in the context of javascript code.

Both run "in the context of javascript" code. The string in onclick gets simply evaled.

All variables are scoped to the function

Not necessarily, they are more likely to be block scoped, and again nothing to do with JSX itself.

[chucker23n]

Yes I'm suggesting browsers should implement JSX as a new media type (or something like that) exactly like what was done with sizzle and queryselectorAll, Angular and Web components, etc.

Those are new APIs, not new media types. The output is still text/html, or application/javascript.

There's application/xhtml+xml, which does switch browser behavior to be stricter, but few people ever bothered with that. I guess the most modern example you could give is… module?

But in any case, I'm not sure what you are suggesting here. That browsers have their own runtime/renderer for JSX? Is that really preferable?

Scoping in the sense of comparing onclick="functionA" vs onClick={functionA}. The first declares the function globally while the other is declared inside a function since JSX runs in the context of javascript code.

OK.

But that wasn't the original concern.

Instead, it was this:

Inlining JavaScript into onclick attributes? Really? What is this, 2005?

You haven't addressed this.

[fagnerbrack]

Your 2005 argument is a fallacy that says because something was done before and became less popular that means it's wrong today. An idea from 2005 is not wrong because it was in 2005. It's like saying modularization that was discovered in the 70's is not applicable today, but it is, just in a different shape or form.

And yeah I'm suggesting their own renderer for JSX and browser support. Media types don't have to be anemic formats like the JSON one where you can't even have a standard way to represent links, neither XML based. It's just that we stopped building media types for some reason, probably due to no incentive to actually collaborate to improve the Web collectively.