The hardware industry didn't stop at mass-produced integrated circuits (IC) though. ASICs (Application-Specific Integrated Circuit) and SoCs (System on a Chip) are common now.
Similarly while IC-style libraries may be good enough for back end systems and native applications, front end can only tolerate the associated bloat to a point otherwise tree shaking wouldn't be a thing—and code has to be deliberately structured for tree shaking to work.
So apart from hand coding, in terms of automation, this suggests tooling that is capable generating exactly the functionality required but with the minimum amount of code. It doesn't take too much of a leap to imagine that "configuration" of such tooling is going to be some form of "programming"—though likely more declarative in nature.
Interesting point. I immediately thought of C# WASM. Whereby all Javascript can now be bypassed. No more bloat, because the C# IL and subsequent machine code don't have it. In fact I believe C# WASM also supports pre compiled machine code.
If the code supports DI using configuration options, then optimal low code solutions are workable.
No more bloat, because the C# IL and subsequent machine code don't have it.
I don't agree. The bloat exists in the form of the .NET CLR which isn't present on browser- the JavaScript runtime already exists on all browsers. And for the time being each isolate/thread/worker would need it's own copy of the runtime in memory which can add up pretty quickly especially on resource constrained devices.
WebAssembly is an attractive option for languages with minimal run times like C/C++, Rust and perhaps even AssemblyScript but due to their comparatively slow development cycles will most likely be optimizations rather than main application development (there will always be exceptional niche cases).
In many cases using JavaScript as a compilation target will still make more sense in order to take advantage of the existing capabilities rather than having to design some minimal purpose designed WebAssembly runtime (especially during product inception).
Some C# dialect to generate WebAssembly against some minimal Web API specific runtime via WASI perhaps but there is no advantage going through the CIL.
I don't agree with that either. C# is able to deliver code that's pre-compiled and fully optimized at the machine layer. Apart from a one time CLR load the bloat comparison holds no water. Javascript only goes to the IL layer which always interprets into machine code. Optimization with Jit are inferior, they don't have time to do the same thing as multipass compilers. Minus the one time CLR load WASM is super fast. It's ultimate niche is with those needing ultra secure run time.
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.
The hardware industry didn't stop at mass-produced integrated circuits (IC) though. ASICs (Application-Specific Integrated Circuit) and SoCs (System on a Chip) are common now.
Similarly while IC-style libraries may be good enough for back end systems and native applications, front end can only tolerate the associated bloat to a point otherwise tree shaking wouldn't be a thing—and code has to be deliberately structured for tree shaking to work.
So apart from hand coding, in terms of automation, this suggests tooling that is capable generating exactly the functionality required but with the minimum amount of code. It doesn't take too much of a leap to imagine that "configuration" of such tooling is going to be some form of "programming"—though likely more declarative in nature.
Interesting point. I immediately thought of C# WASM. Whereby all Javascript can now be bypassed. No more bloat, because the C# IL and subsequent machine code don't have it. In fact I believe C# WASM also supports pre compiled machine code.
If the code supports DI using configuration options, then optimal low code solutions are workable.
I don't agree. The bloat exists in the form of the .NET CLR which isn't present on browser- the JavaScript runtime already exists on all browsers. And for the time being each isolate/thread/worker would need it's own copy of the runtime in memory which can add up pretty quickly especially on resource constrained devices.
WebAssembly is an attractive option for languages with minimal run times like C/C++, Rust and perhaps even AssemblyScript but due to their comparatively slow development cycles will most likely be optimizations rather than main application development (there will always be exceptional niche cases).
In many cases using JavaScript as a compilation target will still make more sense in order to take advantage of the existing capabilities rather than having to design some minimal purpose designed WebAssembly runtime (especially during product inception).
Some C# dialect to generate WebAssembly against some minimal Web API specific runtime via WASI perhaps but there is no advantage going through the CIL.
I don't agree with that either. C# is able to deliver code that's pre-compiled and fully optimized at the machine layer. Apart from a one time CLR load the bloat comparison holds no water. Javascript only goes to the IL layer which always interprets into machine code. Optimization with Jit are inferior, they don't have time to do the same thing as multipass compilers. Minus the one time CLR load WASM is super fast. It's ultimate niche is with those needing ultra secure run time.