I would like to implement client-side hyphenation via JavaScript on some large texts on my site. (I know about CSS3 hyphenation and will use it instead when available, but it's usually not available.)
I have been using Hyphenator.js, and it works well but is very large (my optimized, compiled build with just English comes out to 106 KB) and pretty slow. It's large and slow enough that I'm considering dropping hyphenation altogether. It's just a luxury anyway.
But recently I came across what seems to be an alternative: Hypher. What baffles me is how Hypher can me so much smaller and do the same thing. I'm wondering if anybody can explain this.
Does Hypher work just as well? Is there any reason to use Hyphenator.js instead? Hypher's readme has a link to Hyphenator.js at the bottom of the page, but none of the text explains the connection between these projects.
Does anybody have an opinion about the most efficient client-side hyphenation?
I had a look at hyphenation in JavaScript and found the following four libraries:
hy-phen: Is a pure JavaScript library developed by Yevhen Tiurin since 2016 using the MIT license. You are offered a JavaScript function that you can call to hyphenate strings. You only need to include the main JavaScript file and the desired language file to use it.
Hypher: Is a pure JavaScript library developed by Bram Stein since 2011 using the "Three Clause BSD" license. You are offered two JavaScript methods that you can call to hyphenate strings. It can only be installed using Node.js or jQuery.
Hyphenator.js: Is a JavaScript/HTML implementation developed by Mathias Nater since 2008 using the MIT license. The project is discontinued since 2018. It is not so simple to include into your project - you need to use the Merge&Pack tool first to create a JavaScript file that you can then include. It automatically scans the HTML page and adds hyphenation to selected HTML elements. There is no JavaScript function that you can call to manually hyphenate strings.
Hyphenopoly.js: Is the follow-up project of Hyphenator.js and developed since 2016 by Mathias Nater using the MIT license. It dropped some features of Hyphenator.js and is a bit simpler to use. Nevertheless it works the same way meaning there is no JavaScript function that you can call to manually hyphenate strings.
All four libraries are using the hyphenation algorithm developed by Franklin M. Liang that uses matching patterns to find hyphenation points in words. This algorithm does not provide 100% correct hyphenations as stated by Liang in his thesis:
These patterns find 89% of the hyphens in a pocket dictionary word list, with essentially no error.
The primary reason Hypher's so small, comparatively, is that it relies on an externally-loaded jQuery for page integration. Hyphenator.js is completely standalone and thus has to include way more boilerplate for manipulating HTML across browsers. (They even re-implement some jQuery functionality.)
To be fair, Hyphenator.js is a relatively old project that hasn't been completely rewritten along the way to take advantage of substantial browser improvements. (Note that they proudly support Firefox 3.0.) And, more charitably, Hyphenator.js has many more finely-grained settings.
If you're already using jQuery, and don't use Hyphenator.js's advanced API, switching to Hypher may be a worthwhile improvement.
Related
We all know the great benefits that js libraries such as jquery and mootools etc. have contributed to web browsers and web development. These libraries are now included in a lot if not most of all websites.
So, I was wondering why none of the current javascript engines just include these functionalities inside the javascript engine itself. No doubt this has even more benefits such as performance, no need for external loading, standardisation (and its own benefits), etc.
I realize that this would probably only benefit web browsers and alike, though there must be also many uses beyond just web browsers, but for the sake of argument, one could just add such engine built in functionalities in an optional engine / ECMASCript -and I am guessing the word here- component (with emphasis on optional), that could then be enabled or added only in the engines inside web browsers.
Does anyone know this or has more info on this all?
My second questions is: If we, the community, would decide this to be a great progress for the future, where can we propose/ask such a thing and what else can we do to make this happen?
(Some of you must realize the trouble that some feature cost to be included in some projects, such as the years to decade old feature requests voted on by zillion users and never got through because of ...well..let's not be ungrateful to developers and leave these dots for your own imagination. So I'd rather have that the community focus this wish on 1 place only nad maybe the answer to this second question is the start of it?)
ECMAScript only intends to standardize the minimum amount of language and support library necessary to build these higher level libraries you're describing. Also, things like jQuery work on the Document Object Model provided by the browser code, which isn't even part of the ECMAScript standard -- ECMAScript just knows about DOM nodes in the general category of "foreign objects". The SpiderMonkey engine implements just the JavaScript language and its small standard library, which is then embedded into the larger Firefox browser environment.
So, to answer the question more directly: is it possible to give the JavaScript engine intimate knowledge (and perhaps an implementation) of a user-level library like jQuery? Yes, although you'd be breaking a lot of componentization in the browser, as you mention. Will anybody actually do it? Most likely not, because JavaScript engines just implement the core of what's necessary to build higher level libraries, like jQuery. Everybody is happy with them living outside of the JS engine, and a nice property of JavaScript is that you can just load the library in as you need it -- the source is freely available.
In fact, as a further note, JS engines are doing more and more to push ECMAScript standard library code out of C++-implementation land and into something called "self-hosted builtins", which enables functions like Array.indexOf to be implemented in JavaScript itself (i.e., with a for loop and comparisons). This exposes more JavaScript code to the natural process of optimizing JIT compilers, instead of having to deal specially with calls into native C++ implementation code.
I realize a JavaScript library like jQuery that is specific to the HTML / DOM wouldn't work nor make sense in a Flash ActionScript application. But what about other JavaScript libraries? I was reading that ActionScript is a superset of JavaScript / ECMAScript which is what got me wondering.
If it wouldn't use JavaScript libraries "out of the box" could a JavaScript library be adapted relatively easily? Also, does ActionScript support XMLHttpRequest or have a rough equivalent?
The syntax is similar, so you may be able to compile some code snippets. JavaScript looks more like the old Actionscript 2 though.
It's not only jQuery, but most JavaScript libraries are used to interact with the user interface or doing some communication things in the background. If they weren't, you could probably replace them with a server side library for the same job.
Many APIs, like the ones used for input and output are very different. If you are thinking of a copy&paste approach to convert a library, you would need to recreate a lot of those APIs for it to work. For example, a library to draw something on a canvas: You would either need to recreate the canvas API to draw the canvas instructions in flash - or create a wrapper to make flash call the original API to draw it on a real canvas. Alternatively rewrite all those parts, which are likely to found almost everywhere in the library.
That leaves us with libraries that strictly use non-js specific stuff. Maybe encoding/decoding libraries or algorithm and math heavy libraries. Those libraries may can be converted more easily. It would be quite a lot of work to refactor them into maintainable code though (in the OOP based Actionscript 3 sense). Apart from some less changes in the syntax, it probably requires almost the same amount of work to port the library to any other language. Also, chances are, that those generic libraries already exist for Actionscript.
This is a very old question but I thought to give an up to date answer.
Adobe ceased updates to its flash browser plugin as of January 12, 2021.
There are now some libraries and/or browser plugins being developed to continue flash support.
One that has the option of loading a JavaScript library from a HTML script src tag is Ruffle. As of this date it support 70% ActionScript-1/2 and 5% ActionScript-3.
The developers claim they plan for full support of AS1, AS2 & AS3.
I have tested it myself and found it to work quite well for many SWF files containing AS-1/2. The only thing required is to adjust your server software (ie. Apache, IIS, etc.) to allow wasm file support.
Use the link titled "Self Hosted" to download the necessary files that you must host.
ref. https://ruffle.rs/#releases
I'm currently working on a new Date class with some extra clock skew features. I want to fully test it so I can guarantee it is a drop in replacement for the existing Date class.
So coming from the Ruby world - we have a rubyspec project which is a test suite for all of the standard features, so that different interpreters can easily be compared.
I've been looking around for something similar in JavaScript. The only thing I've found so far is the JavaScript Test Library. I've ended up porting some of them across to Jasmine so that I can run them easily in multiple browsers.
Is there something better I can use? It seems like this type of thing would be really valuable.
You should look in to JsTestDriver. It is a Google project. You can set it up so that it will run your tests across multiple browsers and OSes. Also, you don't need to write any kind of HTML test pages, you just write your tests in JavaScript, which is really nice.
http://code.google.com/p/js-test-driver/
My choice is Cucumber-JS:
Describe behaviour(Specs) in plain text.
Gherkin: Business Readable, Domain Specific Language
Reusability(language independent): even on other projects and other languages.
Gerneration PDF/HTML Documents.
Custom Formatters
Supports Node.js and modern web browsers
I have developed one of my modules using Dojo. Its gone really well and I have done a lot of custom plugins and server support in Dojo to allow AJAX calls, RPC + SMD communication with my server.
However, now that I am getting onto the user side of things, I am seeing that jQuery has some really nice already built plugins. Do you think it is possible to support both JS libraries realistically without it being a massive problem?
What kind of integration can I achieve? Does anyone have experience in this?
I have probably written somewhere in the region of 30k lines in Dojo for my Administration panel...
jQuery is very good about not messing with the prototypes of built in javascript objects (unlike Prototype), this allows it to be used with other libraries quite easily.
A source of potential conflict is jQuery's use of $ as a shortcut for jQuery. I'm not a dojo user, but if this conflicts with dojo in some way, there are instructions addressing this.
That said, I think you'd be better off looking at these jquery plugins and rewriting them and porting them to dojo. I'm sure the dojo community would appreciate it, and it would give you experience. It'd also make your application a little slimmer in the waist area.
Edit: I've noticed a couple answers trivializing the download speed of adding an additional library. I'd take this with a grain of salt.
As developers we tend to see only the extra 10ms it takes to download the library over localhost, or from our development server on a 100 Mbit LAN. The download speed is not so trivial from California to Virginia, or especially from USA to Europe. Additionally, it adds further burden on your client's javascript engine. If they are using a 1-2 year old good computer with Safari or Chrome, this would be negligible, but if they're on IE, FF2, or some versions of FF3 the difference can be severe, or at least measurable.
When using 2 libraries (both of which, I'm sure - were designed to be used by themselves) you have 2 main worries:
That one library will effect the other.
That having a dependency on 2 libraries will bloat your pages.
In this case, I would bet that #1 is not going to happen. Although #2 is still a concern.
Most of the popular JS libraries can be scoped to their own global shortcuts. JQuery can be set to not initialize the $ variable. JQuery aside, I hear that Dojo and Prototype can work together without conflicting.
Regardless of what combination of JS libraries you decide to use, the best way to get information on compatibility issues is to hit the mailing lists relevant to the JS libs you'll be using with each other.
http://docs.jquery.com/Using_jQuery_with_Other_Libraries
http://www.dev411.com/blog/2006/06/13/dojo-and-prototype-together
Query.noConflict() makes for fairly easy interoperability because you can redefine $. As hobodave draws attention to, Prototype is lousy in this regard (because you can't easily just redefine $ with Prototype). I am not sure but I think Dojo doesn't have any issues of it's own and plays nicely with others out of the box (please someone correct me if that's not true).
The biggest problem I've had is the number of "must have" libraries written in specific frameworks, such as for things like sophisticated graphing that would be non-trivial to implement from scratch.
Bloat is bad, but compared to image sizes JS script sizes are of negligible concern (because it's so small and connections are so fast and it's only on first page load if you get your caching right, it's almost a non issue). I'd say maintiainablity being more of a worry, and it's a matter of deciding if you want that must-have-plugin that you don't have the time or inclination to reinvent in whatever framework you are using.
I have used Prototype, jQuery, and ExtJS on several projects (for various reasons) and almost always use jQuery and ExtJS together. One way to limit trouble would be to avoid mixing libraries in any given page - keep Admin page to dojo and new pages to jQuery - but what fun would that be? :-)
I find few problems when integrating jQuery and ExtJS. I pick a framework for classes/objects/inheritance (I use ExtJS) and stick to it. Then, I use ExtJS to create most widgets and I use jQuery for low-level DOM manipulation and simple widgets. Again, I cannot recall running into conflicts when using two libraries, but FireBug is a good tool to uncover suspected causes of such conflicts.
I am developing my first ASP.NET MVC application and I beleive that Script# can help me a lot. But it cannot find the resource necessary to support my development.
I could not find The codeplex site;
There is only one manual, which is very good, but it is not enough;
I could find very few tutorials;
I know that Script# was used to develop ASP.NET MVC scripts and that the source of MVC distributes the library.
But it seems that it is used only internally in Microsoft.
Where can I find other resources???
Do you really think that Script# will be continued and new versions will be deployed and it should be used by third-party projetcs ???
Thanks in advance
Don't be afraid of Javascript, it's a beautiful and powerful language. And with frameworks like jQuery, Prototype and Dojo, DOM manipulation and AJAX are greatly simplified and cross-browser issues are mostly history.
About Script#, I agree with this answer by mcintyre321. Last release over a year ago + closed source = no go for me.
UPDATE Jan/2010: there have been new Script# releases since the original writing of this answer. It's still closed-source but the author mentions open sourcing it after 1.0
UPDATE May 2011: Script# is now open source.
In short, my answer is: if you like powerful IDEs that run on Windows, OOD and C#, use ScriptSharp. It is more maintainable and structured, and demonstrably stable enough to use on serious projects. It can also be easily extended, as illustrated below and by other projects.
Since this is yet another Google indexed thread where people refer to Script# and jQuery as mutually exclusive I just wanted to point out some people are merging these two worlds, and in my case unleashing a lot of power by doing so. I'm offering a completely free and reusable library to access jQuery 1.4 from Script# projects, and full source code for the solution that generates it (almost exclusively from jQuery's own API documentation file):
http://www.christophercrooker.com/visual-studio-2010-rc-custom-tool-for-code-generation-and-jquery14-with-intellisense-for-scriptsharp
IMHO Script# fits well for large projects only, with really "rich" web client. Participating in such kind of project, I could only say that Script# helped us much. josephhemingway's remark about strongly typed is 100% true for such case. Also it allowed us to introduce new .NET developers without any JS background quickly. Assuming Nikhil Kothari's plans to open-source it in the summer 2008, we even decompiled (don't tell anybody! it's illegal) it and introduced generics, operators overloads, various bug fixes, etc.
BUT. Then Script# support faded away. Project on CodePlex with discussions and issue tracking was closed (interesting that parts of framework were published there shortly before). No updates, no future plans, no explanations. After such thing I'd consider Script# only after it goes open source to give the community ability to support it. E.g. on CodePlex.
I use Script#, I think it is great. You can use it with any framework, jQuery, dojo whatever, you would however have to wrap the framework, this could be a big job...
It's only benefit as I see it is that it allows you to develop javascript in a strongly typed environment. I think this is a HUGE benefit. I refuse to develop in weakly typed languages as maintenance is a nightmare.
If however you like to work in a weakly typed language then you wont need Script#.
Short answer NO. Wait for TypeScript.
Script# is really cool, but MS decided not to support it at all. The reason for that turns out to be that they were working on a better version of that - TypeScript (http://www.typescriptlang.org/)
It adds support for everything you need in a static language (intellisense, type checking, interfaces, classes etc.), but still looks very much like JS, and more importantly - confirms to the upcoming ECMA Script 6 standard. (unlike Script# or google's Dart)
Like the others have I would recommend some JavaScript (namely jQuery). Should you wish to continue with Script#, Nikhil Kothari's blog may be a good resource for you. http://www.nikhilk.net/ScriptSharpIntro.aspx -- That being said, I think you'll find that you are more productive with jQuery. There is a large database of community written plugins so you wouldn't necessarily have to reinvent the wheel on everything you want to do. jQuery plugins instead of ASP.NET Controls
Wow Val you got generics to work in
it, I'm impressed, was it hard?
Generics support would be great, so
would method and operator overloading.
josephhemingway
The whole point is that ScriptSharp's parser supports full C# 2.0 syntax. The only thing needed is to generate the proper JS. Not much work, considering JS dynamic nature. Generics would act as Java-style ones, i.e. no generation for each closed type argument set, just one class.
Are you sure that it is illegal to
decompile it, I will have to have a
look to see if it is the terms of use.
josephhemingway
Yep, it's illegal. EULA showed in setup clearly mentions that.
A release went out today, so it is good to see that it is still active.
Regardless of the previous lack of updates and that it not been open sourced I would still use it over plain js. You can stop using Script# at any time and more forward with the 'compiled' js if you don't like it.
I agree with you Val though that it really only fits large js based projects. I don't think you would get much benefit out of using it to perform basic page functionality like validate form input etc. It probably wouldn't be worth setting it up.
If however you are heavily using javascript and need to replicate OOP then I think it is a must. Things like refactoring becomes so easy, with plain js I would never refactor because it was just too hard to implement, over time my code became a mess.
Wow Val you got generics to work in it, I'm impressed, was it hard? Generics support would be great, so would method and operator overloading. Are you sure that it is illegal to decompile it, I will have to have a look to see if it is the terms of use.
The other advantage of using ScriptSharp that no one has mentioned is that if you need to interact with C# (using AJAX/REST/SOAP) you can use the same class definitions in both places and be sure that you have the interface defined properly, because it's the same source file! I have tried to use logic in shared source files with minimal success due to the way ScriptSharp's corelib is not 100% compatible with the C# corelib. But it works great for data file definitions.
I am using jQuery. It is really good. But I beleive that It is more confortable to me to work with C#. Even if it is a subset.
Also I would like to add that you certainly should use ScripSharp when you are planning to develop multiplatform projects. For example, at present time I write my image processing library code for .NET, JavaScript (ScriptSharp), Android (Mono) platforms on C#. Also I am planning to port my code on iOS (Mono) and Windows Phone in the future. And I think it's great code reusing and developer time minimization!