GWT - Revision history

JaroslavTulach: /* Common Ground and WORA */

JaroslavTulach — Wed, 29 Jan 2014 16:45:53 GMT

Common Ground and WORA

←Older revision		Revision as of 16:45, 29 January 2014
Line 30:		Line 30:
	The days when [[wikipedia:Write_once,_run_anywhere\|WORA]] was the biggest strength of [[Java]] seemed to come to their ends. If you want to target browsers now, you need to deploy [[JavaScript]]. But that does not mean you have to write [[JavaScript]]! We can (re)design the roots of [[Java]] and together find a common ground for the [[Java]] as we know it (aka [[HotSpot]]) and [[Java]] that fits into browsers.		The days when [[wikipedia:Write_once,_run_anywhere\|WORA]] was the biggest strength of [[Java]] seemed to come to their ends. If you want to target browsers now, you need to deploy [[JavaScript]]. But that does not mean you have to write [[JavaScript]]! We can (re)design the roots of [[Java]] and together find a common ground for the [[Java]] as we know it (aka [[HotSpot]]) and [[Java]] that fits into browsers.

-	[[Bck2Brwsr]] [[framework]] can be such common ground. If you care about [[Java]], join us to make [[Bck2Brwsr\|it better]].	+	[[Bck2Brwsr]] [[framework]] can be such common ground. If you care about [[Java]], join us to make [[Bck2Brwsr\|it better]]. Consider [[MigrateFromGWT\|migrating from GWT]] - it is so easy!

JaroslavTulach: /* Slow JavaScript Interpreters and Doing Less Work */

JaroslavTulach — Thu, 25 Apr 2013 05:18:22 GMT

Slow JavaScript Interpreters and Doing Less Work

←Older revision		Revision as of 05:18, 25 April 2013
Line 9:		Line 9:
	* one does not need to write parser to create a [[Java]] [[AST]]		* one does not need to write parser to create a [[Java]] [[AST]]
	* one does not need to do attribution - e.g. resolve fully qualified names of every symbol		* one does not need to do attribution - e.g. resolve fully qualified names of every symbol
-	* new ~~version~~ of the [[Java]] language are supported (almost) immediately	+	* new versions of the [[Java]] language are supported (almost) immediately
	All of this has already been done by [[JavaC]] when generating the [[ByteCode]]. [[Bck2Brwsr]] can use such information, become more effective and at the end fit into the browser.		All of this has already been done by [[JavaC]] when generating the [[ByteCode]]. [[Bck2Brwsr]] can use such information, become more effective and at the end fit into the browser.

JaroslavTulach: /* Slow JavaScript Interpreters and Doing Less Work */

JaroslavTulach — Thu, 25 Apr 2013 05:18:12 GMT

Slow JavaScript Interpreters and Doing Less Work

←Older revision		Revision as of 05:18, 25 April 2013
Line 9:		Line 9:
	* one does not need to write parser to create a [[Java]] [[AST]]		* one does not need to write parser to create a [[Java]] [[AST]]
	* one does not need to do attribution - e.g. resolve fully qualified names of every symbol		* one does not need to do attribution - e.g. resolve fully qualified names of every symbol
		+	* new version of the [[Java]] language are supported (almost) immediately
	All of this has already been done by [[JavaC]] when generating the [[ByteCode]]. [[Bck2Brwsr]] can use such information, become more effective and at the end fit into the browser.		All of this has already been done by [[JavaC]] when generating the [[ByteCode]]. [[Bck2Brwsr]] can use such information, become more effective and at the end fit into the browser.

JaroslavTulach at 05:16, 25 April 2013

JaroslavTulach — Thu, 25 Apr 2013 05:16:52 GMT

