Gelmiş geçmiş en büyük porno sitemiz olan 2pe de her zaman en kaliteli pornoları sunmayı hedefledik. Diğer video sitemiz olan vuam da ise hd porno ağırlıklı çalışmalara başladık.

  1. #111
    Sencha Premium Member
    Join Date
    Oct 2009
    Location
    Germany
    Posts
    296
    Vote Rating
    62
    Ekambos is a jewel in the rough Ekambos is a jewel in the rough Ekambos is a jewel in the rough Ekambos is a jewel in the rough

      -4  

    Default


    Quote Originally Posted by mitchellsimoens View Post
    I think this thread got super hijacked into a personal preference battle.
    Nope. It s about real software engineering and the fact that JS is/was not designed for that.

  2. #112
    Sencha Premium Member
    Join Date
    Oct 2012
    Location
    Brisbane, QLD, Australia
    Posts
    45
    Vote Rating
    3
    ampro is on a distinguished road

      0  

    Default .

    .


    Nope. It s about real software engineering and the fact that JS is/was not designed for that.
    I agree. This is the real topic. Apologies for my IDE diversion.

    And looking to the future ...

    Once you get more type metadata into your code you can compile it into more efficiently code. So we can see where MS might be heading here. To out do Google's V8 engine, MS compiler writers need type information. So I think we'd see a future where typescript is an optional language in the browser (and runs faster if you use it). Since Javascript is a subset of Typescript, they can just use the same compiler but with performance improvements if you give it type information. Since it's all done in one compiler you can also happily mix existing JS frameworks with newer and faster typescript code. Once one browser implements this performance booster (like IE) I suspect we may see others follow (ECMA standards permitting). If I'm right then this may be very significant for Sencha.

    Note: In world that has a mixture of browsers that may or may not be typescript capable, you add server code that detect this and loads either the typescript file or the javascript file (compiled from your typescript file). A plugin could do this transparently so you'd just deploy a .js file (that may contain typescript with a header for the plugin to know it's typescript).

  3. #113
    Sencha - Senior Forum Manager mitchellsimoens's Avatar
    Join Date
    Mar 2007
    Location
    Gainesville, FL
    Posts
    36,519
    Vote Rating
    814
    mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute mitchellsimoens has a reputation beyond repute

      0  

    Default


    Quote Originally Posted by Ekambos View Post
    Nope. It s about real software engineering and the fact that JS is/was not designed for that.
    Just because something was not designed for a purpose does not mean that it cannot be used for that purpose. I personally have had great success with JavaScript for "real" enterprise/government level development so I personally like JavaScript. Every language will have pros and cons, you have to learn to work around the cons and utilize the pros.

    Now there are always going to be critics of everything and I respect your opinion about JavaScript.
    Mitchell Simoens @SenchaMitch
    Sencha Inc, Senior Forum Manager
    ________________
    Check out my GitHub, lots of nice things for Ext JS 4 and Sencha Touch 2
    https://github.com/mitchellsimoens

    Think my support is good? Get more personalized support via a support subscription. https://www.sencha.com/store/

    Need more help with your app? Hire Sencha Services services@sencha.com

    Want to learn Sencha Touch 2? Check out Sencha Touch in Action that is in print!

    When posting code, please use BBCode's CODE tags.

  4. #114
    Ext JS Premium Member
    Join Date
    Aug 2007
    Location
    Antwerp, Belgium
    Posts
    555
    Vote Rating
    27
    joeri has a spectacular aura about joeri has a spectacular aura about joeri has a spectacular aura about

      0  

    Default


    Quote Originally Posted by ampro View Post
    Once you get more type metadata into your code you can compile it into more efficiently code.
    That is an assumption for which I do not see much evidence. AS3 is javascript + static typing, and it is outperformed by V8 and Tracemonkey. Modern JIT engines observe code at run-time to infer types by looking at what the actual data is that flows through the code. They generate executable code to match the actual values of variables. This means that even code that is typed must be analysed at run-time to gain additional information about the data in order to JIT-compile it efficiently. So, for a JIT engine, as far as I understand it, there is no huge difference between statically typed code and untyped code. It is a matter of convenience in implementation.

    What benchmarks there are do not seem to support the notion that JavaScript is slow. The alioth shootout has V8 outperforming or matching the performance of pretty much any dynamic language except for Java (and Java's JIT has been heavily optimized, so no surprise there). It matches the performance of C# Mono, and it outperforms Dart. Now, that benchmark may be flawed, and type information may offer better performance after all, but I do not consider that fact a given.

    Finally, I would argue that what we need is not faster JavaScript but faster DOM. Javascript is so fast that I never, ever, have to optimize my javascript code's actual algorithms. I do have to optimize my DOM interaction, but TypeScript would suffer from this equally. Admittedly there are areas where YMMV, like game development, but I would need to see actual proof that TypeScript can offer better performance in those areas before concluding it does.

    Update: just to play devil's advocate to my own post, Adobe claims that with the static typing and compilation in AS3 they can outperform any JIT implementation for JavaScript. So, again, it's not clear but we can only look at real-world performance as a guide. http://blogs.adobe.com/avikchaudhuri...hy-competitor/

  5. #115
    Sencha Premium Member
    Join Date
    Oct 2009
    Location
    Germany
    Posts
    296
    Vote Rating
    62
    Ekambos is a jewel in the rough Ekambos is a jewel in the rough Ekambos is a jewel in the rough Ekambos is a jewel in the rough

      0  

    Default


    I think what he ment is that compilers can generate a more efficient JavaScript because of a static type system.
    Look at the closure compiler which generates probably the most efficient JS out there. You wont get that level of efficiency without a static type system.

    It s true that JS engine has gotten better and better(V8).
    But the fastest code is the one that does not run right ?

  6. #116
    Sencha Premium Member
    Join Date
    Feb 2012
    Location
    Raleigh, NC
    Posts
    417
    Vote Rating
    134
    brian428 is a name known to all brian428 is a name known to all brian428 is a name known to all brian428 is a name known to all brian428 is a name known to all brian428 is a name known to all

      0  

    Default


    Quote Originally Posted by joeri View Post
    That is an assumption for which I do not see much evidence. AS3 is javascript + static typing, and it is outperformed by V8 and Tracemonkey.
    First, the bulk of the case being made here has nothing to do with the speed of the executable JavaScript. If typing ends up making the JS faster, great. But the vast majority of the advantage comes in developer-time activities involving IDEs and tooling. At least this is what I care about.

    Comparing browser JS speed to AS3 is really a straw man. Adobe is one company with many products, so the Flash runtime only gets a small portion of their resources. Compare that with the hundreds of millions of dollars that Mozilla, Google, and Microsoft have poured into maximizing the speed of JS.

    So even if execution speed were the issue (which it isn't), it's not really a shock to find that JS may still be faster. The JS engines have had vastly more attention and optimization.

  7. #117
    Sencha User
    Join Date
    Dec 2007
    Posts
    168
    Vote Rating
    4
    SeaSharp2 is on a distinguished road

      0  

    Default


    Quote Originally Posted by joeri View Post
    That is an assumption for which I do not see much evidence.
    You need to watch the video interview between Google's designer of both V8 + Dart and Anders of Microsoft. When pressed to explain the advantages of Dart over TypeScript the Google man mentions the extra control his system has over loading and managing the modules of a very large web application. Your argument that single threaded performance of small JavaScript execution paths is more than fast enough, misses the point. If the designer of V8 and Dart says there is a problem to be solved, we should bow to his knowledge on this matter as he has intimate knowledge of the challenges faced when implementing speculative stealth compilation of JavaScript on the fly. That it is possible at all is a minor miracle, your faith in the scaleability of this technique might be a miracle too far.

    The most interesting contribution to this thread is the earlier speculation that extra meta data placed in the JS output of a TypeScript compiler could give load and compile hints to a future MS javascript engine and so close the gap between TypeScript and Dart.

    Anyhow all this focus on strong typing and runtime performance missed the main advantage of TypeScript right now. History tells us that the human brain struggles to maintain a working familiarity with more than a few thousand lines of block structured code as is typically created by JavaScript programmers.

    OO languages are an answer to this problem, encapsulation through classes and public/private access help programmers keep control as applications scale to 100,000 lines. This is the primary benefit of TypeScript.

    Denial of this means you are claiming that software engineers of the last 30 years were engaged in a mass group delusion.

  8. #118
    Ext JS Premium Member
    Join Date
    Aug 2007
    Location
    Antwerp, Belgium
    Posts
    555
    Vote Rating
    27
    joeri has a spectacular aura about joeri has a spectacular aura about joeri has a spectacular aura about

      1  

    Default


    Quote Originally Posted by SeaSharp2 View Post
    Denial of this means you are claiming that software engineers of the last 30 years were engaged in a mass group delusion.
    Wow, wow, please don't put words in my mouth.

    I do not deny that adding modules and classical OO syntax at the language level would provide many benefits. If you look back in the thread I pointed out myself that I believe JavaScript must go in this direction. However, I don't think TypeScript is the solution. Not because it is badly designed, but because it is not JavaScript and never will be. I want these improvements to roll into the standard language. Given that google also has a few horses in this race, it is pretty much guaranteed that the only language that will be available in all browsers will be JavaScript. TypeScript will always be a cross-compiler, and I don't like cross-compilers for the complexity that they introduce.

    What I deny is that TypeScript, or solutions like it, solves that large a proportion of the engineering challenge as people in this thread claim. It is not a silver bullet, because there is no silver bullet. This will not solve run-time performance issues, because those are all DOM-based. This will not solve people's struggling to learn API's and functional domains. This will not solve issues with cross-browser layout. This will not solve browser-specific bugs. Finally, it will do very little to solve the biggest challenge of all in working with large teams and large codebases: communication between team members.

    Extraordinary claims require extraordinary evidence. If people claim cross-compilers are a silver bullet for productivity, I say: prove it, show me the numbers. Until then I'm sticking with JavaScript.

    And now I've said all there is to say on this topic. A fine day to you all.

  9. #119
    Sencha User
    Join Date
    Dec 2007
    Posts
    168
    Vote Rating
    4
    SeaSharp2 is on a distinguished road

      0  

    Default


    Quote Originally Posted by joeri View Post
    Wow, wow, please don't put words in my mouth.
    The first rule of combat in any feisty internet debate

    Quote Originally Posted by joeri View Post
    I do not deny that adding modules and classical OO syntax at the language level would provide many benefits. If you look back in the thread I pointed out myself that I believe JavaScript must go in this direction. However, I don't think TypeScript is the solution. Not because it is badly designed, but because it is not JavaScript and never will be.
    We are not actually far apart except for a confusion as to what TypeScript is. TypeScript could be a far more interesting language if Microsoft took the CoffeeScript approach and viewed JavaScript is nothing more than a target runtime platform and innovated as far as possible. Instead Microsoft has designed TypeScript with a self imposed limitation that it must conform to the best available specification of nextGen JavaScript as defined by the non Microsoft custodians of the JavaScript language. They have also strived to achieve cut & paste source compatibility between JavaScript to TypeScript.

    In all probability there is little chance of binary support for a future OO JavaScript version arriving embedded within browsers this side of 2020. After 5 years the JS committee could not agree on a final spec of nextGen JavaScript and there is even less chance of a synchronized mass rollout of runtime browser support for a new JavaScript version.

    TypeScript is the most pragmatic escape route out of the current malaise of poor JavaScript application scalability today.

  10. #120
    Sencha User 2gua's Avatar
    Join Date
    Feb 2013
    Posts
    1
    Vote Rating
    0
    2gua is on a distinguished road

      0  

    Default


    Native JavaScript is enough.
    Scala & HTML5 & Ext fan