5 ms·

Define "compatible with the language". Anything you shove into a string and then parse yourself is "compatible with the language". Doesn't make it better or si

Define "compatible with the language". Anything you shove into a string and then parse yourself is "compatible with the language". Doesn't make it better or significantly different from systems that do this step earlier.

rektide 4y ago
Compatible with the language seems like a dead obvious concept to me: something you can do with the current TC39 EcmaScript language. Anything you do with JSX isnt compatible with the language. So that makes it worse & significantly different. Diving way into technics, tagged template strings, if called from a function, will have reference equality for the literals array. The optimizations might not be ahead of time, but the net is, even if the tagged template string is inline and single-phase (as opposed to moving your tagged template strings to the top level & having them "compile" & return a function to accept variables/children), there's still a lot of room for reusing the same "compiled"/parsed work.
- dmitriid 4y ago
  > Compatible with the language seems like a dead obvious concept to me: something you can do with the current TC39 EcmaScript language. Most JS frameworks are written in JS. You can run React, Svelte, Vue etc. directly from the browser without a build step. > Anything you do with JSX isnt compatible with the language. So that makes it worse & significantly different. So, this is an artificial and absolutely arbitrary line that only looks good because you chose it to be so. Also, JS world is probably unique among all programming languages with such aversion towards anything even remotely resembling compilation. Which is ironic, given that transpilation (aka converting from non-existent and future syntaxes to existing one) is Javascript's bread and butter. > The optimizations might not be ahead of time, but the net is > there's still a lot of room for reusing the same "compiled"/parsed work. As opposed to what? To compilers/transpilers that can, and do, the same thing? And can do significantly more things like run whole-program optimisations. Or, like Solid, can just remove the need for components in the resulting code. The world already agreed about 40-50 years ago that programming with strings is a bad idea. And now JS purists are willing to die on this hill (while inventing bizarre justifications and increasingly bizarre DSLs for anything remotely complex, see lit-html). And of course there's nothing wrong, or "worse" with DSL, or compilation. As evidenced by compiled frameworks being blazingly fast: https://krausest.github.io/js-framework-benchmark/2023/table_chrome_110.0.5481.77.html https://krausest.github.io/js-framework-benchmark/2023/table... and
  - rektide 4y ago
    > JS frameworks are written in JS. You can run React, Svelte, Vue etc. directly from the browser without a build step. incredibly fantastically hugely incorrect. JSX is not supported in EcmaScript! Vue3 is not supported. the way we in fact do use these tools is not supported. i've said that so many times already & you keep making these absurd claims otherwise. it's just not so (not unless you take extreme & vast detours off the mainstream & hand author lower non-JSX react, which no one and few libraries do). it's not in any way unclear that you've been wrong the whole time but you keep generating longer & longer posts & making more and more noise each time. but you've been in the wrong this whole time & it's just obvious & clear. JSX is not supported in EcmaScript. again and again and again I keep having to say it. it requires tooling to reduce a superset of the language down; the browser's js engine is not capable of parsing code with jsx in it. this is intensely self-evident yet you protest & make a large hard to deal with confusing scene here. again: jsx is not valid ecmascript! > So, this is an artificial and absolutely arbitrary line that only looks good because you chose it to be so. so now you seemingly maybe actually sideways-admit the truth, but you want to defend the other side... after having repeatedly made confusing claims there is no such line... please man, it hurts to get dragged through this. your whole first arguments seem dishonest & misrepresentative. and this second half admits the truth, but tries to smokescreen & cloak the basic obvious truth in painful new contorted ways. i meam, really, omg, what? are you frakking kidding? this isnt "arbitrary". this is a quite clear line: things the language can do, and things that require outside tooling to do. jsx and vue3 (im unsure about vue2) require tooling, because as I have said multiple times already the language does not support them. as much as you protest, that's for sure how it is. > As opposed to what? To compilers/transpilers that can, and do, the same thing? fuggin exactly; holy heck, yes! a thing in the language as opposed to something that has to rewrite your code because the language cant do that thing (jsx, vue). frelling heck dmitiriid, nearly everytime you show up in my replies it's full of huge long dissembling. you are telling lie after lie after lie, sowing absurd confusion & doubt over basic assertions, flooding the zone with shit. like this hummdinger of an overstated opinion-as-fact: > The world already agreed about 40-50 years ago that programming with strings is a bad idea. get off it man. this vastly overrepresents a particular chosen preferred view, & is nothing more than a malice-ful way to browbeat & condescend. if there's a tagged template string that works just as well as jsx, but actually works inside the language, you're ready to browbeat & bully it... because there's quotes around the content? i've already cited htm, which seems basically to prove this potential, but you're just gonma use nastiness & snark to degrade that potential, to disregard it out of hand? dimitiriid, this is how your replies to me keep going. i really really hate it. your words show intense favoritism towards what you want to believe time & time again & are just incredibly callous & short & browbeating against anything you dont want to think about. this dogmatism is intensely unpleasant to deal with; i'd really like to see a reformed & much more honest & engaged form of discussion when you reply to folks/myself, where other people are allowed to also have opinions, or I'd really appreciate you opting out of replies to me, to reduce these ultra long winded back & forths that feel so vastly unpleasant & infinitely useless. you never ever acknowledge that maybe perhaps other views are possible. > And of course there's nothing wrong, or "worse" with DSL, or compilation. they can have be worth it for some people, at some time. but. i think there's room for people to express a desire not to deal with this shit. just authoring code & having the browser run it has attraction, has some merits. needing more work- external build processes- is in many ways clearly & obviously worse; we just shouldnt have to be taxed like that every single time we want to do anything. these are worse, in many (but not all) dimensions.

