What do you think about doing JS-Free sites?


By itself, WebAssembly cannot currently directly access the DOM; it can only call JavaScript, passing in integer and floating point primitive data types. Thus, to access any Web API, WebAssembly needs to call out to JavaScript, which then makes the Web API call. Emscripten therefore creates the HTML and JavaScript glue code needed to achieve this.

I use JavaScript in my web applications almost only for dynamically manipulating the DOM according to responses to AJAX requests. All the heavy lifting, e.g. site wide searching, math simulations of differential equations depending on user entries, signal measurements, FFT, and generation of SVG plots etc., is done by C subroutines on the server. Now, I conclude, that WebAssembly is not only inefficient and clumsy, it is a non-solution of a non-problem. It is absolutely useless.

It reminds me of Flex... :D
 
I don't understand how anyone keeps preferring Javascript over PHP.

These are entirely different things. PHP runs on the server, JavaScript on the client.
And I know no PHP application that doesn't make use of JavaScript in its generated pages, I don't even know if it has existed in PHP's early days.
 
Now, I conclude, that WebAssembly is not only inefficient and clumsy, it is a non-solution of a non-problem. It is absolutely useless.

C can't really directly interact with the Win32 API, X11 or OpenGL either. However for emscripten, this is what bindings are for. For example for some html5 features: https://emscripten.org/docs/api_reference/html5.h.html

Emscripten provides the EM_ASM{} syntax for "inline Javascript" to help create these bindings (https://emscripten.org/docs/api_reference/emscripten.h.html#c.EM_ASM). If Javascript ever did disappear, these parts can either migrate to the new thing or (more likely) interact with the DOM directly.

Quite a few WebAssembly programs have fairly substantial DOM wrappers and some replace much of it entirely. I am certainly not saying this is a good thing. Qt is a pain in the butt!

Still early days but in ~20 years I reckon it will be the norm. Web developers just always seem to want new features and WebAssembly seems to offer it (in a slow and less than elegant manner).
 
You have CSS variables for this. :)
And if you like stacking up frameworks, you also have SASS and friends. ;)
From what I just looked up, that's not pure CSS. CSS wouldn't work with a variable. It says it would have to be compiled, through SASS which you mentioned, to CSS in the form without the variable.

There were two types of variables, one which didn't work in CSS in itself, but compiled with something else to CSS.

Miniaturizing CSS for speed, would probably remove such variables. A macro shouldn't cause speed penalties, and those variables aren't in the CSS itself.
 
From what I just looked up, that's not pure CSS. CSS wouldn't work with a variable.

CSS variables are part of the CSS standard published by the W3C.
I can't remember whether they came with CSS 2.1 or CSS3 (which, by the way, is not a version number but a convenient nickname to refer to modularized CSS).
 
Pretty much every single web developers I'm aware of (not many!), develop their project with Chrome/Chromium in mind, and a final test on 2-3 platform,namely Chromium(Desktop/Android) and rarely Safari.
This is a blunder made by incompetent web developers. You write to standards and NEVER to a browser. And if you aren't including Safari in your tests, you are ..... I don't want to get in trouble for what I've told people before.

EDIT: To continue. My web dev company mainly dealt with the entertainment industry and restaurants. Fully half of all visitors to the entertainment industry sites were through Safari. On the other hand, one of the restaurants sat a block away from a huge financial institution where 75% of their visitors used IE. One MUST consider the logs of their visitors and analytics!
 
  • Like
Reactions: a6h
[...] Qt is a pain in the butt!
Can you explain why?
Still early days but in ~20 years I reckon it will be the norm. Web developers just always seem to want new features and WebAssembly seems to offer it (in a slow and less than elegant manner).
The general idea of WebAssembly is good. Programmers are free to choose any language they like that can be transformed into WASM. Maybe it has flaws in it's implementation, and maybe also some design flaws.
 
  • Like
