Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What if we'd had better HTML-in-JS syntax all along?

leontrolski.github.io

Post reply on HN
Print view View original

151–160 of 170 posts

Re: What if we'd had better HTML-in-JS syntax all along?

#151

Post by sub7 »

baggy_trough wrote: post #85
sub7 wrote: post #83

HTML in JS feels so wrong, I'll never get used to React-land. Feels like the simplest 2 page, 2 action apps now need a hundred modules, all kinds of weird naming conventions and config dependency spaghetti and of course a complex build system for what would otherwise be a few lines of plain old JS. Rails 6 now webpacks 100s of KB of js for a new blank app. wtf if going on.

Yes, it's some weird cargo-culting nonsense for sure.

Absurd. And I get down voted by scriptkiddies who write button click handlers all day while thinking they're implementing low level OS buffer caches.

Re: What if we'd had better HTML-in-JS syntax all along?

#153

Post by BerislavLopac »

matwood wrote: post #87
masswerk wrote: post #20

> 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…

> creating them from an xhr request was too slow

You had XHR? Luxury! We had to embed a 1x1 px Java applet to communicate with the server without reloading the page! ;)

Re: What if we'd had better HTML-in-JS syntax all along?

#154

Post by kroltan »

kazinator wrote: post #132
kroltan wrote: post #122

Earlier quoted context omitted.

I don't have the sources right now, but I once watched (not attended!) a presentation that talked about how JS was initially intended to be a language more like Lisp or Smalltalk, but was changed into an OO language to appease the heavy marketing at the time.

The duo of Lisp and Smalltalk basically define what OO means . Javascript simulates some of the aspects of OOP in an ad hoc way by turning every object into a hash table so that properties can be tacked onto it. It's what you implement if it's Wednesday, and the boss asks for a some sort of working OOP system by Friday.

You're right I was half asleep when I wrote the previous comment, I am very sorry. I meant a C(Java?)-like language. Which I am aware has nothing to do with OO, just syntax style.

Re: What if we'd had better HTML-in-JS syntax all along?

#155

Post by blacksqr »

pjmlp wrote: post #144
TedDoesntTalk wrote: post #57

Earlier quoted context omitted.

There was also the the idea that JavaScript was just one way of scripting the page. VisualBasic Script (VBScript) had momentum in IE releases. The general idea was that the user-agent was going to be able to parse multiple scripting languages, the list of which would probably grow as time went on. Think native TypeScript parsing in a browser today!

ActiveState had browser plugins for Perl, Python and Tcl. I think they were IE only via COM extensions.

Netscape had a plugin API and there was a Tcl plugin for it. As I recall the Netscape API was the de facto standard for as long as plugins were a thing, so the Netscape plugin was usable in conforming browsers.

Re: What if we'd had better HTML-in-JS syntax all along?

#156

Post by holtalanm »

brlewis wrote: post #100
holtalanm wrote: post #89

Earlier quoted context omitted.

was about to mention Mithril. solid framework, but not great for large applications.

What issues have you encountered that make it not great for large apps?

it has been a few years, so maybe these issues have been addressed at some point since I used it last, but:

1) there were multiple issues with deeply nested object models not being reactive within the UI code that cause me to explicitly call m.refresh (can't remember the exact api, as it has been a while, but the function that was called forced a virtual dom refresh, which was _not_ good for performance). I ended up writing a debounce function that would make sure the m.refresh function only got called once per paint at the most, which helped, but it was just a band-aid over the underlying problem, which was that the framework was not detecting reactive property changes within deeply nested models. At the time I was using it, there was no other remedy according to issues that had been brought up on stack overflow.

2) this is probably personal opinion, but the hyperscript model for structuring html, while it looks good on paper, lends to a really tedious process of writing html-generating javascript.

I guess I didn't need a numbered list. Those were my main two gripes.

Re: What if we'd had better HTML-in-JS syntax all along?

#157

Post by thayne »

dmitriid wrote: post #139
thayne wrote: post #128

Earlier quoted context omitted.

Webcomponents should help with this. Although the current API is not as pleasant to use as react.

They can't and they won't. Because they rely on DOM APIs to do anything useful. Which brings us back to the article.

What does that have to do with having composable components?

Re: What if we'd had better HTML-in-JS syntax all along?

#158

Post by brlewis »

holtalanm wrote: post #156
brlewis wrote: post #100

Earlier quoted context omitted.

What issues have you encountered that make it not great for large apps?

it has been a few years, so maybe these issues have been addressed at some point since I used it last, but: 1) there were multiple issues with deeply nested object models not being reactive within the UI code that cause me to explicitly call m.refresh (can't remember the exact api, as it has been a while, but the function that was called forced a virtual dom refresh, which was _not_ good for performance). I ended up…

For (1), m.redraw() is async; I don't think you have to debounce anymore. The autoredraw system may be more sophisticated than when you used it, too. https://mithril.js.org/autoredraw.html

For (2), I've been using JSX with Mithril the whole time. My team and I didn't like deeply nested hyperscript either. (At my employment we're in the process of moving away from Mithril, but I'm still using Mithril 2 in a side project)

Re: What if we'd had better HTML-in-JS syntax all along?

#159

Post by mercer »

irrational wrote: post #145
kalleboo wrote: post #137

Earlier quoted context omitted.

The other major uses of JavaScript were hover-over-button effects, and scrolling text in the status bar

Oh my. I'd forgotten about scrolling text. Why did we do that? LOL

What a magical time... I remember being wowed by having a string of text follow my mouse around.

Re: What if we'd had better HTML-in-JS syntax all along?

#160

Post by jdmichal »

rimliu wrote: post #148
jdmichal wrote: post #60

I have a hypothesis about a different way to organize responsibilities within webpages. I think the split of "content" to HTML and "presentation" to CSS was a mistake. To me, those are both describing content. That is, the author's intent to emphasize a particular part of text, whether via tags or CSS, is part of the content. I think there was a missed opportunity to instead split page layout into its own technology.…

It was not a mistake. The theory being that HTML describes the structure, and CSS describes the presentation. Do not forget, that there are other ways for the page to be rendered: e.g. in screen reader or for print. We had "HTML and CSS living together" with FONT and BGCOLOR and friends. It was not nice. Sad to see people wanting to get it back. We are finally comming to realize that maybe rendering HTML on the serve…

You're grinding an axe that has little to do with what I said.

Your defined split of "structure" and "presentation" is orthogonal to my choice of "layout" and "content". Currently both HTML and CSS define layout and content. Layout being defined as the positioning and arrangement of panels within the viewport, and content being defined as the material displayed within those panels as the author intended. That emphasized part is important.

The issue with styling in HTML had nothing to do with the use of tags and everything to do with the fact that they could not be classed. So the chosen tags had to be duplicated in entirety for every instance, which was a maintenance nightmare. Later versions of CSS saw it become more powerful than the original HTML tags. (Aside: This makes it ironic that it seems to be becoming idiomatic to inline styles for HTML templating. Templating solves code duplication, so it no longer requires classing.)

But the HTML+CSS tools for layout are extremely primitive. There's lots of things to point at here. One simple one is that HTML often has superfluous structure that is required only for the CSS-defined layout to work. A more complex one is that it difficult for me to say I want the footer either at the bottom of the viewport or at the bottom of the content, whichever is lower.

Post reply on HN