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