Develop Reference

What libraries are available to stream data from the browser to a server using standard stream APIs such as WritableStream and Node.js Readable? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 1 year ago.
Improve this question
I am trying to stream a relatively large data file (1 Gig) from an Angular app running in the web browser to a Node.js server running on an embedded device. Streaming is necessary because the large file cannot fit into memory on the embedded device.
I was hoping to find a library that implements the various Stream API standards:
https://developer.mozilla.org/en-US/docs/Web/API/WritableStream
https://nodejs.org/api/stream.html#class-streamreadable
So I could do something simple on the web browser side like:
source_file.stream().pipeTo(socket);
And then on the Node.JS side:
socket.pipe(destination_file);
My first instinct was to use the native browser Fetch API:
https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API
But it turns out that most browsers only support streams for responses and not requests. Unfortunately, "Streaming request body" appears to be missing from the Browser Support Matrix in the documentation so this fact was not immediately obvious. Consequently, I opened a documentation issue here: https://github.com/mdn/browser-compat-data/issues/12188. A nice article on how to do this by enabling experimental browser support can be found here: https://web.dev/fetch-upload-streaming/. As a point of interest, for HTTP/1.1, this functionality is implemented on top of the chunked transfer encoding: https://en.wikipedia.org/wiki/Chunked_transfer_encoding.
Next, I looked at libraries and found the lovely websocket-stream library here:
https://www.npmjs.com/package/websocket-stream.
While this worked nicely on the Node.JS side, the browser side quickly became a nightmare because of the need to "browserify" it to work on the browser. This sadly pulls in a ton of browserified dependencies into the Angular project and involves some complicated configuration to use them.
Finally, I gave up looking and implemented some extremely basic streaming using the above mentioned stream APIs over a standard WebSocket connection. This unfortunately introduces a level of complexity I would rather not maintain which is why I continue to look for better alternatives. I may need to use the web-streams-polyfills browser side for those browsers that don't support the streams API natively yet: https://www.npmjs.com/package/web-streams-polyfill.
Other options I considered and rejected:
stream-http (supports stream API but relies on the browser APIs/support so streaming is likely 1 directional) https://github.com/jhiesey/stream-http
http-browserify (also relies on browser APIs/support) https://github.com/browserify/http-browserify
XMLHttpRequest (no stream API support) https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest
WebRTC (no stream API support + complicated connection negotiation) https://webrtc.org/
socket.io (no stream API support) https://socket.io/
Axios (no stream API support) https://axios-http.com/
Any suggestions of libraries or technologies would be much appreciated!
Alternatively, if I prematurely rejected any of the previous technologies and there is an easy way to use them for streaming from the web browser then I'd love to hear how to use them.
Thanks!

I think libp2p looks like a good candidate for your problem.

What caused Flash and Actionscript to become irrelevant? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
At first glance this question may seem like I'm looking for opinions or a discussion, but hear me out. While I'm sure everyone has their own opinion of which tools are best to use, there have got to be some factual reasons why Flash's popularity faded away. I'm sure there were certain events and inventions that caused people to prefer other tools, and I'm dying to know what those events are. So I am looking for answers that are based on facts and events. All I can gather from the research I've done and the projects I've seen is that Flash used to be really popular for creating interactive media or cartoon-like movies, but now it's not.
The background story to this question is that over the past few months I've been creating a project with Adobe Animate and Actionscript for a college class. It's been fun and I find that Animate is extremely useful. I would like to think that the skills I've learned will be useful in the future, but I've heard from several different people that Flash is pretty much irrelevant now and I can't figure out why.
I know that front end developers are using Javascript and HTML/CSS for most things, and I do understand some of the advantages. Javascript programs seem to have more open-source availability, and of course no one wants to pay a subscription for Adobe products forever. But what I don't get is what replaced the visual aspect of the "stage". Something as simple as drawing a circle could become hard really quick, or tedious at the least, if you're just using code alone. And if you draw two or more objects, you have to worry about their relative positions. Flash makes that super simple by allowing you to just drag them to where they need to be. But once again I imagine it would be really boring to have to use trial and error to position things solely with code.
So are the Javascript coders using something similar to Flash for their animations that I'm just not aware of, or are they really just using code alone? If they are just using code, WHY would they give up the stage aspect of design?

