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 6 years ago.
Improve this question
I am a java-programmer and a few months ago I discover frontend programming with javascript and html, and it is absolutely cool. So here is a js newbie's question.
Is there any IDE, default workflow or maybe best practices for javascript libs development? I didn't mean coverage and unit testing or something like this. I mean is there any tools or techniques which should I use while developing html control with some js-logic, for example? Should I write small test page in text editor and open it in dozen of browsers pressing F5 each minute and watching at browser's console or maybe there is some magic IDE which will on button press reload all browser instances and collect reports from browsers?
JavaScript Fundamentals
Be sure that you know the language. JavaScript is a bit tricky in this regard: you can easily think that you understand the language, but there are weird things that can sneak up on you. I highly recommend JavaScript: The Good Parts by Douglas Crockford. He also has some talks on Youtube with the same name that are definitively worth watching.
JSLint
Integrate JSLint or a similar tool in your workflow. It is a style checker and static analysis tool for Javascript and helps catching subtle bugs.
Avoiding F5
Check out live.js:
Just include Live.js and it will monitor the current page including
local CSS and Javascript by sending consecutive HEAD requests to the
server. Changes to CSS will be applied dynamically and HTML or
Javascript changes will reload the page. Try it!
Browser Developer Tools
Get familiar with them. I personally strongly prefer Chrome's developer tools over Firefox/Firebug, but regardless which one you choose, learn how to use the debugger.
Node.js
You should also be aware that you don't have to test Javascript logic in your browser: you can use it as any other scripting language using node.js.
As a seasoned programmer here are the steps you should follow for JS lib production.
Separate the UI from the application logic. In this case create one component for the application logic that is completely separated from all API access. API access, which means DOM and WSH and Node.js, should be separated out. I go so far as to use different files to force and ensure separation.
Create UI environments to access your logic. Have a production UI control for access by your audience and also a separate internal UI control for your sandboxed development. For example I have written my application at http://prettydiff.com/ to work from commandline, and from a browser. I have also written access methods to the application access similar to the published HTML but different for my own development for more rapid unit testing. In a sandboxed UI can use a recursive setTimeout to refresh the page in intervals for automated test plan verification as you are writing and saving code.
Focus on availability and distribution. People can get my libraries directly from my website, Github, and NPM for Node. I have a regimented process where by I upload code to the site during a production release and then perform a quick verification in the browser. If the release did not break the application then push to Github and then push this exact same location to NPM.
Distributed access to code operation is even better. Its nice having rapid and even automated access to libraries online, but being able to access unit testing via request is even better. I can remotely unit test my application's code by accessing code samples online directly by telling my application request a code sample via URI. This means that not only is my static code available for distribution and testing, but so is its operation.
Good documentation is everything. I will never even bother to examine a lib if the documentation is weak. I am not talking about code comments, though these are important. I am talking about end user documentation. I want to be able to read documentation and know everything about the subject. Node.js became popular because even before the codebase was stable it's documentation kicked ass. Get other people to QA your documentation before they QA your code. Without stunning documentation your lib is less than worthless to me.
Know your mission. Each and every lib should have a clear, simple, and well stated purpose. If this is not established then the lib is not ready for release. If an enhancement confuses the lib's purpose then it may be time to divide one library into multiple smaller libraries. Focus on precision, clarity, directness, and only the sole stated mission of the lib.
Independence is vital to adoption. I don't like libs dependent upon other libraries or frameworks. Its great that your jQuery library may be the best thing since slice bread, but I won't be looking at it. Independence means greater portability and freedom it mix and match it with other libraries that you are not aware of.
Style is important. This is touchy subject, but style is important. Keep the logic in your lib as simple and declarative as possible. If your code is absolutely declarative in nature then your algorithmic patterns are awesome. Avoid use of the new keyword unless you are an experienced JavaScript badass and severely limit use of this keyword as it will fail you in future maintenance operations. Do not algorithmically build out large strings with concatenation and continually watch the execution speeds of your code. Because even trivial changes to style or seemingly minor enhancements to the logic can destroy execution efficiency I put a timer on all my UI controls. In your development use profilers, such as Chrome's web tools to track down long operations in JS execution.
Be open about your failures. Software is never perfect and other developers will always respect this. If you encounter a bug before anybody else then be open about the existence of the bug. If it will take more than a week to get the solution out then don't delay notification. Notify your users immediately so that they are aware. I recently rolled back a major enhancement to the logic of my diff algorithm because additional unit testing showed heavy slippage. I rolled back the same day I made a decision the prior release or two was flawed and was open about the rollback. If you want people to contribute to your code base or provide bug reports then openness is critical.
I know you may have explicitly said that you didn't mean unit testing, but that is precisely the way I recommend you write javascript libraries.
If you're a Java developer, you may be familiar with jUnit. If so, qUnit may be more natural to you. Otherwise, I recommend you take a look at Jasmine or Mocha. While I prefer Mocha, my experience with Jasmine has generally been better for in-browser development thanks to the awesome Jasmine-Jquery plugin.
If you're writing qUnit tests, take a look at IntelliJ IDE which allows you to execute tests in addition to providing code coverage.
If you're developing on the browser, take a look at LiveReload. It'll watch files for you and auto-refresh your browser - great for instant feedback.
For browser compatibility, I would recommend you just get it to work on one first reasonably before worrying about the others. Check in from time to time to see if you find issues. See if jQuery can abstract some of that mess for you. Otherwise, take a look at Adobes BrowserLab.
Related
I am not a professional developer - I'm just a self-taught amateur in the field, and I followed the trends with quite some delay. My history with javascript goes back to when I was 14 years old and randomly opened files on my C:/Windows/ directory (it was Windows 98), until I found some intriguing .js files. I learned PHP, C and python, but came back to Javascript and follow his evolution from a scripting language to a full-stack tool - first, I played with Jquery a Jquery / XSLT stack, then made a little videogame using Websocket and Gulp and browserify , then recently learnt some Angular, Ionic and Vue, all based on Webpack.
I'm having though about what tool to use as a task manager. Especially, I tends to think most of the tools used these days are inefficient - hard to configure, needing a thousand plugins to work, which often create incompatibilities between versions,... And more importantly (I may be wrong here) but how come none of them are checking which dependencies need to be rebuild?
Last time, I was launching my test in a typescript project using npm test and got really frustrated. I realized the whole project was compiled every-time I changed a tiny detail in my test files. Having developed in C, I found that really inefficient and wrote a makefile to address that.
Now the bad side of make is that it's kinda hard to make it work with modern javascript tools (tsc explicitely adviced me to use a .tsconfig file instead of the CLI). Another example is there is no official CLI tool to compile a .vue file into a render() function.
Now my question is is there a modern tool that doesn't require me to rebuild, compile, minify, uglify my whole project and lose 30 seconds every time I add a commas in a file? and what's wrong with make?
I would take any idea or correction about that matter with gratitude :)
I don't know the exact nature of your project but I don't think there is a single tool for all the things you want to achieve. That's why we have the term "javascript fatigue".
Currently Webpack is the closest thing we have "one ring to rule them all" in terms of module management in development environments for javascript projects.
Now my question is is there a modern tool that doesn't require me to rebuild, compile, minify, uglify my whole project and lose 30 seconds every time I add a commas in a file? and what's wrong with make?
Since you mention you are familiar with webpack, maybe you can checkout its hot module replacement feature. Here is its description straight from the developers' website:
Hot Module Replacement (HMR) exchanges, adds, or removes modules while an application is running, without a full reload. This can significantly speed up development in a few ways:
Retain application state which is lost during a full reload.
Save valuable development time by only updating what's changed.
Tweak styling faster -- almost comparable to changing styles in the browser's debugger.
It is a sad fact that with each tool comes extra cognitive load. To reduce it, maybe you can:
follow certain patterns and habits in your workflow
have basic setups or boilerplate projects for frequent ones
check out the best practices
take advantage of cheat sheets and API docs
checkout source code before searching on the internet, It maybe less time consuming and less confusing than searching on the internet
try to master few vital tools for your projects
Following the works of developers who move the community forward maybe helpful for staying up to date with technologies, usually they gave speech and write articles.
It may look a lot of work when you see them listed one after the other but you will see it is more rewarding and less time consuming in the long run.
Please remember that, it is a common problem among developers, even the best ones suffer from it. That is why we have these tools in the first place. Good news is that, with every passing day dust is settling and tools are getting better, more mature and more stable.
For more on hot module replacement:
https://webpack.js.org/concepts/hot-module-replacement/
Is it possible to write a script for VS or TFS in order to simulate the work of programmer? For example, it would make minor changes in js file (swap two function) an commit it to TFS on schedule.
It's not a recommend way to use automatic check-in/commit in a mature source control system.
If files are going to commit automatically, some negative issues have also followed. Who is going to add the comment, what comment should be add, Who is going to associate it with related work items? These things are really important features of TFS as an ALM tool to enable traceability and visibility.These will make source control history more detailed and easy to management.
Moreover, "how to guarantee the quality of the code available in the server?" is another serious problem. Even though it's just making minor changes, which may also has a huge impact. When another developer gets the latest version he may receive code that is not working, because of the work checked in automatically by script, and so on.
The answer in this question (even not about TFS) have some useful facts for your reference. (http://stackoverflow.com/questions/8397918/any-way-to-make-vault-auto-check-in-files)
If you really need this feature, to achieve your requirement, you could create a VS add-in project, and then use TFS API to check in the files. About how to use TFS API to check in files, please refer to this tutorial.
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
we are currently evaluating the use of AngularJS in a Enterprise Application (e-Banking) as a Single Page Application.
Many of the devs#work are already convinced that there no other way to go. It is the trend, it is future proof (html, css and js) it is easy to do, less burden on the server etc etc.
Despite the interesting part of this framework, i am not convinced that there are factors that must be considered before going this road. These can be:
Maintainability of code
Testability of code, not only the ui part
Continuous integration (like TeamCity or TFS)
Developer friendliness like debugging, navigating through code
Security (if there is a risk)
Has anyone any experience on enterprise apps build like that? I would rather go with Asp.Net MVC4. Please no hypothetical answers, i don't want to start a war. Real life experience is really appreciated.
Regards
I had thought about this when incorporating Angular into our enterprise application. First, some optional background information. I really needed to keep all my page state on the client side since recreating it on the server side is a very resource intensive task. I started off with building it with just JQuery, since I only needed a few things, but soon I found myself having trouble keeping track of the callbacks I wrote just last week. Hence, I wanted to refactor. While I was at it, Angular looked like the best fit for my programming style.
To address your concerns:
I think that it is more maintainable, since it encourages you to split things up. This, however, depends totally on your team and your discipline to keep things maintainable.
The Angular team definitely thought about testing when they were making it. Things are very easy to test, from unit testing to e2e testing. Others have even found a middle ground in between.
We use Jenkins at our Microsoft shop for continuous integration since it was easier for us to plug in our own programs to make it work with our complex environment setups. However, I don't think this relates much to which framework you decide to go with.
Coming from Visual Studio, I find JavaScript in general leaves something to be desired. I love edit and continue, unwinding the stack, and dragging that yellow arrow around. That stuff is just pure magical bliss. Debugging on the browser just doesn't give you all of that.
Security is pretty good. Looking through the docs, you can see that the team is concerned with security issues such as XSS and CSRF attacks. However, anything done over the browser is hard to secure. There are new attacks and bugs discovered every other day. If you are really concerned about security, you wouldn't have an online app. You would make sure that your customers only banked in the branch with multiple forms of ID. With that said, I don't think Angular is any less secure than any other JavaScript solution.
I would like to raise another issue with all of these JavaScript frameworks/libraries. They're all fairly new and constantly evolving. Look at how many functions JQuery has deprecated recently, and you'll get a sense of how hard it is to keep on top of your libraries. Many of these are also forgotten and left to rot. Angular being one of Google's products also makes me a little scared, since they have been cancelling waves of their projects. Hopefully, Angular does not become one of those.
The documentation is also lacking. Although the community is good, the documentation is not. Many pages are half done. Again, compared to the latest stuff from Microsoft, the documentation is pretty sparse.
This being one of the new things, it is harder to hire someone to help/take over this stuff.
Despite all these drawbacks, I really like it, and I'm definitely going to push my company towards adopting it.
Yes I have used Angular with Asp.net WebAPI along with MongoDB .Pls find my findings
1)Testability is absolutely fantatic .You can easily test you unit test using karma and jasmine
2) CI. Integration of Jenkins is available with Karma
3) Easy to debug similar to Javascript debugging can use chrome extension Bartrang to debug angular apps easily
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 4 years ago.
Improve this question
Background
I need to create a potentially very large HTML/JS mobile web app that will be delivered as a mobile web site and natively using Phonegap. I'm currently working to determine the best way to organize the app itself.
The basic plan is to have many modules that will each focus on a different subject of interest . Some of these modules will be very basic (ie, announcements / news) and some will be very complex (ie, sports: team players, schedules, video, etc). There will be a side-drawer navigation that will apply to most pages so users can quickly navigate to a different module. There needs to be the ability to deep-link within modules. These modules will be created by a variety of developers and vendors.
Single Page App
Most of the mobile solutions I see involve Single Pages, which seem like a bad idea to me in this case, since there is the potential for so much memory use. It also seems like it would be difficult to reconcile hash navigation between modules and hash navigation between section within modules. Module development would have to be done with the app framework in mind and limits how things can be done by vendors and developers. On the other hand, things aren't getting loaded as often and everything can easily communicate with each other.
Multiple Page App
Using multiple pages, it seems like each module could easily be created in whatever technology a vendor was comfortable with (and could do quickly and cheaply). It would cut down on memory use, but also remove the ability for modules to communicate (a feature that I don't know is necessary for us at this point). I could see making a javascript library every module would use for common handling of various events (like logging errors, navigation, etc). Each app navigation between modules would be a new page call, resetting the DOM. Each module could use a single page design if it wished.
Help Me Please
So, is there any common or new knowledge about how things like this should be designed? I'm eager to begin work, but don't want to be rewriting things that may already exist. Do I have any glaring flaws in my reasoning? I'd love to hear from anyone that has insight.
Honestly, if you are considering building any app that you believe will be high volume and of high complexity, you really ought to consider doing native development, or at least use something like Appcelerator where the application will be "compiled" down to native code for better performance. If you are intending to just let any number of developers build their own javascript components that may or may not do a good job of managing limited system resources, so are going to quickly run into application performance issues.
On the other hand, if you are just going for proof of concept and don't mind potentially having to greatly refactor your application architecture when and if you get a sufficient level of complexity, then you may want to simply go with the web app approach.
Really, you need to also be considering your backend service architecture as much or more than the frontend architecture. that is really where you are going to run into problems down the line in trying to integrate offerings from other developers.
I had a similar architectural problem to contend with a couple of years ago. It wasn't mobile, but it wasn't entirely web-based either. The target applications were a mix of web sites and desktop apps, with the potential to go mobile in the future.
The interesting part was that there had been two prior attempts at creating a framework that could be used in a variety of situations. The problem, and the reason both attempts failed, was that the developers saw it as a UX problem space. They approached it using several different technologies, but became mired months down the road because they had made assumptions up front and flown the project by the seat of their pants.
My approach was to eschew all the UI discussion completely and focus on a backend architecture that could be approached from any standpoint. To this end, I created a web service that had data going in both directions, and was ultimately serving a mathematical model. The service is being accessed from a variety of sources using different technologies: Flash, Unity, a Google Earth plugin, and finally, from an unrelated web architecture serving up good ol' HTML.
My advice to you, is don't concentrate on the front-end mapping so much as get your back-end right. Once you have a data structure in place, you can build outward, and several issues such as memory management, monolithic app or not, i.e. one page versus many, will almost resolve themselves. Work on creating a great API with lots of good interfaces and you won't fall into a "many chefs" hole. Give a bunch of dispersed developers enough rope, on the other hand, and you'll never find where all the knots are!
The decision whether to ultimately go native API over HTML5-based technology such as Sencha Touch, jQuery Mobile, or Phonegap is an evangelical black hole that will be played out over the coming months and years. Native apps may be more fluid and speedy in some cases, but the investment in resources is something that should be considered. On the other hand, JavaScript developers are lurking around every corner and are not in short supply.
Your first step is to nail down those requirements.
If you're doing this for yourself or for your own company, then nail down how these modules (co-)operate.
If you are doing this for your employer, then somebody there ought to have a clue what they want to see, otherwise, how are you going to build it?
A solution which supports multiple pages, opening and closing modules with no communication is going to require different things than a framework which is responsible for maintaining multiple widgets at the same time, which may or may not communicate through system-calls or services.
There's no way around that -- building services/sandboxing/etc for modules is going to take more work than treating each like a page-change (or making them be literal page-changes).
When you figure out what you want your program to do, start building out an idea of the API you'd like other people to have.
Are you going to provide them with an API for building UI components, or are you going to leave that to their own whims?
Personally, I'd avoid a situation where each module change just replaces iFrames, and then the end-user can do whatever they want in there.
Likewise, I'd avoid situations where you're allowing module-creators to run whatever they'd like in a non-sandboxed environment... It ends poorly for your end-users (or you, in UK court).
But that's not a concern, yet.
First-concern is what does your platform do.
Then figure out what your back-end communication is going to look like, and what interfaces you're going to provide to module creators, and how you're going to get data from your end to theirs (http-based API, REST or whatever else... ...but work it out WELL, if you don't already have it).
THEN, when you know what your platform is expected to do, AND you have a backend which can serve all kinds of tasks well, figure out what services you're going to provide to content-creators, to make their widgets, and to upload/download data from your service, and sandbox, and the like.
While I imagine that a definitive answer would require more specifics, I'm interested in a high-level perspective about the appropriateness of heavy JavaScript integration in either cms. Thanks.
I'm going to answer the question you actually asked — rather than the question you may have meant — by focussing on "appropriateness." In my mind, js integration is appropriate when 1) it actually improves usability, and is not simply decorative; 2) is done with careful attention to maintaining accessibility; 3) is done in a javascript integration layer that achieves separateness from the content layer and modularity in implementation; and 4) minimizes page-load impact.
In regard to Plone, all I can say is that we've spent a lot of time on these issues, and that our framework team is aggressive in demanding that we meet those tests before integrating new functionality. I'm in particular proud of how we're doing on accessibility, and expect us to continue to focus on that. We won't deliberately break accessibility, and if we break it accidentally, we're going to fix it.
One very tough area is consistency. We've been bounced around between choosing between consistency within the platform's use of JS and choosing individual tools as best-of-breed for a particular functionality. I can't say we've done well on either score. The results are OK, but it gives the new developer a burden to understand the toolbox.
Plone has integrated portal_javascripts registry which allows you to
Merge and compress Javascript files to bundles
Set "safe compress" flags per file etc.
Set conditions when Javascript files are served (only for authenticated users)
Use IE conditional includes
etc.
i.e. it's very heavy tool for Javascript processing and supported out of the box.
All this can be edited dynamically through-the-web in admin interface. This is far superior tool compared to manually adding your files to <head> or using an external tool to manage Javascript compression bundles.
Plone also sets Expires headers and generates cache busting URLs for JS files correctly, something many CMS lack out-of-the-box.
More info can be found by
1) Install Plone
2) Go to Zope Management Interfcae
3) Find portal_javascripts