9 ms·
Hyperscript Tagged Markup: JSX alternative using standard tagged templates
- sddfd 8y agoHow is this different from lit-html? https://github.com/Polymer/lit-html https://github.com/Polymer/lit-html
- domenicd 8y agoHTM is React-compatible, and has all the React semantics: e.g. you can interpolate attributes (with ...${foo} instead of React's ...foo) and tag names (with <${foo}> instead of React's capitalization-dependent <Foo>). In other words, HTM is a drop-in replacement for JSX that avoids the need for a compiler by using the corresponding language features. (At the cost of a few extra ${}s.) lit-html and its ilk render directly to the DOM. They give similar developer ergonomics to React/JSX, but don't integrate with that ecosystem. They aren't a drop-in replacement for a JSX compiler within your React app; they're more of a competitor to the entire React paradigm. Also of note is that, as a drop-in replacement, HTM is properties-first, like React/JSX. lit-html has you use different syntax for properties and for attributes. Both are cool!
- johnhenry 8y agoI wouldn't describe it as a "drop-in replacement". It's very similar in the way that it allows one to use html syntax within javascript, and I appreciate the fact that it doesn't require and extra compilation step. But it does appear to be lacking what I see as the main draw of %eact -- the ability to compose and remix components. (Correct me if I'm wrong?) Edit: Composability does appear to be a feature. I agree with your description.
- Scarbutt 8y agolit-html can't be used server side.
- ricardobeat 8y agoThe original project that google ripped off can do SSR: https://github.com/WebReflection/viperHTML https://github.com/WebReflection/viperHTML
- deleted 8y ago[deleted]
- bcherny 8y agoThis is a neat syntax, but it doesn’t seem at all typesafe (typesafety was the main benefit of JSX over the various string templates that came before it).
- ricardobeat 8y ago> typesafety was the main benefit of JSX Do you have a source for that?
- pspeter3 8y agoI don't know if there is a primary source but it is one of the main benefits for me.
- bcherny 8y agoMy opinion, not a fact. Before JSX came out, there were tons of templating systems that let you embed HTMLish things in JS: Handlebars, Mustache, EJS, Pug, Angular templates. JSX’s big innovation was taking the way XHP promoted HTML to first class syntax and applying it to JS. The big difference between that and the template systems that came before it is JSX is statically analyzable (by your type checker, or by other tools), which means you can scale it to FB scale.
- ricardobeat 8y agoWhat I was thinking is that you're backdating your impressions. JSX came out in 2013, when TypeScript was at it's infancy, and also predates flow; support for JSX in the TS compiler was only added in late 2015. You're right that when it came out it's main innovation was separation of concerns and composability, but types or static analysis were not part of the value proposition at the time.
- bcherny 8y agoYou know, I think that’s a really fair way to look at it. I would be surprised, though, if down the line type safety wasn’t a design goal. It did come from the same company that built XHP around 2010, and the same dude that built the first React prototypes in OCaml. I can ask around after the holidays and see if anyone remembers :)
- deleted 8y ago[deleted]
- mbostock 8y agoThis is lovely for using React or Preact in Observable! https://beta.observablehq.com/@mbostock/hello-htm https://beta.observablehq.com/@mbostock/hello-htm We have our own lit-html-inspired html tagged template literals that render directly to DOM, but it’s nice to see HTM’s improved support for function attributes (e.g., onclick), spread attributes, etc.
- spankalee 8y agoI love that work! Eventually we'll get some great parts of this approach standardized, starting with Template Instantiation, and we'll finally have a great way to create and update lots of DOM from data right in the platform. A future d3 based on that would be very awesome too :)
- leowoo91 8y agoCan we go back to Jinja now?
- eksemplar 8y agoDid we leave jinja? I mean, I know I know, but we still do a lot of jinja on our smaller projects.
- coder543 8y agoWhy go back?
- leowoo91 8y agoI wanted to phrase it as a circle, just waiting to see how far SPAs can go.
- mrweasel 8y agoMaybe it's just me being an old man at this point but I still dislike doing templating in JavaScript. It's not natural. I want Jinja2 and server side rendering. If you absolutely must do JavaScript you should keep it separate of your HTML and other stuff... again maybe I'm just getting old. Honestly I don't find neither JSX, or this new alternative particularly readable.
- leowoo91 8y agoYoung is just learning it hardway, we all have been there. Creating walls of abstractions as well as enduser's greed for edgy feel that is turning into easy profit.
- allover 8y agoYou can use Jinja-style templates client-side too if you want (see nunchucks). But client-side rendering and server-side rendering have different use-cases. It doesn't come down to just which is 'particularly readable'. > If you absolutely must do JavaScript you should keep it separate of your HTML and other stuff Why? This argument has been lost. If you're writing a rich client-side UI that makes sense to be "component-oriented", there is literally zero value in splitting each component into HTML and JS, it is a completely arbitrary 'separation by technology'.
- dixie_land 8y agoTIL https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals#Tagged_templates https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... I'm not a JavaScript developer so this is news to me, very neat feature!
- simlevesque 8y agoHere's a list of tagged template literals: https://github.com/declandewet/common-tags https://github.com/declandewet/common-tags
- reificator 8y agoWhich brings up a question: Is it possible to have multiple tags on a given string? Composing smaller helpers would be nice, but I don't see how the syntax would work.
- simlevesque 8y agoYou'd just need to create a meta tagged litteral function. tagged litteral can accept parameters.
- drivingmenuts 8y agoSo,I guess mixing presentation and logic is OK now? 'Cos as a PHP programmer I used to get shat on all the time for that and I'd like a chance to, you know, unload on someone else for a change. NM, I'll just go back to my cave now.
- wild_preference 8y agoThere's presentation logic vs business logic. Tracking whether a button is disabled or not is presentation logic. Projecting a snapshot of business state onto a presentation is also presentation logic. "Old school PHP application" style seldom made a distinction. Also, you must add indirection (bad) to split things apart, and indirection doesn't necessarily pay its own rent. An example would be putting an ajax api request (a client's business concern) into a component where the <button> exists that triggers it. Collating that logic with the UI is nice until you want to reuse the logic, and it's usually cheap to extract it from a component, so you can often add indirection on an as-needed basis as you scale.
- stevebmark 8y agoGood thing "logic" isn't a concern and separating view code from view code doesn't make sense ;)
- stevebmark 8y agoThe nice thing about React, vs others like Vue and Angular, is that we've learned not to write code in strings. You'd think this would be a fundamental law of software engineering, but we keep seeing things like v-bind:id="'list-' + id" or <button [style.color]="isSpecial ? 'red' : 'green'"> or this. Writing code, not strings, means you can do everything to it that you can do to code. You can type check code. You can lint it. You can optimize it, compile it, validate it, syntax highlight it, format it with tools like Prettier, tree shake it... That's why I like JSX, it's Javascript all the way down. Everything is code. It's a very well designed and thought out DSL.
- Bizarro 8y agoI wrote React for a couple years and was pretty dogmatic against the whole "stringy code" thing. Obviously and generally, we'd rather write code not in strings. But guess what? Moving to Vue from React was a major productivity boost for us - "stringy code" and all.
- rickycook 8y agothat as the case may be, id say that was in spite of the “stringy code”. the point (i think) is that this, and JSX are functionally the same thing, but there are some very large issues with doing this in a string. *edit: clarity
- boubiyeah 8y agowhat if it being more productive for you has nothing to do with these magic strings? :)
- BigJono 8y agoI'm calling bullshit on all these claims of "massive productivity boosts" when switching to Vue. What on earth were you doing in React that was so unproductive? Maybe if you're bogging yourself down with a bunch of absolute garbage like immutable and redux-saga, but you can hardly blame React then.
- 8y ago
- qwerty456127 8y agoIMHO the name choice (htm) is really bad.
- ricardobeat 8y agoWe've arrived at the point where the majority of developers have never seen a .htm file!
- mattbierner 8y agoI’ve written tooling to support lit-html and styled-components in editors. Template strings are sort of nice to write but complete pain to support in editors. They are just like a macro language, so you end up with stuff like: `<${tag}>...<${tag}${slash}>` which is not possible in jsx. Even just detecting syntax errors is a pain Obviously if deciding between making life easy for editor implementers or making life easier for coders, the coders win, but if something is unnecessarily difficult to build good tooling for, that’s a sign of poor design in my book. And coders will ultimately suffer too because their tooling will suck and because their code will make use of all the crazy flexibility the library allows.
- spankalee 8y agoThanks for all your work on the lit-html plugin! I think though that the concern here is a little misplaced given the constraints that HTM and lit-html work under - which is that the template strings themselves, without the values, have to be well-formed because they're passed to the HTML parser without values. In HTM, `<${tag}>...<${tag}${slash}>` is not possible to interpret as a possibly self-closing tag because self-closing tags are expanded before values are written into VDOM. In lit-html `<${tag}>` is not allowed at all. So we know what the tag name will be, and what attributes and properties are bound. The same amount of type-checking is possible as with JSX.
- thedonkeycometh 8y agoNice try, Angular.
- mhd 8y agoI remember when everyone suggested their own way of s-expressions (basically) to avoid having to write superfluous end-tags and other XML/HTML tchotchkes, now we're getting multiple ways to get all the markup boilerplate into our programming language. Sometimes it's weird how tastes change. Same thing happened with the nigh universal hacker-ish dislike of "bondage and discipline" languages, now it's enforced formatting wherever you look.
- BigJono 8y agoThere's so much money in web apps now that your average team is flooded with mediocre devs. These joints need "bondage and discipline" languages and frameworks to be productive. It's better business value to have your 50 work-a-day devs productive than your 2 rockstars.
- lucideer 8y ago> Improvements over JSX With the exception of html comments, these are invariably antifeatures. Optional quotes/closing tags save zero to negligible typing time in exchange for added complexity for tooling and reduced readibility in many circumstances. I can understand why these features were added to HTML5 (backward compatibility is of more benefit than prescriptivism) but I would never have thought anyone would argue that having these features in HTML1 was a good idea in retrospect!? Adding them to a new syntax that isn't burdened with backward compat requirements seems daft.