Passionate generalist conquering the web one project at a time. Whether authoring libraries for node, JS, PHP, or Rust, I am always on the lookout for better solutions to common problems.
Location
USA
Work
Lead Developer & Co-founder at corpscrypt, CTO at REtech
I remember thinking along those lines when pug (Jade) or coffee script was big. And frankly: markdown is great but lacks important elements to make it truly versatile. The fact that there are different flavors in circulation doesn't help either.
At the end of the day, HTML is a terrible solution considering what we use it for today, but too many standards will probably make it hard to deprecate it. However, if we do dare to think about it: think bigger. There must be a better solution to define declaration. In a component based world, why do we think in documents in the first place?
How’s it going, I'm a Adam, a Full-Stack Engineer, actively searching for work. I'm all about JavaScript. And Frontend but don't let that fool you - I've also got some serious Backend skills.
Location
City of Bath, UK 🇬🇧
Education
11 plus years* active enterprise development experience and a Fine art degree 🎨
Passionate generalist conquering the web one project at a time. Whether authoring libraries for node, JS, PHP, or Rust, I am always on the lookout for better solutions to common problems.
Location
USA
Work
Lead Developer & Co-founder at corpscrypt, CTO at REtech
Nothing I know of. But if we look into the history of HTML, it is clear that it was intended for structured content, ultimately to be interpreted by processing layer. We call that layer browser and it now mainly uses HTML as entry hooks to attach interactivity and functionality rather than flat data. If you think about it: in a SSR application we read form various sources (database, cookies, request payloads,...) in order to ultimately translate the results into HTML. What for? To then pass it on to the client which will likely execute processes again (e.g. through js) in order to again translate the document into the intended presentation layer.
This whole concept got worse in recent years. With declarative JavaScript frameworks and webcomponents we effectively hack the browser's regular interpretation of HTML tags in order to hook intended outcome into the HTML format. This has gone so far that we have things like JSX that need a local server to compile our markup and logic into what is supposed to be static in the case of HTML and interpreted in the case of JS. So clearly we are going in the wrong direction. And we all know it. The computational power, memory and space required to run "create react app" by far exceeds what brought us to the moon.
So it's not that I have a solution, unfortunately. But I advocate to consider that we are using the principles designed for the requirements of over half a century ago to run the modern web.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I remember thinking along those lines when pug (Jade) or coffee script was big. And frankly: markdown is great but lacks important elements to make it truly versatile. The fact that there are different flavors in circulation doesn't help either.
At the end of the day, HTML is a terrible solution considering what we use it for today, but too many standards will probably make it hard to deprecate it. However, if we do dare to think about it: think bigger. There must be a better solution to define declaration. In a component based world, why do we think in documents in the first place?
The later question is interesting, what else is there?
Nothing I know of. But if we look into the history of HTML, it is clear that it was intended for structured content, ultimately to be interpreted by processing layer. We call that layer browser and it now mainly uses HTML as entry hooks to attach interactivity and functionality rather than flat data. If you think about it: in a SSR application we read form various sources (database, cookies, request payloads,...) in order to ultimately translate the results into HTML. What for? To then pass it on to the client which will likely execute processes again (e.g. through js) in order to again translate the document into the intended presentation layer.
This whole concept got worse in recent years. With declarative JavaScript frameworks and webcomponents we effectively hack the browser's regular interpretation of HTML tags in order to hook intended outcome into the HTML format. This has gone so far that we have things like JSX that need a local server to compile our markup and logic into what is supposed to be static in the case of HTML and interpreted in the case of JS. So clearly we are going in the wrong direction. And we all know it. The computational power, memory and space required to run "create react app" by far exceeds what brought us to the moon.
So it's not that I have a solution, unfortunately. But I advocate to consider that we are using the principles designed for the requirements of over half a century ago to run the modern web.