HTML5+svg[2]+css3+ecmascript5+domL2/L3

építsünk egy sokkal szebb webet

Script# (C# to JavaScript) tudnivalók

3 hozzászólás


A JavaScript programozás megfelelő C# kódból való fordítással és ezzel a megszokott fejlesztői környezet használhatóvá tételével, ez volt egy igazi szoftver zseni, Nikhil Kothari 2006-os kezdeményezése. Fontos, hogy itt nem a nyelv maga a döntő, hanem azok az eszközök, tool-ok, amelyekkel minőségileg jobbá lehet tenni a JavaScript fejlesztést.

2008 után nem sok minden történt ezen a téren, mert Kothari a Silverlight fejlesztéssel volt alapvetően elfoglalva. Az utóbbi hónapokban viszont lényeges változások történtek azzal, hogy a MIX’11-en Kothari alapos promóciós előadást tartott, majd azt követően folyamatba helyezte nyílt forráskódú projektként való továbbvitelét a GitHub-on keresztül. Maga is viszonylag gyorsan lépked tovább a Script# fejlesztésével. A MIX’11 idejére megjelentetett 0.7-es változat már 0.71 és 0.72 változatként fejlődött tovább.

Ebben nyilván az is közre játszik, hogy Kothari a Bing fejlesztés “mobil experiences” megoldásainak architekt-je lett, bejezve a korábbi Silverlight és RIA Services munkáit. Amennyiben sikerül a GitHub-os projekthez megfelelő társakat találnia, akkor hivatalosan is bejelentik a Script# nyílt forrású projektként való továbbvitelét. (Amennyiben ez nem sikerülne, akkor marad a Microsoft termék opció, ami sohasem volt szándék, mivel a JavaScript programozás megfelelő támogatása jóval túlmutat a vállalati alkalmazások fejlesztésén, amikre a Microsoft fejlesztői termékek – fizetősek révén – eredendően irányulnak, és ráadásul mára javarészt az open-source uralja az JavaScript-es eszközök területét).

Akárhogyan is, végre elérkezett az ideje annak, hogy a JavaScript fejlesztők megismerkedjenek a Script#-al. A verziószám (0.72) senkit se tévesszen meg. Az eddigi tapasztalatok szerint teljesen érett és jól működő szoftverről van szó, amit úgy a Microsoft használt akár egészen nagy projektekben, mind mások a nagy projektektől (pl. bizonyos FaceBook részek) a kisebbekig. Mi több már kiegészítő open-source projektek is megjelentek a Script#-hoz.

Az alábbiak a jelenlegi helyzetet tekintik át angol nyelvű kivonatok gyűjteménye formájában.

Nikhil Kothari: “on the Bing team as architect on the mobile experiences team (worked on Silverlight, RIA Services and ASP.NET before), Script# creator” http://www.nikhilk.net

Script#

Getting Started with Script# [April 28, 2011]

Hello World with Script# – a 101-style walkthrough on authoring and deploying scripts compiled from c#, while using the HTML DOM APIs, XMLHttpRequest, and jQuery.

At MIX11, I presented a session on Script# titled “Script#: Compiling C# to JavaScript” … and I did a follow up blog post highlighting the key points from the presentation.

This blog post covers the Hello World demo, which will show how you can get started with script#, and deploy scripts authored using this approach. It doesn’t go into more advanced topics, but hopefully it will also demonstrate a couple of key principles at play:

  1. Script# doesn’t introduce some new and odd abstractions. You’re still very much authoring script against the DOM and standard APIs, and existing knowledge of web development carries forward.
  2. The generated script is similar to script you might have authored directly, and can be distributed or deployed into a web application like any other script library, without a dependency on the compiler at runtime.

Script# enables you to leverage Visual Studio, C# syntax and existing familiar and robust set of .NET tools to scripting. In my MIX talk, I demonstrated some of this. In this post, you’ll see some basic benefits such as intellisense and compile errors.

