To what extent can I have faith in dart2js [closed] - javascript

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 9 years ago.
Improve this question
I was seduced by the Dart language and I would like to build my future webapp in this language, but since only chrome supports to this day this language (and it is unlikely that other browsers will follow) I put all my hopes in dart2js to convert my future application in pure javascript. But I'm afraid I have bad surprises once the work is completed, my question is simple: can I have complete confidence in this tool whatever the target browser is?
Edit1: I understand that the cross-browser compatibility is mainly the job of the developer
Edit2: What I exactly mean is: to what extent can I have confidence that dart2js will convert my entire webapp once finished, that it will not encounter an "internal error" while doing it.

First of all, Chrome does not actually support Dart natively at this point in time (although it is planned for the future). "Unlikely that other browsers will follow" is not necessarily true, it depends on a whole host of factors (e.g. language popularity, performance gains, etc.), but I agree with you that you should only consider dart2js as a viable target at this point.
You can't have complete confidence that dart2js will work exactly the same regardless of browser. But that is the nature of the web currently; different browsers render things differently, have their own bugs and quirks, and in general do not work the same way.
Whether you are developing in Dart and using dart2js, or in Java and using the GWT compiler, or in JavaScript itself, there is no guarantee that the application will work properly across browsers. It is up to you as the developer to test each browser target to verify that it works as expected.
However, since dart2js only supports modern browsers, the discrepancies you will encounter will likely be minor (as opposed to the discrepancies you will discover running an application in latest Chrome vs. IE8 for instance).

Related

Pre-compiled versions of often used scripts in browsers [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 8 years ago.
Improve this question
Does anyone know why browsers such as Chrome, FF and IE don't just have all famous scripts embedded in their install? They could have all the versions of jquery, for example, pre-compiled (i.e. in V8 for chrome) and the browser would just be able to recognize the reference to a cdn or simply a local script by the name of the script. And really, how much greater would that make the install of the browser if you included all version of, say, jquery, angular, dojo and ext? Compiled to C++ via V8 these scripts aren't very large at all.
Sure, you could say, 'but then it won't use the modifications I made in jquery-2.1.3.js'. True, but that's just horrible engineering.
It would be faster and save bandwidth.
But there is probably something I'm overlooking. There always tends to be.
Because there is already a whole protocol related to delivering resources to browsers and for caching them on client side and sending headers to tell the browsers when they should check for new versions.
Also, filename-1.2.3.js don't tell the whole story. There is also a build number after major, minor and patch. See http://semver.org/
You couldn't expect distinct browser vendors to take the responsibility to update their browsers every time any script was being updated or built. It'd simply slow down the delivery. Considering there already is a protocol for it. HTTP.

JScript user asks how to build a a home made JavaScript interpreter to avoid limitations [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
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.

Is Google's V8 engine really limited to 1 VM per process? [closed]

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
I can't get a straight forward answer on this. Is Google's V8 engine really limited to 1 VM per process?
If google's v8 engine is limited to only 1 VM per process, then doesn't it sort of exclude itself from being used in libraries? Say I code up a c++ library that uses V8 called LibA. And someone else codes up another library that uses V8 called LibB. If an application links to both LibA and LibB bad stuff would happen (right?).
I need a fast (with speed being the most important requirement actually) javascript parser for a lib I'm trying to write, but I don't want to use v8 if I'll run into this problem (it's likely that the kind of applications that link to it will also use v8 at some point).
Based on this closed bug report, it's safe to say that Google's V8 engine is not limited to a single thread per process (since approximately April 2011).

Why is javascript the only client side scripting language implemented in browsers? [closed]

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).

Standalone webGL/Javascript client? [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 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.

Categories