Earlier quoted context omitted.
> PHP code which supports being interspersed with HTML You're one of a large number of people who say this, but it is false. PHP intersperses a programming language with static strings. Those static strings frequently adhere to HTML syntax, but that's aside from PHP. What is HTML? It's not random strings; it's a syntax. JSX is much closer to interspersing HTML with a Turing-complete programming language than PHP ever…
You're technically correct, but I don't think the distinction adds anything to the conversation. I don't know if PHP was the inspiration for JSX, but if the strings they were using in PHP was HTML, then it could have been. EDIT: Sounds like JSX was inspired by XHP: https://www.facebook.com/notes/facebook-engineering/xhp-a-ne...
What if we'd had better HTML-in-JS syntax all along?
101–110 of 170 posts
Re: What if we'd had better HTML-in-JS syntax all along?
#102We'd have PHP in the browser.
if php had a html-in-php syntax, that might be true. but as anyone who has ever worked with php and jsx knows, this isn't true
You can also just switch in and out of PHP to an HTML block.
Re: What if we'd had better HTML-in-JS syntax all along?
#103What if html would use round brackets and just use the closing bracket instead of the closing tag?
e.g. foo
could be:
(html (body (div 'foo')))
Something similar could be done for javascript. Instead of writing html in javascript we could write javascript in html. Just imagine if we could represent the code as html or in that round bracket form:
function inc (x){ return x + 1; }
could be:
x 1
or with round brackets:
(function inc (x) (+ x 1))
Re: What if we'd had better HTML-in-JS syntax all along?
#104This reminds me of a very cool property of the Lua language that allows for very neat "syntax extensions", and reminds of functional languages too: If you have two expressions adjacent to eachother, it evaluates to calling the left-hand side with the right-hand side as a parameter. At its simplest: function foo(text) print("Foo:", text) end foo "bar" But you could implement a JSX-lite in it: function Div(props) retur…
In fact, since objects and arrays are one and the same in Lua, one can even do away with the nested calls, which also simplifies things visually: Div { id = "outer", Div {id = "innerA"}, Div { id = "innerB", Div {} } } This works because when you omit the key (id=) of a table item in Lua, it is assumed to have a incrementing numeric key.
I wonder if Netscape hadn't collaborated with Sun if JS would have had a more pure implementation of prototypes, and how those might have been leveraged more minus all the confusion from mixing in Java-like syntax on top of JS's object model.
Re: What if we'd had better HTML-in-JS syntax all along?
#105Something close to this is possible already in JS, I'm working on a library for generating HTML in node, heavily inspired by Haskell's blaze and lucid. Example code: div( { class: "table-responsive" }, table( { class: ["table table-sm", opts.onRowSelect && "table-hover"] }, thead(tr(hdrs.map(hdr => headerCell(hdr)))), tbody( vs.map(v => tr( mkClickHandler(opts, v), hdrs.map(hdr => td(typeof hdr.key === "string" ? tex…
This actually already exists as a library. This type of syntax is called Hyperscript[1], and it's existed (at least) since 2012. [1]: https://github.com/hyperhype/hyperscript (Although this library does not look maintained anymore)
Re: What if we'd had better HTML-in-JS syntax all along?
#106> I have a theory that a grave mistake was made in 1995 - the decision not to have a neat, succinct and declarative way of representing html elements in javascript. It may be interesting to recall that initially the only way to output HTML was by `document.write()` using strings (which was pretty declarative). The genuine way of generating HTML in JS were various methods of `String.prototype` for generating HTML form…
> It may be interesting to recall that initially the only way to output HTML was by `document.write()` using strings (which was pretty declarative). I think people also forget how slow a lot of JS was really until V8. I remember having server code generate JS arrays (creating them from an xhr request was too slow), that in turn would document.write (manipulating the DOM was also super slow) data on the client to make…
Re: What if we'd had better HTML-in-JS syntax all along?
#107Re: What if we'd had better HTML-in-JS syntax all along?
#108> I have a theory that a grave mistake was made in 1995 - the decision not to have a neat, succinct and declarative way of representing html elements in javascript. It may be interesting to recall that initially the only way to output HTML was by `document.write()` using strings (which was pretty declarative). The genuine way of generating HTML in JS were various methods of `String.prototype` for generating HTML form…
So, if initially there were no Array nor Object constructors (there were arrays and objects, but only prepopulated ones, representing anchors, forms, etc, found in the document), how were arrays done in a script? function MyArray() { this.length = 0; } function arrayPush( value ) { return this[this.length++] = value; } function arrayPop() { return this[--this.length]; } MyArray.prototype.push = arrayPush; MyArray.pro…
o = new Object
o.foo = 'bar'
a = new Array
a[0] = 'baz'
But functions were constructors function hello() { return this.name }
function Person(name) {
this.name = name
this.hello = hello
}
new Person('James')
Array push var length = 0
a[length++] = 'foo'
a[length++] = 'bar'
Actually it was not bad for scripting language, no WAT: new Object + new Array
//null is not a number
No `typeof` (so no `typeof null`), better `parseInt` parseInt("foo")
//0
Much better start than ECMAScript 1Re: What if we'd had better HTML-in-JS syntax all along?
#109https://github.com/samuelgoto/proposal-block-params#kotlins-...
Re: What if we'd had better HTML-in-JS syntax all along?
#110Earlier quoted context omitted.
You can also take a look at mithril.js implementation of hyperscript [0] [0] https://github.com/MithrilJS/mithril.js/blob/next/render/hyperscript.js
was about to mention Mithril. solid framework, but not great for large applications.