legality of unpacking minified javascript [closed] - javascript

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I know that this is more of a legal question but I thought I'd give this a shot.
I am learning javascript and I found some interesting drop down menu's on a webpage. I wanted to learn more about them but the code is minified with the following in the comments above the minified code:
// Unauthorized decryption/reproduction of any codes contained herein is strictly prohibited and will result in severe civil and criminal penalties.
Is it really illegal for me to unpack the code and look through it? Can I be sued for looking at code without actually using it?

I'm no expert, but if there were anything criminal about viewing a website's source code, then browsers would not make it so easy.
While I can definitely say that using someone else's code without permission is wrong, I think it's a great thing to learn from it.

IANAL
Minification is not encryption. You already have permission to copy the file to your machine and open it (as your browser requires these permissions to use it). There is no legal protection for examining the contents of a file that's freely available. You can even modify it on your own system at will, these sorts of copyright allowances fall under fair use because you're doing so for educational purposes.
What you can't do is distribute the file or the modified file.

In my honest opinion, it shouldn't (and probably isn't) illegal to look at the code since it's open to anyone.
Using and learning from the source code are two completely different things.
Using someone's work without their permission is simply wrong no matter what the context is (code, images, art, etc).
But learning from other source code is probably the best way to learn and get better.
As for their legal note, I think they just put that there to scare people off but I don't think it would stand in court.

Related