Daryl

Posted on 4/28/2011 @ 8:50 PM

This is an interesting project. I’ve been watching it for a while.
But honestly, I just can’t imagine how anyone could invest any serious resources developing with Script#.

It’s written by one guy, when he finds the time. There’s no timetable for important features. There’s no roadmap to speak of, and no source code. If he gets hit by a bus or something (let’s hope not), your project is dead.

Hey, I understand this isn’t your day job. Is there any reason it can’t become a “real product”, ie, get some support for adding it to VS, or open-source it?

Nikhil Kothari

Posted on 4/28/2011 @ 9:07 PM

The plan has always been to open source it. And its already on the path to being set up that way… see the MIX11 announcement first.

That said lots of teams have used it successfully for some large apps. The two things that helped: the productivity benefits outweighed the issues, and second, and this has been most important for the large teams – they could walk away from the tool with their latest snapshot of compiled scripts (which closely resembles their original source code), if there came a day where they decided directly working on the script in fact worked better. In other words they weren’t betting the farm by picking up a development-time tool, rather than a dependency they need to carry around in their deployed product.

Nikhil Kothari

Posted on 4/29/2011 @ 9:40 AM

@PadovaBoy
I really don’t think the useful question is “why the project exists”

The real question IMO is why users use it (and there are many users building large and very real projects… also listed in my past blog posts). Only they can ultimately answer that particular question, since each team has unique requirements, and unique ways script# is providing value to the team… at the 10,000 ft level, these reasons converge into increased productivity and maintainability of code base. For many of the teams, this tool has been indispensable.

Of course, everyone’s mileage and experience differs, based on your needs, your opinions etc. You’re free to decide for your own situation. Not every tool is meant for everyone.

Erik Källén

Posted on 4/29/2011 @ 1:38 PM

And, @PadovaBoy, say you have 20k LOC of JavaScript with an object carrying data like this:

{
key1: “Some string”,
key2: 3,
value: “x”
}
and you want to transform it, and all 50+usages of it, to
{
key: {
first: “Some String”
second: 3
}
value: “x”
}

With C#, it is literally a 5 minute job to make the changes in all code paths, while in JavaScript it can easily take half a day to achieve a reasonable confidence that you have covered most of them. And no, unit testing is not the solution to this, because it would most likely show up as an integration bug, and integration testing is complex enough without having to test every possible code path.

rekna

Posted on 5/1/2011 @ 10:48 AM

