upvote

points

by quantadev20 hours ago |
comments
upvoteby Gualdrapo20 hours ago|
next
[-]
"If I could wave my magic wand..." at least 2 of 3 of the changes I'd made about the way frontend web is developed, would be about `<template>`s:

1. Making it possible to do something like <template src="..."> and being able to load them from an external source

2. Making them "dynamic"

3 (and the most controversial one) that all CSS, HTML and Javascript (if you don't hate it) could be written natively like QML - one syntax to rule them all.

reply
upvoteby lelanthran4 hours ago|
parent|
next
[-]
> 1. Making it possible to do something like <template src="..."> and being able to load them from an external source

I've done that, requires no build step/npm/whatever. It was posted on HN for discussion a week ago: https://github.com/lelanthran/ZjsComponent

reply
upvoteby quantadev18 hours ago|
parent|
prev|
[-]
As a web dev you probably already know but #1 is slightly similar to `Web Components` but you're right we cannot load a web component right in the HTML where we use it. It makes sense though because if you use an Element in multiple places it wouldn't make sense to have 'src' in multiple places, so ultimately some kind of 'loading' at the top of the page is needed, and that's how WebComponents work, but I still like how you think.

#3 is a tricky one syntactically because HTML needs to be used by mere mortals and JS is a programming language used by us gods, so unifying all three would br tricky, but again I agree with you that would be awesome. Maybe some flavor of LISP would be both "powerful like a language" and "easy like a document".

reply
upvoteby rictic19 hours ago|
prev|
[-]
The system described in the article is very React-like, and could be used by future versions of React. In both, functions return a description of HTML to render, which can be applied either to create new HTML or to update previously rendered HTML.
reply
upvoteby nwienert18 hours ago|
parent|
[-]
I skimmed part of it, but unless I missed some huge caveat I think you’re backwards and GP is definitely right. The article mentions React, then sort of dismisses it later saying the other two strategies are better to implement instead of diffing.

I don’t see any reason a browser level “here’s new DOM you diff and apply it” couldn't exist and be a huge win for React and other libraries, with React so much more popular than every other framework combined, and that being a pretty low level API, it makes sense to start there.

Building the overly abstracted thing first is a mistake web API authors have made too many times (see web components).

reply
upvoteby quantadev18 hours ago|
parent|
[-]
I still have hope for Web Components to take off in the figure. I'm a React dev so I don't "need" them, but they may end up being some kind of capability that React can secretly, quietly embed into React core as some kind of optimization if that ever makes sense. Web Components is a great idea, but like I said it's just not quite as convenient as React, so it's currently somewhat irrelevant at least for me.
reply