>My take on all of this is that the JavaScript part of client side development is a solved problem.
>
>You can do most things you need to now relatively easily with frameworks like Angular, React or Vue or any other frameworks. There's a learning curve with all of these but once you understand the underlying concepts the process of building solid business logic becomes pretty mundane and easy. With ES6 and Typescript in particular (and all the benefits of type checking when using Typescript) the dev process in JavaScript is pretty well established.

Agreed - this is what I meant with the option to adapt/abstract a particular problem to any of those fwks with minimal glue code.


>What continues to suck with HTML based applications is the lack of decent UI controls. We're 25 years into the Web and we still have less than a dozen input controls. Every app I struggle to find the right date picker and auto-complete etc. depdending on which CSS framework I'm using. That's just plain ridiculous. Web Components have been `a year off` for close to 10 years now and mobile interfaces that provide parity with native apps are even worse. The HTML UI of Web applications is what I see most people struggling with these days, not the client side code logic.
>

>As to data storage I'm sure why that's a problem in your view. You can use plain JSON in memory and store that in localstorage or session storage for local persistence - it really doesn't get much easier (except for browser storage size limitations that affect all storage tech). Libraries like loDash (or even the new ES6+ array methods) provide for easy searchability. What else do you really need for client side that is supposedly so much better in FoxPro tables?

Schema automatically used and checked, RI rules easy to pick up from the backend and applied to client data - all that nice well established Data Dictionary stuff available via xCase and similar tools. Yes you can work on arrays or JSON/object rows with lodash or even AlaSQL or load into SQL.js, but you will either have 2 ways to code same functionality in client and server or load 300+MB of JS for a runtime-functionalty probably most tested/used across all people already included at least in Chrome and Firefox and available as public domain in C if MS does not want to use own code.

I saw in WebSQL something similar enabling the web dev as ODBC/JDBC enabled PC clients to access the SQL backend world.
[Oracle killing WebSQL is my pet peeve...]

>>
>FWIW, I think we'll see yet another big shift in the next years as WebAssembly takes off. Having seen some of the Blazor demos which lets you write C# and Razor code using the standard .NET development tooling is pretty cool. And producing an optimized WebAssembly package that's smaller than typical frameworks like Angular or React I think makes that a real contender in the future - I don't mean Blazor in particular, but there are efforts for other platforms doing the same with Web Assembly.

I would like to see/benchmark real use cases. WebAssembly is not machine code, but an easier-to-JIT format with the option to define C types/structs. It will help the first-to-interactive times, but will not abolish time needed for JIT. The speed of JITted JS running problems where you would prefer C/C++ over interpreted [Vfp or Python] pseudo-compiled code is often nearer to C than to other untyped/[p-]interpreted languages, so speed benefit might be less marked as expected. The drawback of sources running on the client being even more obfuscated will open the door for many new day niceties like drive-by-crypto mining or attacks that are harder to identify.

But yes, a lot of tools from the strictly typed compiled universes will have easier access to the web - probably the compile to JS tools like GWT, Vaadin and similar first. A slightly uphill battle if FIC or Django tries to cover a terrain easier for strictly typed languages.

>But even with those - in the end we're stuck with the Browser and DOM infrastructure and the slow as molasses W3C standards process that seems to be at a standstill.

Ecmascript had too much syntactic sugar added lately for my taste - it would have been better to steer part of that energy into DOM or CSS
;-)

regards

thomas