If anyone needs a good reason why scriptsharp might exist : recently jqgrid ( a very good grid plugin for jquery ) changed some methods from old syntax to new syntax:
an example:
old method : jQuery(”#grid_id”).jqGrid(‘getPostData’)
new method : jQuery(”#grid_id”).jqGrid(‘getGridParam’,’postData’)

if I had written everything with scriptsharp in my project, I could have changed this quite easily… just remove the old method and compile, and all places where the code would be broken just show up in the compiler output as errors…
instead, now I have to sift through each and every javascript file in my project, looking for places where I still use the old syntax… and change it, with the chance to introduce new typos…

phil

Posted on 5/2/2011 @ 1:21 AM

@rekna
I’d rather write my own grid control using Script# than using jqgrid(Im really considering this).😛
I have really bad experience with jqgrid, awful setup, configuration, lots of overhead, and then u dont know why something is not working….

Daryl

Posted on 5/2/2011 @ 7:41 AM

Script# is going in the right direction, but the one-person development model is hopeless. No offense to the NK: you’ve done a yeoman’s job but after 6 years there are still huge gaps, and HTML itself is changing every few months. One person working really really hard will never keep up.

Nikhil Kothari

Posted on 5/2/2011 @ 8:32 AM

@phil
Would love to see components built in script# rather than just a wrapper. Eventually, I hope there will be ability to do static linking, it will help to have code rather than just stubs, that can be static linked.

@Daryl
Hence the reason for open sourcing. Hopefully the new community around the web is one where everything doesn’t have to be baked in into VS, i.e. its a bit different from the typical .net/windows enterprise customer set. If open sourcing also doesn’t motivate the right community, then yes, you’re right, the only way to move it forward would be for script# to be a product, not a project, a topic on which I am not going to comment on over here. I’m going to give it a chance and see where it goes.

Michael Murray

Posted on 5/2/2011 @ 4:47 PM

@phil
Script# controls are exactly what the company I currently work for are focusing on – the only way to go!

#1 for me is that Script# helps keep all our JavaScript really organised – refactoring is a dream. The shear number of collaborators on some projects also mean that it is difficult to get everyone to conform to the same standards, but Script# helps us do this too…

Keeping people away from hand coding javascript has also a triggered better architecture in that we are grouping scripts that used to be scattered around, into plugins and libraries.

We are avoiding the runtime script synchronisation issues that we used to have with UpdatePanels and that kind of thing, by replacing that kind of functionality with controls that have a single load of javascript and markup then use Ajax calls returning Json for everything else (a little like EXTJS approach). I am also working on a project using MVC3 to unify the whole lot – one call for your markup and script view and then all other calls back to the same controller for JsonResults – awesome and something I would have bothered looking at if it wasn’t for the change in mindset that using Script# has triggered.

Keep up the good work Nikhil! I don’t care whether it goes open source or not, so long as you can keep it alive!

Script# at MIX11 [April 19, 2011]

Followup to my talk at MIX11 – Script#: Compiling C# to JavaScript, along with links to sample code and slides.

At MIX11 last week, I presented the Script#: Compiling C# to JavaScript using Visual Studio.

As full-fledged script-based development becomes widespread with the HTML5 wave, a couple set of interesting questions emerge – what are the development tools you and your team uses to productively author and manage a code base? Shouldn’t you write code in a model that is optimized for development and productivity and let a compiler do its magic and produce code that is optimized for deployment and runtime?

Script# allows you to write your code in C# and compile it down to deployable JavaScript, it also unlocks the power of C#, Visual Studio and existing .NET tools for scripting scenarios.

Development with Script#

In my demo, I highlighted some of these tooling experiences (things like refactoring, static analysis, unit testing and IDE tools). I also demo’d how you can get started with the traditional “hello world” scenario and how you can continue to use frameworks like jQuery, as well as write your own jQuery plugins using Script#.

I have published the code and slides. I will be blogging a more detailed post on each demo over the course of the next few blog posts, so stay tuned.

Script# has been used successfully to develop various applications. These include Bing maps, Bing mobile, and the Messenger/Web IM integration within Hotmail.

Bing Maps Bing Mobile Web IM in Hotmail

If you’re building an application using Script#, I’d love to hear about it, and reference it in an upcoming revamp of the project’s site.

You can now download the latest release of Script#, v0.7 off the Script# project site. It comes with the ability to consume generic types, a new script loader, and improved asp.net mvc integration, as well as nuget support to get you started on that. As always I look forward to hearing from you on your use of Script#.

Amit

Posted on 4/20/2011 @ 8:27 AM

Hi Nikhil,
Script# looks really great. But do we have support for calling any jquery plugins. E.g. jquery.imgareaselect.js. How can we write a wrapper for that. Is there any tool which can compile a js plugin to create a c# wrapper.

Nikhil Kothari

Posted on 4/20/2011 @ 12:30 PM

@Amit
You can use jQuery plugins with script# – for example, out-of-the-box there is support for the jQuery BBQ and templating plugins. There is nothing automagic to build the wrapper, but it isn’t rocket science either.
I’d suggest checking out the sources on http://github.com/nikhilk/scriptsharp to see the code for those plugins as examples… and furthermore if you do build any, perhaps share them as well. Hopefully that sets up a pattern of the community helping itself, and overall will ensure everyone doesn’t have to build a wrapper from scratch every time for every plugin.

phil

Posted on 4/22/2011 @ 12:37 AM

Hi
When will there be language support for c#4? All the sweet syntax sugar that makes C# outstanding, is not yet supported. Writing code in Scriptsharp looks more like writing .net 1.1 Code to me(Now with generics its a little more pleasant ;P). Im really anticipating you finally releasing the source code, and so maybe advancement goes faster in the future.
What do you think about SharpKit(which is open source and free now), which does the same and has full C#4 support? Their source on google code doesnt seem to be complete either and their .cs files are bloated and roughly about 2000 lines long each with lots of commented out methods.
I also really wonder how the ms teams went with script# for building things like maps and bing mobile and stuff. How did they organize the code and most importantly what did they say about the missing “var” statement?😀
Also what about debugging? Wouldnt it be possible to actually debug against the .net dll, maybe using proxy types that do js calls against the browser? This would also greatly enhance prouctivity(I hate to debug js in IE).

Nikhil Kothari

Posted on 4/22/2011 @ 1:39 AM

@phil
I too would like to see more support for language constructs from newer c# versions, and am evaluating couple of different approaches in terms of how the script# compiler is built (the current approach is to parse c# source code). Both of those approaches require some underlying foundation work that isn’t ready yet. As those become ready, and I pick one, I will start opening up the source code. Opening up the source code to compiler before, and then doing a major shift in approach isn’t going to be helpful.
While that is happening, the current focus is to first optimize the generated script further, as that results in better runtime characteristics (size, perf etc.) and in some ways is more interesting to teams using script#. As for teams using script# without c# 4 support, the productivity wins with using the overall approach far outweigh the pain from absence of specific language constructs.
Debugging – yes, theoretically its possible to build what you’re referring to. It would be a nice subproject of its own, and perhaps something the community can get started.🙂

phil

Posted on 4/30/2011 @ 6:15 AM

Hi
I see your priorities. This seems to stand on much better fundamentals than other similar projects imo, and its an important project, just about to really start off.
I wonder what compiler approaches you are thinking about, i would think of the 3 possibilities of either directly parsing source code, parsing the il(like in jsc), or using some external ast provider or whatever(like “Compiler as a service” in the coming .net rewrite of the c# compiler)?
After I just started with Sharpkit, seeing it doesnt feel like its exactly brilliant, I might have a look at script# again, maybe I get it to work this time.😀

GWT vs. ScriptSharp Pros and Cons [July 21, 2010]

We have determined it’s too difficult for us to maintain the bulk of javascript we need to write full-scale “single page” javascript “applications”. Relying on programming conventions still has left us wanting… especially in the area of refactoring. For developers new to these projects, they find it very difficult to change anything because they have no faith they know who else is truly relying on the component (things easy to do with “find all references…” and code access levels in strongly typed languages).

We’ve been playing with GWT, but one of our developers wants to use Script#. We are already a Microsoft-based shop, and do all of our server-side work in C#.

I don’t consider java to be a show-stopper for GWT, as it’s extremely similar to C#.

My initial concerns with Script# primarily revolve around support and documentation.

On one hand we have Google, on the other… “Some Dude”. Script# is also closed-source… so if the developer stops working on it, are we S.O.L.? I also feel GWT has more documentation and community support.

Anyways, have you worked with both? Thoughts? Pros/Cons?

(To head this off at the pass: the question is not whether to go with a compiler or not… the question is which compiler)

Similar, but different, questions:

http://stackoverflow.com/questions/788933/what-advantages-can-scriptsharp-bring-to-my-tool-kit
http://stackoverflow.com/questions/1579192/should-i-use-scriptsharp

answered Jul 21 ’10 at 21:19 chris.r

I have been using GWT for several years. I have never heard of Script# so I will just tell you why you should stick with the Google solution.

  1. Active development. Google has a paid team of engineers both actively fixing defects and working on new functionality. I am currently in discussions with some other developers on how to implement a new feature for GWT.
  2. Large institution. Google has invested this project and used it to implement large-scale solutions. They’re eating their own dogfood, in other words. They have a vested interest in not letting it stagnate or become obsolete.
  3. Community. There are plenty of people working on add-ins/third-party/etc libraries and APIs to use alongside the vanilla distribution. These same people are also testing, filing, and fixing defects.
  4. Compatibility. GWT can work with anything that the browser can do. There are also plugins for jQuery and other major JavaScript libraries that just make it plain easier to manage the complexity of your project when working with JavaScript.
  5. Open. You touched on this yourself.

Notice how I didn’t touch on issues of language choice. I don’t think that’s really relevant at the level you describe. Remember that the first time you run into a limitation or road block with Script# you’ll become quickly stuck due to the things that both you and I described.

Of course, I recommend GWT just because of the track record.

answered Jul 27 ’10 at 20:48 chum of chance

I use Script# and previously used GWT. They’re really two different things. GWT is meant to provide a client and server solution, with RPCs and everything else. It is definitely more mature and you can get going on complex applications faster. Simply put, there’s a lot more code and examples in the wild.

However, I think if you’re developers are both server side and client side, using two different languages and two different platforms can be very, very burdensome. This is why I moved to Script#. Everything I do is in C# and in Visual Studio, it allows me to be a lot more productive. If you’re not taking advantage of GWT’s backend capabilities, it is really overkill.

I like to think of Script# as Javascript written in C# 2.0 spec (which it is). It is completely clientside and any sort of mapping has to be done by hand (though automapping can be used extensively). It is very complete in its support of Javascript and jQuery, in fact it is so complete this surprised me at first. It seemed like it was doing less than it was.

angryundead’s points are valid, especially in regard to community and openness. While this has been a bit of a thorn in my side, I really, really like using Script#. I don’t have to change IDEs, I don’t have to look up how to do things in Java, etc. jQuery has a huge plugin library and it is very, very easy to hook these into Script#. You simply throw a few objects to represent the properties, annotate them as “imported” and have it returning null. In your code you cast an object as the plugin and your output is exactly as it would appear in Javascript. Script# doesn’t care / know how the plugin works.

Don’t let Script# lack of community support fool you. While it is a problem, the product is very mature and feature rich. If your developers are using C#/VS why make them use a separate program for the clientside? I found that was a huge productivity hit.

As an aside, I’ve become a lot better at Javascript since using C#. A lot of the problems with Javascript are the lack of language features that you don’t really need but on large projects it is the only way to make it manageable.

answered Mar 26 [2011] at 6:21 DuckMaestro

Unless you’re building an full-on in-browser application, my preference is Script# because it sticks to what it does best — compiling C# to JavaScript — rather than trying to be a comprehensive client/server toolkit. Web paradigms change quickly, and investing the project in GWT can leave you with overhead or technology commitments you wish you didn’t have. But I would add that it really depends on the type of web application or web experience that you are trying to build.

Personally, I’m already intimately familiar with jQuery, WCF, and am beginning to use new HTML5 capabilities directly. Script# is the perfect missing piece because I can continue to use jQuery and WCF very easily, and I don’t need to go through the hassle of switching to or integrating with the paradigms or requirements of GWT.

Also, on the UI building side of things, you might consider Sharp UI that I recently open-sourced, which makes it easier to build reusable controls in a jQuery+Script# setting.

Sharp-UI / README [May 9, 2011]

Sharp UI is a control building framework for Script# (https://github.com/NikhilK/scriptsharp) and jQuery.

The goal of the project is to enable basic reusability and encapsulation

(a la the "user control" paradigm in WPF or ASP.NET) when building 

client-side HTML user interface controls in Script# with jQuery.

For live sample application see here: http://files.duck17.net/AnimationEditor/Default.htm.

Features (or beneficial consequences) include:

 * Ability to construct reusable controls using HTML fragments and C# (Script#) codebehind.

 * Ability to separate logic from layout by using .html(.cs) file pairs and partial classes.

 * Support for locally-scoped CSS through CSS rewriting.

 * Support for locally-identified elements through ID rewriting.

 * Automatic binding of member fields to named elements.

 * Support for nested instantiations -- controls can declare instances of other controls.

 * Support for container controls and preservation of nested/inner content.

 * AddedToDocument & RemovedFromDocument events.

 * Replication of standard "mouse capture" behavior.

Detailed documentation is pending. In the mean time please inspect the example

code, or contact me on Twitter at @duckmaestro.

Script# Programming in the Large [Oct 29, 2008]

Some large-scale Ajax apps and frameworks – the Live Framework and Office 14, both announced at PDC – built using Script#…

Yesterday’s PDC keynote featured a number of interesting products and technologies, such as Office 14 and Live Services, that today involve fairly large-scale (code size, team size and project length) Ajax development. The demos were just amazing – Kudos to the product teams!

Behind the scenes, on the engineering front, Script# provided the toolset and script authoring model. I’ve been working with both teams for quite a while now, and am really excited to be able to finally share these particular uses now that they are public (since to be honest, I was myself quite pleasantly surprised to see the model of compiling down to script scale up in this manner).

Live Mesh features an online desktop experience within the browser to enable remotely accessing files from any browser. The Live Framework exposes the underlying platform to .NET applications and script applications alike. The script framework portion of the SDK, like the UI, is based on Script#. The documentation for this framework on msdn was built from doc-comments in the originating c# code, which double up to enable script intellisense in Visual Studio.

Next in the keynote was a quick peek at what is to come in a web-ified Office 14. Some of the highlights included Excel, OneNote, and the Ribbon interface. These apps bring document sharing and collaboration to a whole new level. What is really cool is the live editing and continual sync’ing with the actual good-old, full-fidelity Office document file on the server or with another concurrent editing session in the full-blown desktop Office suite. These apps build on top of the ASP.NET Ajax framework, and were for the most part coded in c# and converted to javascript using script#.

The devs clearly recognized the value from using standard .NET tools and C# for engineering the thousands of lines of script and Ajax code that power these great consumer and developer experiences.

From the latest Twitter messages:

 

– “it’s not about source language first and foremost. It’s about tools support associated with language + static typing”

– 22 May: “Released v0.7.2.0 of script# with #jQuery 1.6.1 + #knockout support & bug fixes http://bit.ly/aZTm2r … also on github http://bit.ly/hJrbv3#Nuget package for @scriptsharp – scriptlets, script loader integration with asp.net mvc simplified … http://bit.ly/lMTuGo

– 17 May: “still in the process of rolling out”

– 2 May: “Posted Script# 0.7.1 with various github reported issues fixed along with couple new features (nullables, observables). http://bit.ly/aZTm2r

– 29 Apr: “Getting back into blogging (slowly) … posted a script# 101 style tutorial covering demo #1 of my #mix11 session – http://bit.ly/m2P6Kb

– 29 Apr … when S# will become an “officially supported” product instead of a side project? It’s hard to sell to my mana’s. Answer: “Script# will be an oss project. See http://bit.ly/hJrbv3 (with more to come over time). Hopefully that will grow a better community.”

– 25 Apr: “Just checked in the sources for ScriptSharp.Web.dll (script# and asp.net mvc integration) into github project at http://bit.ly/hJrbv3

– Will MS contribute to script# once it’s on github? Answer: “If I can recruit some volunteers… hoping to sign up couple of devs I know.”

22 May

nikhilk Nikhil Kothari

#Nuget package for @scriptsharp – scriptlets, script loader integration with asp.net mvc simplified … http://bit.ly/lMTuGo

22 May

scriptsharp Script#

by nikhilk

Released v0.7.2.0 of script# with #jQuery 1.6.1 + #knockout support & bug fixes http://bit.ly/aZTm2r … also on github http://bit.ly/hJrbv3

12 May

TomMathias Tom Mathias

@nikhilk How does JSLint fit into ScriptSharp?

12 May

in reply to @TomMathias ↑

@nikhilk Nikhil Kothari

@TomMathias you can run script tools on generated script, but even better, you can now run tools like FxCop and StyleCop on the original c#.

12 May

joeriks jonas.eriksson Ⓤ

What do people say about #ScriptSharp? Same approach as #Pyjamas, isnt it? But Pyjamas doesnt seem to have gotten much traction?

9 May

in reply to @joeriks ↑

@nikhilk Nikhil Kothari

@joeriks my thought: it’s not about source language first and foremost. It’s about tools support associated with language + static typing.

2 May

scriptsharp Script#

by nikhilk

Posted Script# 0.7.1 with various github reported issues fixed along with couple new features (nullables, observables). http://bit.ly/aZTm2r

29 Apr

nikhilk Nikhil Kothari

Getting back into blogging (slowly) … posted a script# 101 style tutorial covering demo #1 of my #mix11 session – http://bit.ly/m2P6Kb

29 Apr

chadbr chad br

@nikhilk I just want to know when S# will become an “officially supported” product instead of a side project? It’s hard to sell to my mana’s

29 Apr

in reply to @chadbr ↑

@nikhilk Nikhil Kothari

@chadbr script# will be an oss project. See http://bit.ly/hJrbv3 (with more to come over time). Hopefully that will grow a better community.

25 Apr

scriptsharp Script#

by nikhilk

Just checked in the sources for ScriptSharp.Web.dll (script# and asp.net mvc integration) into github project at http://bit.ly/hJrbv3

15 Apr

woodjoe Joe Wood

@nikhilk cool. You also said you had a new job, but didn’t say where…

15 Apr

in reply to @woodjoe ↑

@nikhilk Nikhil Kothari

@woodjoe I’m on the bing team as architect on the mobile experiences team …

14 Apr

woodjoe Joe Wood

@nikhilk Enjoyed your mix talk. Will MS contribute to script# once it’s on github?

14 Apr

in reply to @woodjoe ↑

@nikhilk Nikhil Kothari

@woodjoe thanks. If I can recruit some volunteers… hoping to sign up couple of devs I know.

Written by Nacsa Sándor

2011. május 29. vasárnap - 13:42

Kategória: JavaScript programozás

Tagged with ,

3 hozzászólás

Subscribe to comments with RSS.

  1. […] helyzetet tekintik át angol nyelvű kivonatok gyűjteménye formájában. LÁSD ITT. Elküldve 2011. 05. 29. 13:46 by Nacsa Sándor Megtekintve: 0 alkalommal […]

  2. […] IE9) ez gyakorlatilag nem lassabb, mintha nem HTML5-ben fejlesztenénk. A négy játékból kettőt Script#-ban készítettek, hogy azt is […]

  3. […] helyzetet tekintik át angol nyelvű kivonatok gyűjteménye formájában. LÁSD ITT. Elküldve 2011. 05. 29. 13:46 by Nacsa Sándor Lementve: Script# Megtekintve: 1 083 alkalommal […]


Vélemény, hozzászólás?

Adatok megadása vagy bejelentkezés valamelyik ikonnal:

WordPress.com Logo

Hozzászólhat a WordPress.com felhasználói fiók használatával. Kilépés / Módosítás )

Twitter kép

Hozzászólhat a Twitter felhasználói fiók használatával. Kilépés / Módosítás )

Facebook kép

Hozzászólhat a Facebook felhasználói fiók használatával. Kilépés / Módosítás )

Google+ kép

Hozzászólhat a Google+ felhasználói fiók használatával. Kilépés / Módosítás )

Kapcsolódás: %s

%d blogger ezt kedveli: