4 ms·

> If you know JS fairly well, you're able to understand nearly everything under the hood if you want to. Your definition of "under the hood" is somewhat questi

by weland 13y ago

> If you know JS fairly well, you're able to understand nearly everything under the hood if you want to. Your definition of "under the hood" is somewhat questionable. Yes, you can understand everything down to the JS layer which is basically the first step below the visible UI, but the full stack on which the JS runtime rests is of a dizzying height, and each one of its layers has performance implications. > If you have CLR/JVM in addition, this just brings more problems to the table, especially when you have to deal with much more languages which do not "compile" to JS or when you have to deal with proprietary APIs/Libraries. What problems, more precisely? What's the difference between compiling C++ to JS and compiling C++ for an open VM?

anonyfox 13y ago
> What problems, more precisely? What's the difference between compiling C++ to JS and compiling C++ for an open VM? Fair enough. Personally i see crosscompiler like Emscripten as a way to port already existing stuff over to JS. But i do not see the point why i would want to build a new application that targets JS in C++. You would loose the "native" performance of C++ and don't have the high-level language constructs to deal with common problems... even bread-and-butter string manipulation just takes more time (not too much, but just more) in C++ than for example in Coffeescript.
- weland 13y ago
  > But i do not see the point why i would want to build a new application that targets JS in C++. The main reasons I'd avoid writing any application that is either performance-sensitive or at least modestly complex are bad (or sometimes utterly inexistent) tooling, unstable and unpredictable environment and hidden complexity. Writing in C++ would alleviate at least some of the bad/inexistent tooling, but not much. I know this sounds strange to a web developer, but to someone coming from a hefty desktop/systems programming background, even the latest JS development tools are a joke. Coding for the web today feels worse than coding for X11 in 1996 (and we were equally enthusiastic about it). What I would like to see for the web is exactly that: a language on which writing a codebase larger than a hundred lines isn't a piggybacked thing. Java had its problems (which were probably rooted in its far poorer integration with the web browser, compared to where JavaScript is today), but it had some nice features of its own: the stack behind your Java applet was a lot thinner (dear God, I thought I'd never live to say that!) than the JS environment and consequently a lot more predictable, even with its dreaded garbage collector, tooling was somewhere at the same level (but 15 years ago!) and the applets were in fact portable. Portable as in, they actually ran pretty much on anything that could run Java code (yes, regrettably that was in the form of a proprietary plug-in, but it need not be that way), as opposed to any JS trick that even begins to be impressive, which breaks on pretty much every other configuration. The "native" performance of C++ is, IMHO, a poorly-stated idea in communities that like to call themselves "geek communities". If you were to write, in C++, a program that performs exactly the same functions, down to every abstraction layer (e.g. bytecode compiling, garbage collecting, decoding and rendering HTML etc.) and thus end up with exactly the same machine instructions, you'd arguably get a program that runs just as slowly, waiting for the same kind of I/O to complete and so on. You can get a performance equal to that of native-compiled C++ by compiling JS to native code. That, unfortunately, has its own problems, which we painfully remember from the days of ActiveX. History doesn't repeat itself, but it rhymes so much! Edit: personal rant: I honestly think much of today's web application ecosystem exists because a lot of programmers were lazy, in a bad way. Back in the late 1990s, we were hoping that we'd use the web for awesome, collaboration- or communication-driven applications. That dynamic websites ("web app" is a misnomer IMHO) would be a better way of achieving some things because they'd let people communicate together. But 90% of the "web apps" I see today literally don't do that, or do so with things that are utterly useless, like sharing todo lists with friends (unless it's a really jealous spouse, the amount of your todo list that you have to share really fits in the timeframe of a phone call...). Countless HTTP requests are made, but communication happens between a single client and a single server. It's like a native program, except all I/O operation are a few tens of thousands of times slower. The problems they solve are entirely different, and in fact well within the capacity of "native" development tools: portability, accessibility and so on. I honestly think because, at some point, several million kids who learned HTML and some PHP from web tutorials wanted to make really useful things, but just didn't want to learn how to use more adequate tools and started beating the ones they had into submission.

by weland 13y ago

anonyfox 13y ago

> What problems, more precisely? What's the difference between compiling C++ to JS and compiling C++ for an open VM? Fair enough. Personally i see crosscompiler like Emscripten as a way to port already existing stuff over to JS. But i do not see the point why i would want to build a new application that targets JS in C++. You would loose the "native" performance of C++ and don't have the high-level language constructs to deal with common problems... even bread-and-butter string manipulation just takes more time (not too much, but just more) in C++ than for example in Coffeescript.

weland 13y ago
> But i do not see the point why i would want to build a new application that targets JS in C++. The main reasons I'd avoid writing any application that is either performance-sensitive or at least modestly complex are bad (or sometimes utterly inexistent) tooling, unstable and unpredictable environment and hidden complexity. Writing in C++ would alleviate at least some of the bad/inexistent tooling, but not much. I know this sounds strange to a web developer, but to someone coming from a hefty desktop/systems programming background, even the latest JS development tools are a joke. Coding for the web today feels worse than coding for X11 in 1996 (and we were equally enthusiastic about it). What I would like to see for the web is exactly that: a language on which writing a codebase larger than a hundred lines isn't a piggybacked thing. Java had its problems (which were probably rooted in its far poorer integration with the web browser, compared to where JavaScript is today), but it had some nice features of its own: the stack behind your Java applet was a lot thinner (dear God, I thought I'd never live to say that!) than the JS environment and consequently a lot more predictable, even with its dreaded garbage collector, tooling was somewhere at the same level (but 15 years ago!) and the applets were in fact portable. Portable as in, they actually ran pretty much on anything that could run Java code (yes, regrettably that was in the form of a proprietary plug-in, but it need not be that way), as opposed to any JS trick that even begins to be impressive, which breaks on pretty much every other configuration. The "native" performance of C++ is, IMHO, a poorly-stated idea in communities that like to call themselves "geek communities". If you were to write, in C++, a program that performs exactly the same functions, down to every abstraction layer (e.g. bytecode compiling, garbage collecting, decoding and rendering HTML etc.) and thus end up with exactly the same machine instructions, you'd arguably get a program that runs just as slowly, waiting for the same kind of I/O to complete and so on. You can get a performance equal to that of native-compiled C++ by compiling JS to native code. That, unfortunately, has its own problems, which we painfully remember from the days of ActiveX. History doesn't repeat itself, but it rhymes so much! Edit: personal rant: I honestly think much of today's web application ecosystem exists because a lot of programmers were lazy, in a bad way. Back in the late 1990s, we were hoping that we'd use the web for awesome, collaboration- or communication-driven applications. That dynamic websites ("web app" is a misnomer IMHO) would be a better way of achieving some things because they'd let people communicate together. But 90% of the "web apps" I see today literally don't do that, or do so with things that are utterly useless, like sharing todo lists with friends (unless it's a really jealous spouse, the amount of your todo list that you have to share really fits in the timeframe of a phone call...). Countless HTTP requests are made, but communication happens between a single client and a single server. It's like a native program, except all I/O operation are a few tens of thousands of times slower. The problems they solve are entirely different, and in fact well within the capacity of "native" development tools: portability, accessibility and so on. I honestly think because, at some point, several million kids who learned HTML and some PHP from web tutorials wanted to make really useful things, but just didn't want to learn how to use more adequate tools and started beating the ones they had into submission.