Is it worth of learning cfclient API for mobile application development? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am ColdFusion developer working in ColdFusion since last 2 years. Recently before few weeks i have started learning cfclient API of ColdFusion Splendor as I am always interested in Mobile application development. But today after reading comments on the blog
http://blogs.coldfusion.com/post.cfm/coldfusion-mobile-features-are-not-just-about-cfclient-but-it-is-necessary#comment-08603915-B031-CC32-1C2DE6521C233F65
I am in big dilemma, Is it worth of spending time for learning cfclient. Some of conclusions that I found after reading the comments on the blog are.
Adobe never have a good track record on generating JS. They generate very ugly looking js.
cfform and cfgrid were introduced with some client side functionality.But now a days no one loves to use it because they have not been updated since long and we can get more flexibility using custom js library.The same may happen to cfclient.
It's a crappy decision from Adobe to focus on mobile application development instead of making the server side language more robust and fixing old bugs.
cfclient inspires the developers not to learn JavaScript.
Adobe is trying to solve a problem that does not exist.
I think you've answered your own question here, to be honest: don't waste your time.
Basically <cfclient> is, by Adobe's own admission, just a hook into the language to tell how the compiler should treat the code: translating it into JavaScript instead of compiling it to bytecode like with normal CFML. And it's a really crap way of achieving that.
The other reason is that they couldn't work out how to implement the hooks into ColdFusion Builder to make all its mobile-dev workflow work.
Another problem is that the Adobe guys are just... not any good at writing anything other than Java. This has been borne out by every single foray into anything other than Java that they write (this includes CFML, incidentally: they can't even write that).
So do you really want journeymen developers who aren't comfortable in the language writing wizards to write your JS for you? No.
Do yourself a favour, and just learn to do it properly. <cfclient> is just an example of Adobe having not learned their lessons over the years after all the <cfform>, AJAX-enabled layout widgets like <cfpod>, and Flash forms. They have never had the skillset to do this work properly, so don't put yourself at their mercy.
Oh, and I'm also voting to close the question as it's not one that can be answered objectively.
This is my take on it
Even if it were good approach today, it is not future proof. New browsers will come, new javascript features will come. I fear that this won't move ahead.
I could not agree more
And some of the existing bugs really need to be addressed.
<cfclient> asserts that client side development should be in cfml. IMHO, Coffeescript covers some of those concerns.
There is a demand for Mobile friendly websites. If I had to pick ONE thing to move ColdFusion forward in this arena it would be: Can we get the JSON functions to work right
There are many ways that Adobe could have moved forward on the mobile application front. If they promoted various community based solutions that would be useful. I know Bootstrap + FW/1 + ColdFusion. But I don't know PhoneGap/Cordova + ColdFusion. I would be good to see those work together.
True, But if you're using CFClient, you're not wanting to write JS anyway, so what do you care what it looks like on the client.
I believe Adobe has promised that we would be able to update the core underpinnings of CFClient (probably PhoneGap/Cordova) and other JS libraries.
Agreed.
I don't know about inspires.
I disagree here. I'd love for a way to quickly deploy to mobile.
PS> I'm sure since this question isn't code related, it will get downvoted / deleted; Might be a better topic for the CF-Talk mailing list or some ColdFusion forum somewhere.

Does Modernizr brings bad programming practises in web development? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
There are a lot of "buts" in approaches to web development. Recently I've read an article
why not to use Twitter bootstrap. One of the reasons were that it doesn’t follow best practices. Well I don't want to discuss about TB. What I wanna know is how is it with Modernizr - it looks like that has a lot of advantages, but what about dissadvantages? Is that also redeemed by using bad programming practises on web (like these mentioned in twitter bootstrap)?
By good practices I mean ideas which are connected with Html5 and CSS => this is not opinion based question - I'm basicly asking if Modernizr is in contrary with these ideas.
Modernizr itself tries to follow best practices as best as possible, however there are a few things that it does that aren't necessarily "best practice"
it basically requires being loading in the <head>. Since one of the main uses of Modernizr is the css classes that are added, you actually want it to block the rendering of the page until after it has ran. If you load it in the bottom of the page (which is the "best practice" for javascript, generally) and rely on the classes it provides, you would see a flicker between the non-support and support versions of your styles as it runs.
It can be heavy. There are ongoing discussions on the github issue tracker about how we can improve the execution time of the library, as well as new preposed updates to the lib that would group tests to increase speed
Not only that, but it can be used poorly. One of the most common issues is that people deploy their public website with the debug build of Modernizr - the one that includes ALL of the tests. This means running very large amount of javascript that never impacts your site.
Other than that, modernizr tries very hard to help define best practices, let alone just follow them. If you ever find there is any issue what so ever, I would really encourage you to open up an issue on the github repo to help us move the internet forward.

is it ok to forget about people without javascript turn on? [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am currently building a new style ecommerce shopping cart to test various scenarios and get the best conversion rates. Alot of this will be Javascript based.
So I am trying to establish whether we are now in a time where we can simply say we happy to drop support for people with javascript turned off?
Thanks for your help help and advice in advance.
Look at your stats!
See how many of your users have javascript enabled, crunch the numbers and decide if you can afford to lose them.
I, as a person who lives happily with Noscript addon for Firefox, advise you to put a warning in a <noscript> tag for us noscripters, telling that your site relies heavily on Javascript. This will do the trick. It is not ok to forget about us, because there are lots of us paranoids out there, but we know how to turn javascript on, so you just need to be gentle with us, and everybody will be happy.
UPD: Just copy the StackOverflow's own <noscript> solution to your site, and it will be enough :)
That is a personal/company decision that needs to be made for each specific site based on the target audience.
For example, if you are selling computer hard-ware, chances are you wont have idiots running stupid browsers with stupid settings.
I personally require JavaScript for my backend systems and allow JS degradation on frontends.
If this is a public facing site, you should try and have some functionality that works - i.e. it should degrade gracefully. If you have a link that opens up a light window via script, for not script users, it'd be good if that link actually browsed them to a new page - this isn't so hard to do.
I would say the majority of folk nowadays would have it enabled. So its really based on whether you think the minority are worth the effort to develop a non-javascript solution.
People do occasionally have js turned off. From a commercial perspective, you can probably ignore these people, unless for some reason they happen to be highly correlated with your target demographic...
However you should ensure that the basket/functionality/style/design etc degrades nicely in absence of js.
Would a business owner want to turn away 10% of their customers? Or refuse 10% of their potential sales? Or simply throw away %10 of their income?
The answer is an easy NO. This is an ecommerce application and it's goal, because it is the goal of the application's owner, is to make money. Not turn it away.
Yes indeed, just like it's ok to leave IE 6 behind.
Yes you can ignore those users. The web has always been scriptable and is more so now, and in the near future, than ever before. People who turn js off know what they've done and understand there may be issues with sites because of it. If they know how to turn it off, they know how to turn it back on. Despite all the older articles about this question (and what if they have CSS turned off?), it's just that. From days gone by.
While there may be statistics showing 2%, or 5%, or whatever percent, have js turned off, these are not typical users who visit ecommerce sites on any regular basis and would be surprised if it didn't work for them. It is no longer reasonable for any user to think they can work with such sites without it.
Therefore, with all the ecommerce sites I am contracted for, javascript is considered a given and we have never had any complaints and I never expect any. This is the modern web.

What are some good ways to prevent people from copying my source code? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 1 year ago.
Improve this question
I have a lot of customized javascript and layout design, and I want to prevent people from using those. Is there any practical way to do this, or do I basically just have to be happy my php code does not show? I want to at least make it difficult to copy my site.
If people really want to get access to your source code they can do that fairly easily.
It is possible to slow people down to a limited degree by obfuscating code.
See:
http://code.google.com/p/minify/
http://refresh-sf.com/yui/
http://ajaxian.com/archives/utility-javascript-obfuscator
Maintaining obfuscated code is difficult. What you want to do is obfuscate it before deployment so that you can test and debug with the normal version. Debugging problems on a live site can be made a lot more difficult by the obfuscation.
All client-side code can be copied. If you're a web designer, your best bet is to just brand yourself well and keep innovating so that clients are more interested in the originator than the imitator.
There's no way to prevent people from seeing your source code. There are ways to obfuscate it and make it difficult to reuse, but there's no way to hide it. Also note that obfuscation makes it hard to maintain as well.
By far the most widespread method is to write so bad code that no one in their right mind would want to copy it, it's employed by approx 99% of web sites.
Is it actually a problem to you if someone snatch a piece of your code?
Sure it is a problem if someone the steal the whole site/application, but the only way you can really deal with that anyway is through standard legal means.
I use the Google Closure compiler for javascript. This is to reduce download size and remove redundant code but it has the added benefit of making the code much harder to read.
I have always envied people who sell JavaScript products because their work is always out in the open. I think this is a terrific deterrent for anybody who has something to lose—i.e., businesses, commercial web sites, and such. The day Google (or another big search engine) offers the possibility to search in pages' source code, you can start detecting copyright infringements within minutes.
And even if that search engine option never comes up, it's still possible to find out, very quickly and effortlessly, whether a site uses stolen Javascript.
On the other hand, a minifier used by the person stealing the code would make this much, much harder. So some minification/obfuscation, as suggested in the other answers, is probably a good idea nevertheless.
You can use an obfuscator for your code which will make site loadable but not readable to the other developers - they will not have an easy way to modify and adapt it.
You can use an obfuscator, if you like. It makes the source human-unreadable.
Scare them by using copyright marks in your code and a good lawyer. If they believe that you will sue them maybe the will steal form someone else.

What JavaScript Repository should I use? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
Many languages have standard repositories where people donate useful libraries that they want others to have access to. For instance Perl has CPAN, PHP has PEAR, Ruby has RubyGems, and so on. What is the best option for JavaScript?
I ask because a few months ago I ported Statistics::Distributions from Perl to JavaScript. (When I say ported I mean, "Ran text substitutions, fixed a few things by hand." I did not rewrite it.) Since I've used this module a number of times in Perl, I figure that statistics-distributions.js is likely to be useful to someone. So I've put it under the same open source license as the original (your choice of the GPL or the Artistic License). But I have no idea where to put it so that people who might want it are likely to find it.
It doesn't fit into any sort of framework. It is just a standalone library that gives you the ability to calculate a number of useful statistics distributions to 5 digits of accuracy. In JavaScript.
JSAN (JavaScript Archive Network) sounds like the kind of thing you're looking for, but I've never personally used anything from it apart from Test.Builder.
As long as your JavaScript can be dropped in to people's projects without polluting the global namespace or doing things which are liable to cause breakage in other people's code (adding to Object.prototype, for example) I would just stick it somewhere like Google Code as already suggested.
There is no centralized repository for JavaScript. JS Libraries usually have their own plugin-repositories, but for stand-alone scripts, The best way to promote it is to send it to famous website such as ajaxian or mashable
AFAIK, there is no central JavaScript repository, but you might have success promoting it on Snipplr or as a project on Google Code.
You could start a project on SourceForge to contain useful snippets of code like this (or google for snippets to find one).
Perl, Ruby, PHP, etc all have distribution mechanisms built into the language to consume such libraries.
There's not such a thing built into JS.
There are tons of script archives out there - but no "central" JS repo.
Consider packaging it up as a plugin for one of the major Javascript libraries such as jQuery - see http://docs.jquery.com/Plugins/Authoring for more details. This way it can be included on their plugin page which will get it good exposure as they have a huge developer base and it'll be one of their first ports of call when a need arises for such functionality.
Whilst jQuery is one of the most popular frameworks (if not the most) out there, there are a host if other libraries you could consider using in addition to/instead of it.

Categories