Web 3.0?

Modern days web page is also taking over lot of business logic to its side. The fat client relives the server not just from the UI rendering but also serves as a gateway to the web cloud services. That is IMO Web 3.0 concept: the client is an application on its own and became a nerve cell in collective distributed network brain with server connections as synapses. The server is not in charge of whole process anymore, clients live and interact on its own discretion. That idea defines the complexity we will face in fat client apps. The industry is trying to manage the scope by introducing so called “one page” applications. In another word by splitting the complex tack on primitive ones which do not have any or just little smarts on it. I guess that explains the popularity of AngularJS and its competitors. But sometimes it is a good advantage to have a fat client app or module to leverage the cross-site knowledge and provide appropriate user experience. In my case the sync between version control, Wikipedia hierarchy, documentation sites and test results take too much orchestration if implemented via web 1.0 or web 2.0 patterns. The sequence of hierarchy discovery, sync data with automated and interactive merges, progress updates and error/retries handling do not fit easy into web service – UI pair. Old dogs would advise to look into server-side model with live sync like IceFaces or Vaadin could potentially do. Modern will refer to MeteorJS. While that could be doable (not sure) the idea of keeping live model on server side is hardly scalable. Few hundreds simultaneous sessions will need proportional resources increase. Rather the fat client will use just a bare minimum from each involved server. Happy coding!

JSON added to XmlView, a bookmarklet for web service presentation as sortable table

In addition to early promoted XML in XmlView the JSON format support appeared to be an easy effort. The recognition of JSON format and conversion to XML was all needed to make a sortable table presentation for JSON based web services.

It is not as efficient and scalable as XML though. JSON doubles the browser memory consumption, half of which reside in the JS VM; additional parser for JSON consumes extra CPU/time.

Is it possible to make a faster and smaller memory consumption implementation using JSON without XML?

I guess not. XML reside in browser memory and is not a subject for JS limitations which will be in place for JSON. There is no multi-threaded(yet?) template transformation from JSON to HTML. Not to mention there is no way to render directly DOM by template engine besides XSLT.

Potential for the improvement

There is a prototype for virtual scrolling via XSLT. It could be used as a base for rendering just visible part of data delegation the rendering on scroll in real time.

Happy coding!

Modules compatibility as business problem

While the issues(and solutions) bellow are not browser client specific, the current subject of API registry primarily focused there.

• Legal compatibility. While open source is a great engine of progress it also a significant problem in keeping the application legally clean. Most of opensource contributors are enthusiastic junior developers who do not really paying attention for such things. And adding some fancy UI component could lead to the lawsuit with the cost way bigger than nice UI could ever bring. To prevent such gap the OSI licensing has been developed but going further it become not sufficient to use the library which has multiple contributors.
  Contributors License Agreement(CLA) has been developed by foundations and each code commit should be backed by it when applied to the library or application. When using external modules legal department should go over commit list and make sure that every committer have signed it.
  The complete chain of external modules licences and CLAs could relax the restrictions for external use or make the approval process straight.
  
• Identity validation (electronic signatures on sources&/binaries) will give an assurance for security review. For now this is performed(if at all) by IT department while it could be delegated to the trusted verifier within API registry.
• Methods overloading. JS methods could have multiple signatures as result there is a need for signature recognition in beginning of method and routing to the code matching the particular signature in run time. That increases JS code size, makes API confusing and code hard to maintain(as business logic mixed with signature recognition).
  In compiled languages this problem is resolved by performing of signature recognition and type casting during compile time. That way methods overloading does not cost in development/maintenance and runtime performance.
• Extending the existing API. Some existing API often need to be extended with additional functionality. For example retryCount in XHR or alternative location for AMD MID. Shim code could be attached to API similarly to AOP advise.
• Platform support. Often the API has a generic solution which is broken in some environments( like lack of Html Components or Web Components in browsers ). Special treatment could be done before|after|instead of original module methods for such special case. The problem is in separation of main codebase and special cases. It is pretty similar to extending the existing API but with platform conditional inclusion applied on top.
• API registry. For one or another reason like licensing or platform support the alternative modules could be demanded. The AMD does not answer whether AMD MID has a backup location or what licence it uses. The API registry meant to hold information about the module for legal, design, development, maintenance reasons
  
  • API - interface definition locator. The reference to pure API(s) which will be implemented by module.
  • dependencies presenting not just a list of modules used by given one bul also their validated/permitted revisions and perhaps sources.
  • API compatibility. The similar business logic could be implemented by different modules but not all of them could be compatible between each other and the caller. Method signature will resolve just the API syntax but not the implementation compatibility..
  • Localization I18N and accessibility support.
  • source and primary source location (VCS branch+revision)
  • identity validation. Verifiable source(as particular module as involved in binary assembly other modules) and binary signature, trusted compilation environment reference and locator, binary assembly all sources
  • help,blog,FAQ,discussion
  • support abilities
  • legal (license, foundation, contributor CLA, etc)
  • Platform support
  • Test( + against dependencies revisions) and results matrix and related support. The test in this case is treated as "test" dependency for original module.
  • Other dimensions TBD. Registry should permit custom attributes  of different types.
• Open registry network. Currently solutions for the some of problems above are insulated under single foundation umbrella with same ( like ISI or Dojo ) licence or API convention. Having registry as open platform capable of passing through and caching data should take the compatibility complexity out of decision making opening the doors for individual contributor modules into enterprise. The best analogy for data sharing would be DNS.