I'm considering webassembly for a new project, and this got me wondering:
Is anyone aware of a consortium that is curating a CDN for webassembly libraries? Ideally, such an offering would improve load times with caching, allow for the benefits of dependency injection, and centralize encryption/security behaviors so that new algorithms can be rolled out quickly when the crap hits the fan with quantum computing.
If there isn't one, does anyone know how to lobby to get one started?
I realize that many libraries can be recompiled into webassembly downloads, but that would bloat the application size, and put extra strain on each shop to manage their library consumption.
Additional (but less critical) benefits to a curated CDN would include shared performance increases for libraries that support data warehousing, shared performance increases for database access, forcible separation of concerns when coding, significantly smaller project sizes, simplified interface contracts via nuget, etc. The list of benefits is pretty huge.
Also, if webassembly containers gain enough adoption, such shared libraries could serve as a vehicle to allow for a much more seamless transition to/from different technology stacks (possibly unifying the JAVA stream and .NET linq libraries for example) under the expressed goal of being language agnostic. Webassembly is meant to be language agnostic. It seems like it would be a shame if each technology platform/shop built their own redundant libraries, which would serve to be slower and less reliable than libraries forged under the scrutiny of open sourcing.
Ideally, such an offering would improve load times with caching
It doesn't work like that in modern browsers; for security reasons they incorporate a technique called a double-keyed HTTP cache (unfortunately, I don't know of a good explainer to link out to, but this one should work well: https://github.com/shivanigithub/http-cache-partitioning/).
What this means is that any resources from a CDN are loaded and stored separately under the origin that requested them, and not shared between various websites like it used to be in the past.
As such, you will be much better off actually compiling the required native libraries for your particular application - that way you will benefit from compile-time optimisations, and won't be loading any unused parts of the huge libraries or frameworks for each user.
However, now that we covered the performance aspect, there are indeed some attempts to serve precompiled Wasm modules, mainly for tiny libraries where code size is not as much of a concern as in standard frameworks.
If you're looking for Wasm libraries intended for use from JavaScript, then npm is used just like for other libraries, and is a convenient platform because you can ship JavaScript wrappers (e.g. Emscripten or wasm-bindgen generated code) together with the actual native code. E.g. just a random example from a quick search: https://www.npmjs.com/package/xsalsa20.
If you're looking to ship Wasm applications built with WASI API in mind, then you might be interested to take a look at https://wapm.io/, which does just that and ships a bunch of precompiled apps.
TL;DR: there are some package managers and CDNs that allow shipping WebAssembly libraries and applications, but it's done mainly for convenience, not performance; if you care about performance and download sizes, then you're better off compiling native libraries yourself for your particular app.
Related
This questions is quite open. So let me make it a bit narrower:
I would start a CAD application project. Some traditional app that run on your PC, not some web app, but it will use some clouded database. I want this project to be open-source and I would like to have some community-driven development model.
I must confess, I am a big fan of C++/Qt.( So then why ask such a question?) Some years ago I turned to Python and I was blasted by it's ease of codding/Debugging and the productivity gain over C++. The drawback of python is the loose of efficiency, which will be needed for any CAD application.
On the other hand, the drawback of C++ is its difficulty to master and to debug some points (like memory management) which might be an issue with the community (to keep the app stable).
Here are my requirement for the GUI Framework:
Cross-Platform
Be native on the target platform (Don't answer java please).
Have some class to help manage thousand of 2D sprites at time.
Be efficient, in therm of Memory and CPU resource.
Integrate well with web by XML/JSON other RPC.
So my final question is: Can you point me to some Language + GUI toolkit that fits those requirement but that is easier to master (in a 'python' way) than C++/Qt ? Any suggestions? Or should I go with C++/Qt?
I have recently regained some interest in learning Qt, but have the following doubt:
Does Qt have enough classes that are not GUI-related?
For example, Python is "batteries-included", .NET is definitely "batteries-included", and as far as I have seen, Android API also has a lot of classes to design and implement application/domain logic, not directly related to visual presentation.
The main reason I am asking is because I don't know C++ and don't plan to learn it deeply (too much time needed), so if I had to take third party C++ libraries all the time and struggle to use them inside Qt projects that would be a strong point against going ahead.
The intended use is mostly to create small desktop apps for personal use while gaining insight on software design good practices - a profession I am slowly migrating to.
I have already used some Python/Pygtk (without IDE) and WPF (in VStudio/ExpressionBlend). In both platforms, most of my work is related to scientific computations, image processing and interactive scientific visualization, and there are good libraries for that either in Python (Numpy, Scipy, Matplotlib, Pandas, PIL, cairo) and .NET(AForge, alglib, System.Media.Media3D). I wonder if the Qt ecosystem is so complete in that regard.
Qt isn't a language in itself, so you can't compare it to Python or .NET. With that being said, Qt does provide general-purpose classes like containers, a Unicode string class, character set encoders/decoders, multimedia, device and file I/O, etc. All these modules are fully documented.
There are also some external modules available for Qt, like Qwt which provides widgets for technical applications.
For other functionality where something Qt-specific isn't available, you can obviously use another appropriate library. Like OpenCV.
Oh, and you can use Qt in Python too, through PyQt.
As far as I know, Qt doesn't have image processing libraries. For that, you'll need to use something like OpenCV. Qt does have libraries for loading most common image types.
However, Qt does extend beyond just GUI classes.
There is a database module that's quite convenient. The concurrency/threading classes are nice. I've enjoyed making use of the Qt Networking classes. The FileIO classes are alright.
These classes/modules are all useful for making platform-independent code. Things like image processing are mostly algorithmic and tend to be platform-independent by nature. So I think they fall out of the scope of the Qt framework. It shouldn't be too difficult, however, to simply find a library that does what you need and link that in to your project.
A lot of the Qt Core services that heltonbiker and Nikos C. mentioned, can be thought of as extensions to C++, a little like std. Although I often prefer the Qt implementations myself. But Qt has gone much further with their libraries, with the I/O, and web services etc...
The QtXML library provides reading and writing of XML files. Traditionally we had always used xerces, but the Qt XML library is almost as simple as .NETs.
The QtNetwork library offers TCP/IP and other networks services
The QtMultimedia library performs playback and recording of audio
and video content to the use of available devices like cameras and
radios.
The QtSQL library interfaces with SQL databases.
And there is much more than that. Although these are probably services that are used to most. The other benefit is that for the most part the implementations are cross platform. So for example using the I/O services does not require you to write separate code for Linux and Windows. That is a general rule, and there are exceptions. But I am sure most people would agree that any of the services they offer are easy to use, and well documented.
Happy coding.
Qt provides ample abstraction besides UI - it comes with a set of functionality enhancing features that come with certain usage paradigms.
Container classes - shallow copy by value, copy on write
Implicit sharing for containers and certain data types
Event driven, signals and slots
A powerful and usable metasystem
Properties
Platform abstraction for a lot of functionality, from file access to network and multithreading
Cross platform atomics (not that important since C++11 atomics)
Settings API
Undo API
OpenGL abstraction (not necessarily UI, custom graphics)
Basic image formats and basic image manipulations
Qt Declarative, a.k.a QtQuick and QML markup (usable for all kind of structure markup BTW)
Dynamic plugin API
Platform abstraction and portability - same code, multiple platforms
High and low level multimedia - audio, video
Sensors and serial port
Unit test
XML, JSON, SQL
An outdated and hopefully soon updated OpenCL abstraction
Last but not least, a lot of 3rd party modules built around Qt fitting a wide range of applications
Honestly, all its missing is support for some more popular formats for file, media encoding/decoding and containers, some parallel and vector abstraction, USB, WIFI/NFC (in the works in an addon module) and it will be 100% versatile.
Note that you can also use Python with Qt, although I have no experience with that, Qt is a very versatile tool that allows for quick and easy application development - and since 5.1 supports pretty much the entire market, with the addition of Android and iOS to the list of supported platforms. It is very useful for creating custom use applications for creative or research purposes.
Although not perfect for every task, Qt is easily the "best of the bunch" of tools you can use in this regard. Unbeatable in terms of portability and very thorough, if not a little bloated for the set of functionality it provides. And finally, it is free, you can even develop commercial applications under LGPL as long as you link dynamically. All in all, it is well worth the investment to learn, the only downside is it lacks uniformity between the old C++ native APIs and the QML runtime, which is actively worked on and is based on JS, so the APIs are a bit different and some glue APIs are required to fuse C++ with JS and QML.
(just for the record, from the official site):
The Foundation: Qt Core Module
The Qt Core module forms the foundation of all Qt-based applications
with core non-graphical classes used by other modules.
Key Functions
File IO, event and object handling
Multi-threading and concurrency
Plugins, setting management
Signals and Slots inter-object communications mechanism
Benefits
Reduce development time and cost by leveraging a complete set of application building blocks
Develop portable code from the ground up with cross-platform functionality
what does the relation between a Web frontend and a smartphone App with identical feature sets look like regarding the development effort? Are there any specific differences regarding the development effort between Apps of different smartphone platforms (iOS, symbian OS, Android, etc.) ignoring training time? A general estimation would completely satisfy me. ;)
Thanks in advance,
Flinsch.
I hesitate to call this an estimate, or even an informed guess, but perhaps by putting down some ideas I might help your thinking.
Ignoring any particular platform specifics I see the fundamental difference of Web v Native is that in the Web case you have some extra work to do:
a). You have presentation separated from the backend, with probably HTTP in between. So there are services to write and issues concerned with notifications and/or polling to deal with.
b). You're likely using a browser to do the presentation so you will be using some JavaScript kind of library, and these are still hard to drive.
So, if you are targeting a single device my guess is that writing native code is likely to be 50% quicker than web-based code - assuming that you really are targetting identical function.
What seems to happend is that we compromise Web Apps, reducing functionality somewhat and hence the overhead is reduced.
Also there's another factor, the UI portions of the Web App are in principle portable, hence in fact the Web App development may be a reasonable investment even if it does take more effort.
I suspect that portability may well end up being a dominant consideration.
specific differences? There are plenty, but each with their own tradeoff:
UI: Web applications have CSS, (HTML, XHTML, HTML5) specifications that is supported by major browsers (although have have their issues). For Smartphone apps, each UI has to be designed and implemented according to the language the apps can be built on. You can effectively create apps like Winamp (having skins). For web applications, this is relatively a quick effort compared to writing UI's for each different smartphone OS models out there.
Language of use/Portability: In Web applications, an application sits in a server, so every request is sent to the server and response is returned from it. This allows that 1) Web applications can be written in any language of choice, as the end user never sees the server nor needs to configure it, 2) It allows the developer to write in a language that he/she is comfortable in. In smartphone apps, for the developer to run his apps to all the smartphone OS'es, he/she has to learn the programming language for the OS, and learn to port their code to work there (if porting is possible). That never exists in Web applications.
Hardware limitations: For smartapps, the developer must be aware of the cellphone capabilities and limitations. Facebook (e.g.) can essentially grow their memory, and add new servers and cluster their environment as the demand grows. You can't do that with smartphone apps. You will have to limit your implementation to run in a capability that your desired smartphone can accommodate.
There are more (feel free to add) but all these are part of the development effort that a software developer has to look at if they want to go a a field of choice.
Until recently I'd considered myself to be a pretty good web programmer (coming up for 10yrs commercial experience on a variety of e-commerce, static and enterprise applications). I'm self taught and have always used the Microsoft product stack (ASP, ASP.NET)...
My applications are always functional, relatively bug free, but have never been lightening quick. As a frequent web user I always found this to be the norm... how fast are the websites from the big tech players (eBay, Facebook, Microsoft, IBM, Dell, Telerik etc etc) - in truth none are particularly fast. I always attributed this to "the way things are with web apps"...
...then I cam across a product called Jira from atlasian and this has stopped me in my tracks...
This application is fast, and I mean blindingly fast.. too fast to time the switches between pages, fully live content, lots of images and data and cross references etc etc...
I run this on an intranet, with a large application DB, and this is running on a very normal server (single processor, SATA HDD, 8GB RAM).
Am I missing something?? Are my programming techniques that bad?? I am wondering if this speed gain is down to it being written in Java and running on Tomcat.
Does anyone have any benchmarks to compare JSP / ASP or Tomcat / IIS???
Thanks,
Mark
NOTE: this isn't a blatant plug for Jira. I don't work for them or have any affiliation to them... but I would like to be able to write applications like them :)
YMMV. But one of the longest-lived Things That Aren't True Anymore is the assertion that "Java Is Slow". Excepting floating-point (where most Java implementations aren't at liberty to use the floating-point hardware), Java is generally as fast or faster than compiled code. Some of the best and brightest have spent years of effort ensuring this, including such things as dynamic recompilation/re-optimization of code based on run-time metrics - something that statically-compiled languages like C or assembler cannot boast.
ASP is sort of the opposite extreme, since the original ASP had to recompile each page request each and every time it was made. ASPX addressed this by allowing retention of the compiled page code. That got rid of a lot of useless overhead.
A more compelling reason to prefer Java over ASPanything/IIS is freedom. A Java/Tomcat webapp will run under almost any OS on almost any hardware. IIS runs on Windows. Period. And for the most part, that also means Intel. Not Sparc, Not zSeries. Maybe you don't care. But then again, maybe next week IBM will offer your employer a can't-refuse deal on a mainframe.
I don't have benchmarks, and there are a lot of things that can make one platform preferable. But I permanently gave up on the "Java is slow" idea when I encountered the Poseidon UML tool with its cool real-time graphics UI and the FreeMind mindmapper tool. A small hit to startup the JVM, but after that, you'd never know what language you were working under.
The great debate. Java vs. .Net.
When .Net first came out there was an application written called "The Pet Shop." Which was a .Net port of Sun's J2EE reference application, "The Pet Store". It was announced that Microsoft's implementation was "faster."
As with anything, especially anything to do with marketing, you have to dig deeper to find the truth.
Any technology can be fast with enough hardware and the correct design.
In my experience there are two factors to speed: What type of hardware is used and how you architect your application (this includes database tuning).
Caching at various levels (response, db, etc.) makes a huge different in responsiveness of a web application. There is also a lot of things that are done to reduce time consuming operations like db connection pooling, sql statement caching, etc. As much as I'd like to say Java is better :-), I think in this case the performance is due to the way Jira was written and the fact that it's being run internally (probably with few users as compared to eBay, Facebook, Microsoft). This site, Stackoverflow, uses ASP.NET MVC and IIS and is very responsive and my guess (since code is not open sourced, yet) is that they use many of the same techniques you would find in Jira or any other web application built to scale.
I think that it is not typically the frameworks and languages used that make an application slow. In my experience, some frameworks like JSF or .NET server side controls give developers alot of freedom to make too many database calls and look things up too often, but that's definitely not the fault of the framework used.
Keep your application as light as possible and focus on keeping the data sent to the client as small as possible, and you will have a fast application. It's usually faster to develop fast applications too.
The Jira folks have written a best in class application (and charge for it) - nice work crocodile dundees.
I also suggest to consider also two aspects:
the maintenance activities: logging and deployment. In my opinion under a unix like server is more easier to log, deploy, and maintain new release than doing the same on a Windows server.
if the project require to use some open source application (i.e. Alfresco repository) Java is better solutions
People's opinion is mostly biased. Most people have never really tried the other while claiming the other is slower. I wouldn't trust any answer: it's mere opinion. It's boring to always read the same 4 cents again and again.
I'm working on a project that currently has zero users but we would like to scale up to potentially hundreds. Currently we are running on a MySQL database with AMFPHP interacting with Flex. We used Flex because of its robust graphic features (important to this project) and because the initial developer (not me) already knew ActionScript. We are currently using AIR but might switch to web-based Flash at some point.
My questions are:
Is Flex a good tool for a project like this?
What are the main limitations of Flex that we might encounter?
What are other development platforms we might want to consider?
Thanks.
- Dave
Short answer, Yes. There are already many prime-time Apps using Flex as their UI development platform. If you go to the Adobe site they showcase quite a few.
Speaking personally, I chose Flex for two reasons, first was that, although you probably can do much of what Flex does in HTML or with an appropriate toolkit, Flex is designed for attractive and compelling user experience and has available all of Flash. Plus the development environment and available widgets make it easy and fun to program. I don't want to spark a religious war about HTML vs. Flex, so I'll leave that there - it works for me and my application and customers.
Second, and more important, was that it balances the processing load more towards the client which means my server architecture can be optimised just for serving the content and persisting the data. Most of my business logic has migrated across to the client. Having spent many years in classical architectures I think this is a huge step forward, but I can already her a chorus of disagreement about that too.
My word of caution about Flex comes from needing to adopt the right architecture for your client code. It is pretty easy to create a huge and badly performing app with Flex if you get that wrong. Make everything event driven and apparently asynchronous and you should be OK ('apparently' because the Flash player is single threaded). And that is downside 1, the single threaded Flash player sometimes causes issues.
Downside 2 is perhaps more serious and that is locked down desktops in corporate environments. Quite often your target audience won't have administrative rights to their computer and will have either the wrong flash player or none at all. This is particularly true in public sector organisations and the military, so if you are heading there I would test carefully the presence of Flash amongst your users.
Other than that I heartily recommend Flex. It's also a great thing to have on your CV!
HTH
Flex has no inherent scalability problems, however if you have a graphic intensive application, proper serving of these resources might be a problem, but that has little to do with Flex.
The only note-worthy and likely platform you won't be able to run on is the iPhone (no flash) and some older non-flash mobile devices (although most support Flash-lite nowadays)
As for alternatives, if you are Graphics heavy, and don't mind the iPhone, then Flex is good if not best cross platform solution besides using pure HTML technologies, the trick here is HTML alone can do 99% of what Flex can do, but if your App requires the missing 1% then you're out of Luck, also Flex will reduce crossplatform and most browser compatibility issues. So it might make your work more productive.
Silverlight 2 is an alternative to consider. WPF if you're looking for something with offline support.
Yes, the scale and type of project
fits.
Immaturity of frameworks and libraries you might depend on. Immaturity of IDE's.
Silverlight, JavaFX.
Flex + AIR is probably as good a tool as Visual Basic was; it may be a better tool for having a much more flexible programming language and having free development tools, but keep the limitations in mind....
The main limitation I've seen from working with it is documentation. There seems to be not enough documentation, not good enough documentation, and not enough high-visibility work on it in the community. (This is coming from years in .NET; I've been constantly upset with how little MSDN says about methods but generally able to deal with it by finding the most useful blog posts.)
Other possible development platforms would depend very heavily on the specifics of the project. Web-based platforms bog down in deep, stateful interactions with data sets (even with nice AJAX libraries), whereas maintaining client-side installations of any thick client program (say, Flex + AIR) might be overkill if it's just a few CRUD forms.