Reactions: a6h
I don't understand how anyone keeps preferring Javascript over PHP.
Because PHP can't run in the browser.
Or maybe can Python or Ruby replace it? Go-lang for those who like Google? PHP is more universally supported than potentially better alternates by hosting providers.
A lot of people don't like Ruby. Go is preferred by a lot of developers because it is web-centric. PHP is the language everyone loves to hate--and for good reason. While it's improved greatly in recent years, one can do better.
 
Currently CSS so flexible, that it possible to do various effects and tricks without JS.
And that is where the problem already starts: In my opinion websites don't need various effects. I cannot recall ever having visited a website for (visual) effects.

The problem I see is that these days people expect fancy looking stuff although it is adding zero value to the actual experience or service offered. At the same time it's often those people that complain about how slow things are and that their phone battery is dead after half a day.
 
I don't need Javascript then, like others have said. Maybe this is basic, and lacks features, but it works. Others here say that works as well.
 
HTML5 is perfectly fine.

It cannot be anymore verified with: http://www.jclark.com/sp/nsgmls.htm

And, as far as I know, javascript is still necessary for AJAX.

I don't understand how anyone keeps preferring Javascript over PHP. Maybe PHP should be replaced, but definitely not with Javascript.

They are for different tasks: Javascript runs in the browser, PHP in the server. No replacement.

But I do not understand the php hype. Older is modperl in Apache. Older is tcl
in aolserver / naviserver. PHP was a superfluous invention.
 
And that is where the problem already starts: In my opinion websites don't need various effects. I cannot recall ever having visited a website for (visual) effects.

The problem I see is that these days people expect fancy looking stuff although it is adding zero value to the actual experience or service offered. At the same time it's often those people that complain about how slow things are and that their phone battery is dead after half a day.

So true! I'm currently on holiday in a small village and only have an ADSL connection. I don't remember the web being so slow when I was using ADSL at home!
Installing anything is a long, long adventure. Even forums.freebsd.org is terrible.

Moreover, the Mozilla Foundation conducted a survey a few years ago showing a page's loading consisted for 45% (if memory serves me well) in trackers and ads.
The same study showed HTML5 notifications were refused by something like 90% of web users.
 
Older versions of HTML were SGML or like SGML.

They were SGML, that is why they could be validated wit nsgml, HTML5 not
anymore.

XHTML is XML. You must decide between on one side smaller and more readable code, on the
other side inflated XML. The trend is the second. A newspaper page with some text may take
megabytes, a lot of obfuscated javascript code. SGML is harder to parse than XML, but that
is nothing compared with the javascripts running, many of them making the browser completely
lame.
 
HTML5 took on many of the same standards of XHTML. HTML5 operates like XML rather than SGML. This is probably why it won't validate there.

XHTML has XML standards on having corresponding opening and closing tags. Previous HTML's weren't standardized in this way, and let a lot slide to validate. HTML5 has the same standards as XHTML in this way.
 
XHTML has higher standards on having corresponding opening and closing tags. Previous HTML's let that slide. HTML5 has the same standards as XHTML in this way.
It does not. The standard is the same assuming you mean closing tags such as
Code:
<img />
I see that often but that closing slash has never been part of any HTML standard including HTML5. In fact, the standard specifically states that slash has no meaning and does nothing in HTML.
 
The things you listed are not what WebAssembly is for. Real heavy lifting shouldn't be done by WebAssembly.
Perhaps I was not clear enough. Reading the documents, am I the only one who recons, that WASM is limited to number crunching, nothing else. And then, the question is, for what do I need a number cruncher in the web browser, which by definition is a frontend. I won't need it. Perhaps hackers would love it for mining bitcoins in your browser. Are there any other useful applications for JavaScript embedding a WASM number crunching kernel (and no it is not the other way around, WASM with JS bindings).

Somebody said there will be a Qt port to the web browser. Are people working on running Qt applications in QtWeb? Will we see QtWeb running in QtWeb running in QtWeb running in ..., as sort of a benchmark for system performance, and the depth count until the system freezes would be the performance indicator. Happy coding :)
 
Back
Top