rektide 4y ago

Compatible with the language seems like a dead obvious concept to me: something you can do with the current TC39 EcmaScript language. Anything you do with JSX isnt compatible with the language. So that makes it worse & significantly different. Diving way into technics, tagged template strings, if called from a function, will have reference equality for the literals array. The optimizations might not be ahead of time, but the net is, even if the tagged template string is inline and single-phase (as opposed to moving your tagged template strings to the top level & having them "compile" & return a function to accept variables/children), there's still a lot of room for reusing the same "compiled"/parsed work.

dmitriid 4y ago
> Compatible with the language seems like a dead obvious concept to me: something you can do with the current TC39 EcmaScript language. Most JS frameworks are written in JS. You can run React, Svelte, Vue etc. directly from the browser without a build step. > Anything you do with JSX isnt compatible with the language. So that makes it worse & significantly different. So, this is an artificial and absolutely arbitrary line that only looks good because you chose it to be so. Also, JS world is probably unique among all programming languages with such aversion towards anything even remotely resembling compilation. Which is ironic, given that transpilation (aka converting from non-existent and future syntaxes to existing one) is Javascript's bread and butter. > The optimizations might not be ahead of time, but the net is > there's still a lot of room for reusing the same "compiled"/parsed work. As opposed to what? To compilers/transpilers that can, and do, the same thing? And can do significantly more things like run whole-program optimisations. Or, like Solid, can just remove the need for components in the resulting code. The world already agreed about 40-50 years ago that programming with strings is a bad idea. And now JS purists are willing to die on this hill (while inventing bizarre justifications and increasingly bizarre DSLs for anything remotely complex, see lit-html). And of course there's nothing wrong, or "worse" with DSL, or compilation. As evidenced by compiled frameworks being blazingly fast: https://krausest.github.io/js-framework-benchmark/2023/table_chrome_110.0.5481.77.html https://krausest.github.io/js-framework-benchmark/2023/table... and
- rektide 4y ago
  > JS frameworks are written in JS. You can run React, Svelte, Vue etc. directly from the browser without a build step. incredibly fantastically hugely incorrect. JSX is not supported in EcmaScript! Vue3 is not supported. the way we in fact do use these tools is not supported. i've said that so many times already & you keep making these absurd claims otherwise. it's just not so (not unless you take extreme & vast detours off the mainstream & hand author lower non-JSX react, which no one and few libraries do). it's not in any way unclear that you've been wrong the whole time but you keep generating longer & longer posts & making more and more noise each time. but you've been in the wrong this whole time & it's just obvious & clear. JSX is not supported in EcmaScript. again and again and again I keep having to say it. it requires tooling to reduce a superset of the language down; the browser's js engine is not capable of parsing code with jsx in it. this is intensely self-evident yet you protest & make a large hard to deal with confusing scene here. again: jsx is not valid ecmascript! > So, this is an artificial and absolutely arbitrary line that only looks good because you chose it to be so. so now you seemingly maybe actually sideways-admit the truth, but you want to defend the other side... after having repeatedly made confusing claims there is no such line... please man, it hurts to get dragged through this. your whole first arguments seem dishonest & misrepresentative. and this second half admits the truth, but tries to smokescreen & cloak the basic obvious truth in painful new contorted ways. i meam, really, omg, what? are you frakking kidding? this isnt "arbitrary". this is a quite clear line: things the language can do, and things that require outside tooling to do. jsx and vue3 (im unsure about vue2) require tooling, because as I have said multiple times already the language does not support them. as much as you protest, that's for sure how it is. > As opposed to what? To compilers/transpilers that can, and do, the same thing? fuggin exactly; holy heck, yes! a thing in the language as opposed to something that has to rewrite your code because the language cant do that thing (jsx, vue). frelling heck dmitiriid, nearly everytime you show up in my replies it's full of huge long dissembling. you are telling lie after lie after lie, sowing absurd confusion & doubt over basic assertions, flooding the zone with shit. like this hummdinger of an overstated opinion-as-fact: > The world already agreed about 40-50 years ago that programming with strings is a bad idea. get off it man. this vastly overrepresents a particular chosen preferred view, & is nothing more than a malice-ful way to browbeat & condescend. if there's a tagged template string that works just as well as jsx, but actually works inside the language, you're ready to browbeat & bully it... because there's quotes around the content? i've already cited htm, which seems basically to prove this potential, but you're just gonma use nastiness & snark to degrade that potential, to disregard it out of hand? dimitiriid, this is how your replies to me keep going. i really really hate it. your words show intense favoritism towards what you want to believe time & time again & are just incredibly callous & short & browbeating against anything you dont want to think about. this dogmatism is intensely unpleasant to deal with; i'd really like to see a reformed & much more honest & engaged form of discussion when you reply to folks/myself, where other people are allowed to also have opinions, or I'd really appreciate you opting out of replies to me, to reduce these ultra long winded back & forths that feel so vastly unpleasant & infinitely useless. you never ever acknowledge that maybe perhaps other views are possible. > And of course there's nothing wrong, or "worse" with DSL, or compilation. they can have be worth it for some people, at some time. but. i think there's room for people to express a desire not to deal with this shit. just authoring code & having the browser run it has attraction, has some merits. needing more work- external build processes- is in many ways clearly & obviously worse; we just shouldnt have to be taxed like that every single time we want to do anything. these are worse, in many (but not all) dimensions.