Politics, sadly. Flash was/is superior to HTML5 in almost every way (explained below), but there were a number of non-technological factors that ushered in its demise. Below are a few that come to mind:
1) Ads. This was the way most people grew to recognize Flash content; if it was flashy and annoying, it was probably Flash. This was unfortunate as it was not the technology itself that was the problem, but the use of it. (the fact that Flash was used so much for this type of content says something about how effective Flash was at creating this type of content).
2) Full Flash websites/games. Again, this was not so much a problem with Flash, but those who used it to create the content. Often devs will produce content on machines that are significantly faster than the average user's, and do most, if not all, testing locally.
3) The 1st iPhone was quite slow compared to those that exist today, and it was slow compared to a majority of computers as well. It is no surprise then that a technology that specializes in multimedia, running in a virtual machine, may have problems running on such a device; however, to say this would be to say something negative about the device, and rather than do that a 100% of the blame was put on the technology. The average consumer's experience with my previous points made this tactic easy to pull off.
4) Adobe gave up after losing the PR battle. There were many things they could have done to save Flash, such as: not dropping Android support, not dropping Flex support, not dropping Flash Builder support, and not ignoring the dwindling Flash engineer community. There is no reason why the iPhone could not run Flash today (and run it well), and there is no reason why Adobe couldn't create a transcompiler to convert content; I already did this (flash api, full as3 language support, e4x, etc.), but it's not open source as of yet. If one engineer could do this, they certainly could have!
5) Overblown publicity of Flash vulnerabilities. Critical vulnerabilities are found in programs all the time, browsers, operating systems (yes, even OS X), etc. But due to the growing discontent for Flash in the general public, issues found in Flash were covered as if Flash was the only program that was exposing people to vulnerabilities.
Technology: Is/was Flash tech superior? Absolutely, HTML5 was actually a huge step back, and here is why:
1) Flash was stable. If you got your app to work, it would almost be guaranteed not only to function exactly the same in all browsers and operating systems, but also to look identical as well. Want to develop an HTML5 app? Either use a javascript library to fix all/most browser inconsistencies, or welcome yourself to a debugging nightmare. So, of course, you add that abstraction layer, but now what happens when you still have an issue? Well, now you have to dig through that layer..
2) Flash/AS3 does it better. Want to have pixel perfect text across all devices? Flash, yes. HTML5, nope. Want REAL classes, typing, Vectors, weak references, interfaces, objects as keys, namespaces, private variables, asset embedding, etc. ? Flash, yes. HTML5.. while it's possible to create a compile-to-JavaScript language to pull most of this off, now you have to deal with that output when you're debugging. How about complex, nested, animations? How easy/fast is that to do in Flash... Sure, editors can be made to output the equivalent in HTML5, but most will not stream like Flash did, and will have severe limitations compared to what Flash can do.
3) The Flash API. The Flash API was well documented, powerful, and pretty simple to use. Compare this to the joy of searching online looking at compatibility lists and vendor prefixes for HTML5.
4) todo... there is quite a bit more.
HTML5 is better only in the fact that it is 100% open (and it's not a plugin, which people tend to dislike). The SWF specification is open, and there was an open-source Flash player (the Tamarin project); so, it is not as if Flash was completely closed like some would suggest; personally, I would trade the openness of HTML5 for stability and consistency any day.
However, if openness is one's primary concern, then one would probably view the step backwards in capability and efficiency as worth it.
BTW: I actually write all my HTML5 and NodeJS code in Flash/AS3 and compile to HTML5/JS. I can still use Flash for debugging (and as my gold standard if you will), which is fantastic..

Technology behind these drawing apps [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Can anyone please tell me what could be the technology behind http://realtimeboard.com/ and http://draw.io/? I am interested in learning that and develop such a software for as my project?

I'm pretty sure they use Canvas 2d (HTML5 API).
There are a ton of tutorials about drawing oncanvas:
https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Canvas_tutorial
http://www.html5canvastutorials.com/
Here are some libraries about canvas drawing:
http://www.jquery4u.com/javascript/10-cool-javascript-drawing-canvas-libraries/
http://fabricjs.com/ - Fabric.js is a powerful and simple Javascript
HTML5 canvas library
http://kineticjs.com/ - Enterprise class interactive web graphics
Don't rush when you pick your drawing library.
UPDATE:
realtimeboard.com seems to be based on Shockwave Flash only, see this piece of code:
<div id="realtimeboardApp"><object type="application/x-shockwave-flash" id="rtbLoader"></object></div>. I wont discuss this much further.
draw.io source code:
<div class="geDiagramContainer"><svg shape-rendering="optimizeSpeed" >[...]</svg></div>
<div class="geOutlineContainer"><svg style="[....] min-width: 3251px; min-height: 2768px;">...</svg></div> Seems to be based on SVG only, however, it still contains some SWF flash object, perhaps as a fallback mechanisms for older browsers and Internet Explorer.
On draw.io site I could identify the following libraries:
http://www.jgraph.com/mxgraph.html (just as Yuryi says), a proprietary JavaScript drawing library, a license costs between 3800€ - 25000€;
http://www.mathjax.org/, open source library for displaying math formulae.
I don't know much about Flash, except that it's obsolete, good for working with older browsers and that Adobe has discontinued its development in favor of HTML.
Updated:
MxGraph is open source now. It is now an option
Conclusion:
Although SVG seems a good technological solution, however mxGraph would not be an option for me, considering the costs and licensing restrictions on my code.
If you want a drawing library look at my earlier recommendations, or look for a SVG drawing library at http://www.farinspace.com/top-svg-javascript-libraries-worth-looking-at/.

Unfamiliar with realtimeboard, but draw.io is made via workflow library MXGRAPH: http://www.jgraph.com/mxgraph.html you can request a trial version, there's documentation, forums, sample projects etc. We're using it in our applications and it's pretty awesome.

Best way to port c++ game to web [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I realize the above question is rather broad so I will narrow it down. I have a simple opengl c++ game engine that lives in a static library (could be converted to a dynamic lib).
I have been thinking of ways of getting it to run in web. From what I can see I could use ActiveX or Google NaCl to run the c++ code in browser. But these technologies do not seem easily cross platform? Or maybe I have misunderstood.
Another option I have seen is converting the engine to javascript and WebGL and running in an HTML5 canvas. Would this be slower than c++? It would be very cross platform though.
What do you think is the best option, or better yet is there any other option I have missed?
EDIT: what about a custom plugin similar to the unity webplayer?

There is a library created by #kripken which is still under development. It takes LLVM bitcode and convert into Javascript.
You can see the project page here, with working examples.
https://github.com/kripken/emscripten/

I would strongly suggest porting to NaCl.
Advantages:
Performance: You can use the full power of the CPU to render your game. If your game uses good 3d graphics or physics, you can make it look smooth even on old system configs. The performance of NaCl is comparable to Native OS applications, it only looses nearly 5 to 10% of FPS when I compared the same game to Win32 version.
There are a lot of already ported examples, games for NaCl that can help you do it easily.
It is already cross-platform. Chrome runs on Windows, Linux, Mac OSX.
Disadvantages:
Might take you around a week to port. You have to port to OpenGL ES 2.0 (However, it should be the same with any browser based methods, especially HTML5)
Runs only on Chrome.

If you want something portable in a browser, then it has to rely on Javascript (and likely WebGL, although IE does not support that).
ActiveX and NaCL are just not portable in any way, shape or form.
I can't say which is easier, but you have an option of rewriting your game in Javascript, or using a tool like Emscripten to compile your C++ to JavaScript.
Note that if you use the latter, it's still not a silver bullet. You'll likely have to make lots of changes to your code (for example because the libraries and APIs used in your C++ game won't be available on the browser)

Why do browsers allow switching off Javascript? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
Am curious why modern browsers allow switching off Javascript.
It's so clear now that to do any substantial modern web application you need to integrate some high level of Javascript, why cant javascript be made an integral part of the browser? It becomes even more annoying especially when this option is OFF by default (IE!!)
My opinion is, it should be made a standard for all the browsers to have javascript option enabled by default.
What do you guys think?

Am curious why modern browsers allow switching off Javascript.
JavaScript:
can be used to perform very annoying operations. while (1) { alert('Have fun now.'); }
can cause performance issues
is one of the biggest sources of security problems in browsers
It's so clear now that to do any substantial modern web application
you need to integrate some high level of Javascript
No, it isn't.
why cant javascript be made an integral part of the browser?
It is an integral part of the browser. The ability to switch it off doesn't change that.
It becomes even more annoying especially when this option is OFF by default (IE!!)
I'm not sure what you mean by this, but if you are suggesting that a clean install of IE doesn't have JS turned on, then you are wrong.

I'm sure you're just venting here, but being able to turn off javascript is a very good thing for many reasons both as a developer and otherwise:
Makes it easier to debug problems with HTML and CSS
Helps with a lot of privacy issues
Can avoid malware and other security issues
Speeds up the browser, reduces memory leaks, etc
Also, fwiw, there is no browser that ships with a default of javascript being off, IE included. Perhaps you're dealing with a corporate installation with customized defaults?

IE also enables Javascript by default.
However, any web page intending to get content across can't rely on JS anyway. The option to turn it off is also a good one in case of paranoia when security vulnerabilities are at large or when you just don't want to be annoyed by all the annoying things JS is used for on modern web pages.
I consider it as good an option to have as turning images or CSS off.

What about in the corporate environment? JavaScript is used for lots of extra stuff on the internet, not least scripts, installers etc, so on that basis it's nice and easy for a company to simply disable JavaScript and quite easily prevent these issues.
In my experience disabling JavaScript also prevents annoying popups etc, which was welcomed when the interface was a touchscreen, it's not so easy to kill them off like this.
I agree that JavaScript is becoming a major part of the modern web experience, however to say 'need to integrate some high level of Javascript' I disagree with, JavaScript should be used to enhance the user experience but not rely on it. A ecommerce site should not be paralised just because JavaScript is disabled, unfortunately that is the current stae of play with some sites.
Consider researching terms such as graceful degradation and progressive enhancement.

You are making the false assumption that just because you are capable of creating a web application in JavaScript and that such an application may be of superior usability that consumers want it. Research, that I do not have to give you, suggests that users do not want usability additions when such additions are contrary to efficiency in execution or download.
Additionally, JavaScript can be used maliciously and in ways that are absolutely annoying. I remember when YouTube first attempted to introduce ads on the site. You could watch three videos and then you would be redirected to a page of ads instead of a choice of another video. In that case I turned out JavaScript to bypass the ad stupidity and then turned it back on to process the flash object request.
If I were are a security manager at a large business that did not produce web services I would recommend that JavaScript be disabled by default in the browser settings and require administrative level privileges to change it. Any browser that does not allow such administrative management from an enterprise level would be blocked from installation. In that same spirit I would also block use of Flash, completely disable the same features in Acrobat, and completely disable ActiveX. Honestly, if web businesses are not willing to provide a security solution to the horrific security condition then those businesses reliant upon such technologies would fail to receive the business of my organizations employees from company systems.

I think that it's because a lot of the script out there can be buggy, slow, or even a security risk (depending on where you are browsing). People have options, and you need to code to deal with it.