3 ms·

I dont think they will converge that fast. I definitely don't see myself writing html and javascript code for a computer program. The web languages unfortunatel

by Aegean 16y ago

I dont think they will converge that fast. I definitely don't see myself writing html and javascript code for a computer program. The web languages unfortunately are ad-hoc pieces of different technologies shuffled together. Ad-hoc is generally good, but its done in a disorganized way which is what I don't like about it. Why bring the same chaos to native?

jasonlotito 16y ago
"I definitely don't see myself writing html and javascript code for a computer program." XAML and C# are rather close in comparison. The capabilities of HTML and JS are only limited by what the browser allows. I understand your point, but I don't think the HTML/JS/Server Side language setup is far off the mark.
spot 16y ago
html and javascript are like assembly language. when/if this convergence happens you'll be using something like GWT or NaCl.
- ori_b 16y ago
  Now, once we get there, can we ditch the brainfuck-quality intermediate layer and just go from GWT or whatever to native code? But... isn't that called a native Java app?
  - spot 16y ago
    i hope so and i think that's the kind of convergence he's talking about, being able to compile GWT to either target.
jimbokun 16y ago
"Ad-hoc is generally good, but its done in a disorganized way which is what I don't like about it." I think each piece does it's job well, and better than if someone tried to somehow consolidate multiple web languages into one. HTTP has proven itself robust and versatile, especially with the wide spread adoption of REST development strategies. It also allows you free choice of language to implement on the server. Before the popularity of web development took off, language choice was largely circumscribed by the environment to which you wanted to deploy (the current controversy over iPhone OS hearkens back to those days). That's true of JavaScript in the browser today, but Javascript has proven flexible enough to allow for many different ways of programming in the browser (Cappuccino, jQuery, etc.). And simply by the size of its installed base, it is inspiring innovations in dynamic language performance that remind me of what happened with Java and byte-code virtual machines. HTML and CSS split the job of content form and appearance nicely, and the speed of HTML5 adoption by competing browsers has been impressive, in my opinion. I think that the CSS approach of separating styling from the content is superior in many ways to traditional desktop development.
- andywood 16y ago
  I think the situation with web languages and technologies is vaguely like the situation with C++ in one particular way: It isn't that they're really good, it's more that they've been around so long, evolving at glacial pace, and there is such a huge community compelled to use them, that we've collectively figured out how to make them passably effective. If I were designing a web application platform on purpose, major design criteria might be: 1) data and apps hosted remotely, 2) discoverable apps/services, 3) hypertext-style linking of resources, 4) ability to fully exploit client CPU and GPU power for UI, and for compute where appropriate, 5) consistency with common desktop UI concepts (like drag/drop), 6) flexibility in languages and developer tools, allowing for compiled, statically checked languages for those who like them. With the current web, I think we have 1-3, but not 4-6. (I think I would trade the enforced niceties of HTML/CSS for more flexibility in the UI.)

by Aegean 16y ago

jasonlotito 16y ago

"I definitely don't see myself writing html and javascript code for a computer program." XAML and C# are rather close in comparison. The capabilities of HTML and JS are only limited by what the browser allows. I understand your point, but I don't think the HTML/JS/Server Side language setup is far off the mark.

spot 16y ago

html and javascript are like assembly language. when/if this convergence happens you'll be using something like GWT or NaCl.

ori_b 16y ago
Now, once we get there, can we ditch the brainfuck-quality intermediate layer and just go from GWT or whatever to native code? But... isn't that called a native Java app?
- spot 16y ago
  i hope so and i think that's the kind of convergence he's talking about, being able to compile GWT to either target.

jimbokun 16y ago

"Ad-hoc is generally good, but its done in a disorganized way which is what I don't like about it." I think each piece does it's job well, and better than if someone tried to somehow consolidate multiple web languages into one. HTTP has proven itself robust and versatile, especially with the wide spread adoption of REST development strategies. It also allows you free choice of language to implement on the server. Before the popularity of web development took off, language choice was largely circumscribed by the environment to which you wanted to deploy (the current controversy over iPhone OS hearkens back to those days). That's true of JavaScript in the browser today, but Javascript has proven flexible enough to allow for many different ways of programming in the browser (Cappuccino, jQuery, etc.). And simply by the size of its installed base, it is inspiring innovations in dynamic language performance that remind me of what happened with Java and byte-code virtual machines. HTML and CSS split the job of content form and appearance nicely, and the speed of HTML5 adoption by competing browsers has been impressive, in my opinion. I think that the CSS approach of separating styling from the content is superior in many ways to traditional desktop development.

andywood 16y ago
I think the situation with web languages and technologies is vaguely like the situation with C++ in one particular way: It isn't that they're really good, it's more that they've been around so long, evolving at glacial pace, and there is such a huge community compelled to use them, that we've collectively figured out how to make them passably effective. If I were designing a web application platform on purpose, major design criteria might be: 1) data and apps hosted remotely, 2) discoverable apps/services, 3) hypertext-style linking of resources, 4) ability to fully exploit client CPU and GPU power for UI, and for compute where appropriate, 5) consistency with common desktop UI concepts (like drag/drop), 6) flexibility in languages and developer tools, allowing for compiled, statically checked languages for those who like them. With the current web, I think we have 1-3, but not 4-6. (I think I would trade the enforced niceties of HTML/CSS for more flexibility in the UI.)