←Older revision		Revision as of 05:16, 25 April 2013
Line 1:		Line 1:
-	[[wikipedia:Google_Web_Toolkit\|GWT]] is a [[Java]] port that runs in a browser, but (unlike [[Bck2Brwsr]] project) compiles on the desktop. The [[GWT]] compiler runs in real [[VM]] (e.g. [[HotSpot]]) and translates [[Java]] code to static [[JavaScript]]. As such [[GWT]] looses a lot of the dynamism [[Java]] could offer - late bindings of classes and libraries, generating [[bytecode]] on the fly, loading new classes, using reflection, etc. is hard/almost impossible in [[GWT]].	+	[[wikipedia:Google_Web_Toolkit\|GWT]] is a [[Java]] port that runs in a browser, but (unlike [[Bck2Brwsr]] project) compiles to [[JavaScript]] on the desktop. The [[GWT]] compiler runs in real [[VM]] (e.g. [[HotSpot]]) and translates [[Java]] code to static [[JavaScript]]. As such [[GWT]] looses a lot of the dynamism [[Java]] could offer - late bindings of classes and libraries, generating [[bytecode]] on the fly, loading new classes, using reflection, etc. is hard/almost impossible in [[GWT]].

	=== Slow [[JavaScript]] Interpreters and Doing Less Work ===		=== Slow [[JavaScript]] Interpreters and Doing Less Work ===

JaroslavTulach: /* Common Ground and WORA */

JaroslavTulach — Thu, 21 Mar 2013 20:40:38 GMT

Common Ground and WORA

←Older revision		Revision as of 20:40, 21 March 2013
Line 27:		Line 27:
	=== Common Ground and WORA ===		=== Common Ground and WORA ===

-	The days when [[wikipedia:Write_once,_run_anywhere\|WORA]] was the biggest strength of [[Java]] ~~are gone~~. If you want to target browsers you need to deploy [[JavaScript]]. But that does not mean you have to write [[JavaScript]]! We can (re)design the roots of [[Java]] and together find a common ground for the [[Java]] as we know it (aka [[HotSpot]]) and [[Java]] that fits into browsers.	+	The days when [[wikipedia:Write_once,_run_anywhere\|WORA]] was the biggest strength of [[Java]] seemed to come to their ends. If you want to target browsers now, you need to deploy [[JavaScript]]. But that does not mean you have to write [[JavaScript]]! We can (re)design the roots of [[Java]] and together find a common ground for the [[Java]] as we know it (aka [[HotSpot]]) and [[Java]] that fits into browsers.

-	[[Bck2Brwsr]] ~~projects~~ can be such common ground. If you care about [[Java]], join us to make [[Bck2Brwsr\|it better]].	+	[[Bck2Brwsr]] [[framework]] can be such common ground. If you care about [[Java]], join us to make [[Bck2Brwsr\|it better]].

JaroslavTulach: /* Language or a Framework? */

JaroslavTulach — Thu, 21 Mar 2013 20:39:24 GMT

Language or a Framework?

←Older revision		Revision as of 20:39, 21 March 2013
Line 23:		Line 23:
	In one of my essays I asked: Is [[Java]] language or a [[framework]]? [[GWT]] answers such question clearly: [[Java]] is seen as a language. The fact that there is also a [[VM]] specification is put aside. The fact that various systems/languages can talk via [[ByteCode]] to each other, is ignored.		In one of my essays I asked: Is [[Java]] language or a [[framework]]? [[GWT]] answers such question clearly: [[Java]] is seen as a language. The fact that there is also a [[VM]] specification is put aside. The fact that various systems/languages can talk via [[ByteCode]] to each other, is ignored.

-	On the other hand [[Bck2Brwsr]] tries to treat [[Java]] as a [[framework]]. The [[VM]] interface is there, [[ByteCode]] is the lingua franca which the [[Bck2Brwsr]] [[VM]] understands. Sure, the [Bck2Brwsr]] framework is not full ~~feature~~ [[Modular Java SE\|Java SE]] - it is a subset. But a base, common subset that can grow.	+	On the other hand [[Bck2Brwsr]] tries to treat [[Java]] as a [[framework]]. The [[VM]] interface is there, [[ByteCode]] is the lingua franca which the [[Bck2Brwsr]] [[VM]] understands. Reflection is naturaly present. Sure, the [[Bck2Brwsr]] [[framework]] is not full featured [[Modular Java SE\|Java SE]] - it is a subset. But a base, common subset that can grow and behave same in browsers as well as [[HotSpot]].

	=== Common Ground and WORA ===		=== Common Ground and WORA ===

