On Friday, 30 May 2014 at 14:49:09 UTC, Marco Leise wrote:
Besides that JavaScript is single-threaded. That could be a
bit of a show stopper.
I think the most promising idea is to support PNACL+JS. If you
can write a whole app in only one language and keep the GC high
level stuff in javascrip
Am Tue, 13 May 2014 13:38:43 -0400
schrieb Etienne :
> Also, nothing says a thread pool won't be in the works if it becomes
> necessary.
Besides that JavaScript is single-threaded. That could be a
bit of a show stopper.
--
Marco
On Friday, 16 May 2014 at 19:28:26 UTC, H. S. Teoh via
Digitalmars-d wrote:
On Fri, May 16, 2014 at 02:52:43PM -0400, Nick Sabalausky via
Digitalmars-d wrote:
But then using it as a GUI engine and software platform is like
abusing Latex or PDF to make software run inside Acrobat
Viewer. All
th
On Friday, 16 May 2014 at 19:54:00 UTC, Nick Sabalausky wrote:
On 5/16/2014 3:26 PM, "Ola Fosheim Grøstad"
" wrote:
On Friday, 16 May 2014 at 18:55:44 UTC, Nick Sabalausky wrote:
You loose:
- performance
- privacy
- power user stuff
Those are very significant downsides.
Well, on me it has
On Friday, 16 May 2014 at 19:28:26 UTC, H. S. Teoh via
Digitalmars-d wrote:
No software is feature-complete until it can read email. :-)
Today I skimmed over the PDF spec... and was horrified to
discover that
I had been living in a fool's paradise, thinking that it was
only a
passive *documen
On Friday, 16 May 2014 at 06:21:40 UTC, Paulo Pinto wrote:
On my side projects, I always do native UIs and I am hoping
that the native mobile apps, finally make the people understand
that what matters is the network protocols, not the browser.
The ideas behind the browser are great, when looke
On 5/16/2014 4:03 PM, "Ola Fosheim Grøstad"
" wrote:
On Friday, 16 May 2014 at 19:54:00 UTC, Nick Sabalausky wrote:
All of that is just as easily solvable without a web browser and
HTML/CSS/JS. The browser and HTML/etc are completely incidental to the
way those were solved.
We could've had all
On 5/16/2014 3:26 PM, H. S. Teoh via Digitalmars-d wrote:
No software is feature-complete until it can read email. :-)
Heh :)
Today I skimmed over the PDF spec... and was horrified to discover that
I had been living in a fool's paradise, thinking that it was only a
passive *document* format
On 5/16/2014 3:15 PM, David Gileadi wrote:
On 5/16/14, 11:52 AM, Nick Sabalausky wrote:
But then using it as a GUI engine and software platform is like abusing
Latex or PDF to make software run inside Acrobat Viewer. All the effort,
bloat and compromises...and for what point?
I assume that que
define your own HTML5 elements with behaviour. You will
probably see UI kits for that within 1-2 years. (IE9 is holding
back development).
Stuff like this... https://angulardart.org/demo/
On Friday, 16 May 2014 at 19:54:00 UTC, Nick Sabalausky wrote:
All of that is just as easily solvable without a web browser
and HTML/CSS/JS. The browser and HTML/etc are completely
incidental to the way those were solved.
We could've had all that by now if so much effort hadn't been
wasted on
On 5/16/2014 3:26 PM, "Ola Fosheim Grøstad"
" wrote:
On Friday, 16 May 2014 at 18:55:44 UTC, Nick Sabalausky wrote:
I don't see many webapp areas than cannot run as proper software ;)
Hehe :) Well, it is a question of cost and control.
You cut:
- development costs
Ha ha hah ha. No. God no.
On Friday, 16 May 2014 at 19:28:26 UTC, H. S. Teoh via
Digitalmars-d wrote:
Today I skimmed over the PDF spec... and was horrified to
discover that
I had been living in a fool's paradise, thinking that it was
only a
passive *document* format. Turns out that it is yet another of
those
document f
On 5/16/2014 8:57 AM, Chris wrote:
Isn't it sad that we still don't have a standard we can rely on, a good
one? Web development is really turning me off. JS, HTML/CSS is a
compatibility hell. I have to use it, there's now way out, and I spend
more time trying to fix things and finding work aroun
On Fri, May 16, 2014 at 12:15:40PM -0700, David Gileadi via Digitalmars-d wrote:
> On 5/16/14, 11:52 AM, Nick Sabalausky wrote:
> >But then using it as a GUI engine and software platform is like
> >abusing Latex or PDF to make software run inside Acrobat Viewer. All
> >the effort, bloat and comprom
On Friday, 16 May 2014 at 18:55:44 UTC, Nick Sabalausky wrote:
I don't see many webapp areas than cannot run as proper
software ;)
Hehe :) Well, it is a question of cost and control.
You cut:
- development costs
- installation costs
- upgrade costs
You win:
- no more piracy
- full control o
On Fri, May 16, 2014 at 02:52:43PM -0400, Nick Sabalausky via Digitalmars-d
wrote:
> On 5/16/2014 2:21 AM, Paulo Pinto wrote:
> >
> >The ideas behind the browser are great, when looked from the Xerox
> >PARC hypermedia research, the implementation however leaves a lot to
> >be desired.
> >
> >The
On 5/16/14, 11:52 AM, Nick Sabalausky wrote:
But then using it as a GUI engine and software platform is like abusing
Latex or PDF to make software run inside Acrobat Viewer. All the effort,
bloat and compromises...and for what point?
I assume that question is mostly rhetorical, because of cours
Am 16.05.2014 20:55, schrieb Nick Sabalausky:
On 5/16/2014 6:36 AM, "Ola Fosheim Grøstad"
" wrote:
I use few native apps these days... I dont really see many application
areas that cannot run as PNaCl+Dart.
I don't see many webapp areas than cannot run as proper software ;)
+1 :)
On 5/16/2014 6:36 AM, "Ola Fosheim Grøstad"
" wrote:
I use few native apps these days... I dont really see many application
areas that cannot run as PNaCl+Dart.
I don't see many webapp areas than cannot run as proper software ;)
On 5/16/2014 2:21 AM, Paulo Pinto wrote:
The ideas behind the browser are great, when looked from the Xerox PARC
hypermedia research, the implementation however leaves a lot to be desired.
The problem is that currently it is a document format, trying to be an
application, with a clustf of J
On Friday, 16 May 2014 at 11:38:14 UTC, Paulo Pinto wrote:
On Friday, 16 May 2014 at 10:36:16 UTC, Ola Fosheim Grøstad
wrote:
On Friday, 16 May 2014 at 06:21:40 UTC, Paulo Pinto wrote:
The problem is that currently it is a document format, trying
to be an application, with a clustf of
Java
On Friday, 16 May 2014 at 10:36:16 UTC, Ola Fosheim Grøstad wrote:
On Friday, 16 May 2014 at 06:21:40 UTC, Paulo Pinto wrote:
The problem is that currently it is a document format, trying
to be an application, with a clustf of JavaScript/CSS/HTML
with more compatibility issues than when C w
On Friday, 16 May 2014 at 06:21:40 UTC, Paulo Pinto wrote:
The problem is that currently it is a document format, trying
to be an application, with a clustf of JavaScript/CSS/HTML
with more compatibility issues than when C was being
standardized.
I think it is pretty good if you remove IE
On Thursday, 15 May 2014 at 17:37:11 UTC, Nick Sabalausky wrote:
On 5/15/2014 3:51 AM, Paulo Pinto wrote:
On Wednesday, 14 May 2014 at 20:50:47 UTC, deadalnix wrote:
For the story, mozilla dropped out of the NaCl project so they
can pull out their me too solution. Now we are back to where
we
On 5/15/2014 3:51 AM, Paulo Pinto wrote:
On Wednesday, 14 May 2014 at 20:50:47 UTC, deadalnix wrote:
For the story, mozilla dropped out of the NaCl project so they
can pull out their me too solution. Now we are back to where we
were 10 years ago with the browser war. We could have one unified
s
On 5/15/2014 4:22 AM, "Ola Fosheim Grøstad"
" wrote:
On Thursday, 15 May 2014 at 05:28:56 UTC, Nick Sabalausky wrote:
While Unity3D provides a great boost in cross-platform...ability,
they've recently made it very clear they have absolutely no intention
of ever supporting any Chrome-only technol
On Thursday, 15 May 2014 at 05:28:56 UTC, Nick Sabalausky wrote:
While Unity3D provides a great boost in
cross-platform...ability, they've recently made it very clear
they have absolutely no intention of ever supporting any
Chrome-only technology. (And on top of that, even their
http://docs.u
On Wednesday, 14 May 2014 at 20:50:47 UTC, deadalnix wrote:
On Tuesday, 13 May 2014 at 17:16:18 UTC, Etienne wrote:
I'd like to point out that asm.js is a very fast subset of the
javascript language that allows almost native speeds (3x
slowdown vs C only) which enables games to be run in the
b
On Wednesday, 14 May 2014 at 20:50:47 UTC, deadalnix wrote:
On Tuesday, 13 May 2014 at 17:16:18 UTC, Etienne wrote:
I'd like to point out that asm.js is a very fast subset of the
javascript language that allows almost native speeds (3x
slowdown vs C only) which enables games to be run in the
b
On 5/14/2014 5:22 PM, "Ola Fosheim Grøstad"
" wrote:
On Wednesday, 14 May 2014 at 20:50:47 UTC, deadalnix wrote:
Until things settle down, these are cool, but useless technologies.
Not if your framework (like Unity) can compile down to multiple formats.
While Unity3D provides a great boost
On Wednesday, 14 May 2014 at 20:50:47 UTC, deadalnix wrote:
were 10 years ago with the browser war. We could have one
unified
standard int he name of NaCl, but fuck that, now we have too.
Not as long as Apple and Microsoft don't want to fuel Chrome Book
as a competing platform. I would be sur
On Tuesday, 13 May 2014 at 17:16:18 UTC, Etienne wrote:
I'd like to point out that asm.js is a very fast subset of the
javascript language that allows almost native speeds (3x
slowdown vs C only) which enables games to be run in the
browser without external dependencies.
You keep saying the
On Wednesday, 14 May 2014 at 11:12:54 UTC, Paulo Pinto wrote:
They do it via IL -> C++ -> Emscripten.
http://blogs.unity3d.com/2014/04/29/on-the-future-of-web-publishing-in-unity/
I thought they used Emscription -> ASM.js too? Anyway, it runs
smooth on my machine.
https://hacks.mozilla.org
On Wednesday, 14 May 2014 at 09:49:21 UTC, Ola Fosheim Grøstad
wrote:
On Tuesday, 13 May 2014 at 17:30:44 UTC, Nicolas F. wrote:
It also doesn't do multithreading, as far as I know.
HTML5 support Web Workers running in isolates.
Also three times slower for peak performance is not
near-native
On Tuesday, 13 May 2014 at 17:30:44 UTC, Nicolas F. wrote:
It also doesn't do multithreading, as far as I know.
HTML5 support Web Workers running in isolates.
Also three times slower for peak performance is not near-native.
They claim "1.5", but I think that is questionable.
The only good
On Tuesday, 13 May 2014 at 17:16:18 UTC, Etienne wrote:
I've been reading on Emscripten and LDC and how they would be
nice together, and came across this nice little library:
http://www.leaningtech.com/duetto/examples/
It's a C++ server/client framework that compiles to JS through
clang => L
On Wednesday, 14 May 2014 at 03:06:52 UTC, Manu via Digitalmars-d
wrote:
On 14 May 2014 04:22, Paulo Pinto via Digitalmars-d
wrote:
I thought Chrome wasn't on-board with asm.js?
Not officially, but they probably tweak V8.
I'm interested in PNaCl support in LDC, and a bunch of my
friends. I
On 14 May 2014 04:22, Paulo Pinto via Digitalmars-d
wrote:
> Am 13.05.2014 20:18, schrieb Nick Sabalausky:
>
>> On 5/13/2014 1:38 PM, Etienne wrote:
>>>
>>> and for platforms like the Chrome OS
>>> that only run JS/HTML, it's also going to be an important tool.
>>>
>>
>> I thought Chrome wasn't on
On 2014-05-13 2:22 PM, Paulo Pinto wrote:
Am 13.05.2014 20:18, schrieb Nick Sabalausky:
On 5/13/2014 1:38 PM, Etienne wrote:
and for platforms like the Chrome OS
that only run JS/HTML, it's also going to be an important tool.
I thought Chrome wasn't on-board with asm.js?
They aren't. If y
On 2014-05-13 2:21 PM, Etienne wrote:
On 2014-05-13 2:18 PM, Nick Sabalausky wrote:
On 5/13/2014 1:38 PM, Etienne wrote:
and for platforms like the Chrome OS
that only run JS/HTML, it's also going to be an important tool.
I thought Chrome wasn't on-board with asm.js?
They are on board, an
On 2014-05-13 2:18 PM, Nick Sabalausky wrote:
On 5/13/2014 1:38 PM, Etienne wrote:
and for platforms like the Chrome OS
that only run JS/HTML, it's also going to be an important tool.
I thought Chrome wasn't on-board with asm.js?
They are on board, and ironically it runs faster on Chrome's
Am 13.05.2014 20:18, schrieb Nick Sabalausky:
On 5/13/2014 1:38 PM, Etienne wrote:
and for platforms like the Chrome OS
that only run JS/HTML, it's also going to be an important tool.
I thought Chrome wasn't on-board with asm.js?
They aren't. If you look at Chrome Dashboard, integration of
On 5/13/2014 1:38 PM, Etienne wrote:
and for platforms like the Chrome OS
that only run JS/HTML, it's also going to be an important tool.
I thought Chrome wasn't on-board with asm.js?
On 2014-05-13 1:30 PM, Nicolas F. wrote:
The only good idea that I see in this is that it allows you to do
client-side web-development without having to use J
I do believe it would allow some web frameworks and UI projects to run
faster by reducing the massive use of fallback scopes and Hash
I'd like to point out that asm.js is a very fast subset of the
javascript language that allows almost native speeds (3x
slowdown vs C only) which enables games to be run in the
browser without external dependencies.
It also doesn't do multithreading, as far as I know. Also three
times slower
I've been reading on Emscripten and LDC and how they would be nice
together, and came across this nice little library:
http://www.leaningtech.com/duetto/examples/
It's a C++ server/client framework that compiles to JS through clang =>
LLVM bytecode => ASM.js.
I'd like to point out that asm.
I've been reading on Emscripten and LDC and how they would be nice
together, and came across this nice little library:
http://www.leaningtech.com/duetto/examples/
It's a C++ server/client framework that compiles to JS through clang =>
LLVM bytecode => ASM.js.
I'd like to point out that asm.js
wrong button ;)
49 matches
Mail list logo
