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 5 years ago.
Improve this question
I'm looking into the possibilities of creating a Javascript application which makes use webGL.
Since webGL is only available in a couple of browsers, and I do not want to force people to use a certain browser (directly), I would like to offer a standalone app client download aswell.
Would it be possible to somehow create a borderless and standalone "fake browser" client which has my app embedded for both linux and windows?
This would allow me to distribute a standalone client without having to modifiy my application code.
jslibs is a standalone JavaScript runtime that has a good support of OpenGL. Look at these samples.
WebGL support has been offered in WebKit builds for more than a year. So if your clients use Macintosh computers then you could create a standalone application using WebKit.
And that is just for the time being. By next year, I think you will see support for WebGL in every major browser except IE, which is experiencing a dwindling user base.
Alternatively, you could write a plugin/addon for each major browser, including IE. That is more work for you. If you do not want to leave the web standards to the browser makers, you can take up the challenge yourself.
Probably not the best plan in the long term, though. They will continually optimize for speed, memory efficiency, rendering quality, and responsiveness. You probably will not want to put the same amount of continuous effort into it as them. You probably will not offer the same cross platform support they do.
Creating an application specific browser (ASB) with one of the standard toolkits, and then transitioning to using web browsers directly a short ways down the road is probably the way to go. No reason why you cannot work out the compatibility testing for that strategy now, since the browsers with support for it are already in public beta.
So you want to write a standalone platform-independant application in javascript that can use opengl?
I would try making a JOGL application.
Related
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
With the release of Chrome 77 the Web Serial API became available with the use of an experimental flag. This is particularly useful for desktop applications running in NW.js or Electron, where NodeJS has previously (and still does to a large degree) provided a bridge between web and native.
I find myself very much wanting to abandon the use of NPM packages like serialport, which extend both NW.js and Electron to provide serial port access.
While Electron 8.0.1 does make available navigator.serial, it's not exactly clear how much of the API is actually implemented. To further complicate things, there is no good documentation for the API (at least in my search) besides https://wicg.github.io/serial/ and https://github.com/WICG/serial/blob/gh-pages/EXPLAINER.md. I've tried tinkering with it on my own, but it's not clear whether I'm using it incorrectly, or whether parts simply aren't implemented.
So what is the status of this API? Which parts are reliably implemented (in Chromium), and is there any indication of when this will be ready for prime time? I think a lot of people are wondering this as it opens quite a few doors for interaction with the user's PC.
Here are some resources for tracking the status of the Serial API and its implementation in Chromium,
Draft Specification, as you've pointed out it is incomplete and I'm working on fixing that.
Specification "explainer", this is a less formal introduction to the specification and a more up-to-date reference for the current design of the API.
Chrome Platform Status entry, this tracks the official implementation status in Chrome.
Chromium implementation tracking issue, star this issue for updates as the implementation work progresses.
Polyfill library, this library uses WebUSB to implement the API for standard USB CDC class devices. Think of this at the moment as a prototype of what the API could look like when implemented in a browser.
Code lab, if you're looking for a larger example of how to use the API this code lab explains how to get started communicating with a particular device in a step-by-step fashion.
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 7 years ago.
Improve this question
I am new to front end development. Let's say hypothetically my clients have modern hardware, 2.20 GHz CPU, 4GB ram. A flashy website that uses a lot of event handlers, and animations like "slide for div containers to move in and out on users click" and "jquery "on" click for mustache templates created on the fly with ajax (for elements being added after initial DOM load).
I know it depends if my programming skills are really terrible which could be causing the user end to perform really poorly, but lets say I program as close to efficient as possible, and use very well written plug-ins.
Question - Do clients with that hardware handle a highly customized design well? Are browser development tools the best out there in terms of troubleshooting and analyzing performance, or is there a highly popular widely used tool that does the job for a lot of developers?
My question focuses on two key points.
Client Side Performance based on sleek and flashy websites using
plugins mentioned below on modern hardware.
What do developers use to help them check hardware utilization,
profile and troubleshoot issues.
browser development tools is sufficient?
A popular tool widley used by developers that I haven't discovered?
Additional Notes
I am also using my application server to host these files since I am using MVC so its not completely static html files. Plugins include:
Jquery
BootstrapJS
Bootstrap Max Length
Jquery UI(Effects Corewith Slidejs, its 14Kb in size)
Jquery Uniform
MustacheJS
Jquery Uniform took the biggest hit on page load times I called it on about 100 elements when the page loaded. So I changed it by calling it on elements that needed it when the client clicks on a div to slide open on specific selectors.
What influenced my question?
Toying around and reading about Angularjs. Since everything is client side, I read mixed feelings on it slowing the client down and possibly speeding it up. Since I am already knee deep in Jquery I was curious how well it performs with the more modern hardware using a lot of flashy components and DOM manipulation that I mentioned above. This is my first front end design, so I know more seasoned Front End Developers know how well browsers handle these knew frameworks being used.
Why it's important
The temptation to add all the glitter and flashiness to a webpage to make it look more attractive to the client, could actually work against me is a concern.
In my experience you can have hundred of thousands of DOM elements, thousands of objects with arrays inside and nothing happens. In the web are many awful sites made up like Frankenstein's monsters with literally dozens of libraries and have not performance problems in computers from 15 years ago.
While you don't mess with 3d rendering and that experimental things you won't have problems in mainstream PCs. I don't know what your flashy cool features are. Also if you are very bad programming and make almost never-ending loops or something like that could be a problem, but that's anywhere.
Another problem is the download time, and is the most important thing to care about, if you have tons of code it will take longer to download. Usually in server applications you prefer performance before lightness but in the front end is better to download small files. Internet always will be slower than the CPU and RAM.
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
I have read this article (Uses of Javascript), while it is right I know there are other uses of javascript, modern javascript nowadays. I haven't read about node.js and how this one works but I have heard that this one makes js do server-side stuffs?
The question is, what are other uses of javascript, can this replace php and ruby? I know this might not be a good idea for enterprise applications but will work well with medium-size applications, am I right?
What are the other uses of javascript other than the one given in the article?
Javascript can very well be used server side. If you're on an IIS server, you can for example use JScript, nodejs, v8cgi (currently known as TeaJS), or a combination of these. On *nix servers nodejs is a popular framework. Nodejs can even be used to program your own webserver (e.g. using the expressjs framework).
Dive in the given links and see what's possible.
There is TESSEL and Espruino javascript inside microcontroller.
I use Node.js for web application for few years, few projects and really happy so far.
The Express.js + MongoDB makes a perfect match (exactly as PHP + MySQL, 5 years ago). You can find reference on MEAN stack.
It works good no only for small applications. We have medium-size app that could be easily scaled up.
Node.js is not to about substitute PHP or Ruby, but what's happening now is indeed, it's more and more used for web applications nowaday. The reason is simple, Node.js has "web-oriented" core, meaning it's originally created to aim highly productive tcp/http applications. With some progress beautiful web development frameworks appeared on top of Node.js that makes web application development even more easy and fun.
For me, programming Node.js on server makes a lot of sense, since JavaScript is main client-side language (almost without alternatives), so context-switching between client/server programming is less. With practice you get use to some initial JavaScript weirdness and things goes smooth and nice.
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
I know how to do my jobs by C++. I like to move most of
them to Windows Script Host JScript. But Windows JScript
doesn't do many important things.
Many JavaScript kernels are open source, and we have node.js,
processing.js already.
So we need to be able to build our own JavaScript interpreter
so as to bypass JScript. This sounds true for desktop applications
, right?
I need some hints to start it. It's worthy even if it takes years.
JScript limitations are :
1. can't access hardware.
2. can't do things that need administrator privilege.
A JScript wrapper like xNeat http://www.xneat.com helps JScript to call APIs. But it does not work with WinIO (access I/O ports and physical memory) because WinIO needs administrator privilege that is not allowed by JScript.
I'll try to compile V8 or the likes and remove restrictions it intentionally made for security then add some low level interfaces to call Windows APIs, which JScript can't do. I think this is cool. Maybe I don't even need to do that again because somebody already done that?
You seriously need a lot more research... I'll try & save a few flops of Google:
JScript != JavaScript. Assuming you are using them interchangably
without knowing about the existence of proprietary JScript from
Microsoft..
Javascript was never meant to do things you mention as limitations. It's supposed to run in web browsers & obviously a random website whose JS it is, should not be able to access/execute anything in the user's machine.
Although contrary to belief that JS does not need to touch the file system, the filesystem API was brought in. I feel, that expands the boundaries wide enough for any web application to leverage on.
Besides, you can always develop desktop apps for windows 8 in JS, by the libraries exposed by Microsoft, but that's another story.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Why don't browsers add support for, say, Python scripting as an alternative to Javascript? Or more general purpose scripting languages? Is there a reason that Javascript is the only one implemented across browsers? After all, the script tag does have support to specify the scripting language used.
(I know there is VBScript support in IE, but it seems obsolete for all intents and purposes.)
Well, Google is trying to buck that trend with Dart. The community hasn't been entirely receptive to the idea; either.
Google proposed adding multiple VM support for Webkit which didn't go down very well.
One particular comment summed it up nicely as to why there has been some resistance to that:
In this case the feature is exposing additional programming languages to the web, something without any real benefit to anyone other than fans of the current "most awesome" language (not too long ago that might have been Go, a year or so ago this would have been ruby, before than python, i recall i brief surge in haskell popularity not that long ago as well, Lua has been on the verges for a long time, in this case it's Dart -- who's to say there won't be a completely different language in vogue in 6 months?), but as a cost it fragments the web and adds a substantial additional maintenance burden -- just maintaining the v8 and jsc bindings isn't trivial and they're for the same language.
The issue here isn't "can we make multiple vms live in webkit" it's "can we expose multiple languages to the web", to the former i say obviously as we already do, to the latter I say that we don't want to.
Unless we want to turn webkit into the engine that everyone hates because of all its unique "features" that break the open web, a la certain browsers in the late 90s.
CoffeeScript is another example of an emerging client-side scripting language. However, rather than support another virtual machine in a browser (as Google is trying to do with Dart), it compiles to JavaScript. There are several other "compile X to JavaScript" that do that as well. emscripten is a good example of compiling LLVM to JavaScript.
So there are plenty of other client languages; they just all use JavaScript as an intermediate. I'd argue that should be what Dart does as well, though they have some room to improve.
Internet Explorer supports any Windows Script Engine, so you can make it support any language that has been implemented as one, or write your own.
Because JavaScript is what every other browser supported, and browser vendors had two main priorities:
Making sure existing webpages worked (which requires JavaScript)
Letting authors do user visible things in their browser that they couldn't do in other browsers (changing programming language would be entirely hidden from users, except when it broke).