JaroslavTulach: /* Gmail Web Toolkit */

JaroslavTulach — Thu, 21 Mar 2013 20:37:08 GMT

Gmail Web Toolkit

←Older revision		Revision as of 20:37, 21 March 2013
Line 15:		Line 15:
	[[GWT]] started as a framework to allow [[Google]] to write Gmail. In fact, it is almost clear it was the opposite way - the goal was to write Gmail (with permission to do it in ''experimental [[Java]]'') - to support this goal [[GWT]] was created. First of all only internally, then it was released as a toolkit of its own.		[[GWT]] started as a framework to allow [[Google]] to write Gmail. In fact, it is almost clear it was the opposite way - the goal was to write Gmail (with permission to do it in ''experimental [[Java]]'') - to support this goal [[GWT]] was created. First of all only internally, then it was released as a toolkit of its own.

-	However the history ~~shows~~ - [[GWT]] is perfect for writing ~~Gmail.~~ Gmail and applications that look like Gmail. But be honest, do you really want to write applications like that? And when you want something just a little different, don't you feel [[GWT]] is a bit too heavyweight?	+	However the history remains - [[GWT]] is perfect for writing Gmail and applications that look like Gmail. But be honest, do you really want to write applications like that? And when you want something just a little different, don't you feel [[GWT]] is a bit too heavyweight?

	[[Bck2Brwsr]] is different. It started small with the goal to have as small [[Java]] as possible. Support just as little as possible to bootstrap [[Bck2Brwsr]] - this means less than 100 classes. The rest of the system is [[modular]] - look at the [[Bck2BrwsrJavadoc]]. It contains ''minimal'' emulation library, it contains [[Bck2Brwsr]] profile (the standard library people code against). When you want more - like access to an [[HTML]] page - you can use another library. When you want to use widgets (like [[Java]] FX ones) - add another library. If you don't need them, don't include such library and your framework is still going to be as slim as possible (currently ~200KB gzipped).		[[Bck2Brwsr]] is different. It started small with the goal to have as small [[Java]] as possible. Support just as little as possible to bootstrap [[Bck2Brwsr]] - this means less than 100 classes. The rest of the system is [[modular]] - look at the [[Bck2BrwsrJavadoc]]. It contains ''minimal'' emulation library, it contains [[Bck2Brwsr]] profile (the standard library people code against). When you want more - like access to an [[HTML]] page - you can use another library. When you want to use widgets (like [[Java]] FX ones) - add another library. If you don't need them, don't include such library and your framework is still going to be as slim as possible (currently ~200KB gzipped).

JaroslavTulach: /* Gmail Web Toolkit */

JaroslavTulach — Thu, 21 Mar 2013 20:36:35 GMT

Gmail Web Toolkit

←Older revision		Revision as of 20:36, 21 March 2013
Line 13:		Line 13:
	=== Gmail Web Toolkit ===		=== Gmail Web Toolkit ===

-	[[GWT]] started as a framework to allow [[Google]] to write Gmail. In fact, it is almost clear it was the opposite way - the goal was to write Gmail (with permission to do it in ''experimental [[Java]]'') - to support this goal [[GWT]] ~~has been~~ created. First of all only internally, then it was released as a toolkit of its own.	+	[[GWT]] started as a framework to allow [[Google]] to write Gmail. In fact, it is almost clear it was the opposite way - the goal was to write Gmail (with permission to do it in ''experimental [[Java]]'') - to support this goal [[GWT]] was created. First of all only internally, then it was released as a toolkit of its own.

	However the history shows - [[GWT]] is perfect for writing Gmail. Gmail and applications that look like Gmail. But be honest, do you really want to write applications like that? And when you want something just a little different, don't you feel [[GWT]] is a bit too heavyweight?		However the history shows - [[GWT]] is perfect for writing Gmail. Gmail and applications that look like Gmail. But be honest, do you really want to write applications like that? And when you want something just a little different, don't you feel [[GWT]] is a bit too heavyweight?

	[[Bck2Brwsr]] is different. It started small with the goal to have as small [[Java]] as possible. Support just as little as possible to bootstrap [[Bck2Brwsr]] - this means less than 100 classes. The rest of the system is [[modular]] - look at the [[Bck2BrwsrJavadoc]]. It contains ''minimal'' emulation library, it contains [[Bck2Brwsr]] profile (the standard library people code against). When you want more - like access to an [[HTML]] page - you can use another library. When you want to use widgets (like [[Java]] FX ones) - add another library. If you don't need them, don't include such library and your framework is still going to be as slim as possible (currently ~200KB gzipped).		[[Bck2Brwsr]] is different. It started small with the goal to have as small [[Java]] as possible. Support just as little as possible to bootstrap [[Bck2Brwsr]] - this means less than 100 classes. The rest of the system is [[modular]] - look at the [[Bck2BrwsrJavadoc]]. It contains ''minimal'' emulation library, it contains [[Bck2Brwsr]] profile (the standard library people code against). When you want more - like access to an [[HTML]] page - you can use another library. When you want to use widgets (like [[Java]] FX ones) - add another library. If you don't need them, don't include such library and your framework is still going to be as slim as possible (currently ~200KB gzipped).
-

	=== Language or a [[Framework]]? ===		=== Language or a [[Framework]]? ===

JaroslavTulach: /* Slow JavaScript Interpreters and Doing Less Work */

JaroslavTulach — Thu, 21 Mar 2013 20:35:29 GMT

Slow JavaScript Interpreters and Doing Less Work

←Older revision		Revision as of 20:35, 21 March 2013
Line 8:		Line 8:
	* one does not need to write lexer and understand [[Java]] keywords		* one does not need to write lexer and understand [[Java]] keywords
	* one does not need to write parser to create a [[Java]] [[AST]]		* one does not need to write parser to create a [[Java]] [[AST]]
-	* one does not need to do attribution - e.g. resolve ~~the~~ fully qualified ~~name~~ of ~~each~~ symbol	+	* one does not need to do attribution - e.g. resolve fully qualified names of every symbol
	All of this has already been done by [[JavaC]] when generating the [[ByteCode]]. [[Bck2Brwsr]] can use such information, become more effective and at the end fit into the browser.		All of this has already been done by [[JavaC]] when generating the [[ByteCode]]. [[Bck2Brwsr]] can use such information, become more effective and at the end fit into the browser.

JaroslavTulach: /* Slow JavaScript Interpreters and Doing Less Work */

JaroslavTulach — Thu, 21 Mar 2013 20:34:59 GMT

Slow JavaScript Interpreters and Doing Less Work

←Older revision		Revision as of 20:34, 21 March 2013
Line 7:		Line 7:
	For example the [[Bck2Brwsr]] project does not deal with [[Java]] source, but with [[Java]] [[ByteCode]]:		For example the [[Bck2Brwsr]] project does not deal with [[Java]] source, but with [[Java]] [[ByteCode]]:
	* one does not need to write lexer and understand [[Java]] keywords		* one does not need to write lexer and understand [[Java]] keywords
-	* one does not need to write parser to ~~for~~ a [[Java]] [[AST]]	+	* one does not need to write parser to create a [[Java]] [[AST]]
	* one does not need to do attribution - e.g. resolve the fully qualified name of each symbol		* one does not need to do attribution - e.g. resolve the fully qualified name of each symbol
	All of this has already been done by [[JavaC]] when generating the [[ByteCode]]. [[Bck2Brwsr]] can use such information, become more effective and at the end fit into the browser.		All of this has already been done by [[JavaC]] when generating the [[ByteCode]]. [[Bck2Brwsr]] can use such information, become more effective and at the end fit into the browser.
-

	=== Gmail Web Toolkit ===		=== Gmail Web Toolkit ===