I am about to embark on a Node.js project with a fairly large codebase. I would prefer to keep my code separate from node_modules.
I would ideally like to work with namespaces and folders as I think it would be a nice way to manage things. However, assuming I have read correctly, this would mean that I would have to import any files/"classes" I require using the path to the file which would be quite messy and hard to manage.
What is the defacto method for managing a large amount/ of code for a Node.js project?
My advice is to use a static typed language, since they provide automatic functionality which helps managing large codebases. That could for example be dart, typescript or coffeescript, all being able to produce javascript.
This post explains well the benefits (especially compared to JS):
http://arstechnica.com/information-technology/2014/06/why-do-dynamic-languages-make-it-difficult-to-maintain-large-codebases/
Some of the main problems stated in the linked article:
There is no modularization system; there are no classes, interfaces,
or even namespaces. These elements are in other languages to help
organize large codebases.
The inheritance system—prototype
inheritance—is both weak and poorly understood. It is by no means
obvious how to correctly build prototypes for deep hierarchies (a
captain is a kind of pirate, a pirate is a kind of person, a person is
a kind of thing...) in out-of-the-box JavaScript.
There is no
encapsulation whatsoever; every property of every object is yielded up
to the for-in construct, and is modifiable at will by any part of the
program.
There is no way to annotate any restriction on storage; any
variable may hold any value.
If you started with JS and don't want to abandon your current code base, you could switch to typescript.
Shortly before my JS project reached 5000 lines of code (in about 15 files), I moved it to typescript. It took me about 4 hours to get it back to running.
This post gives some insights from someone movig Node.js to a typescript environment:
http://tech.kinja.com/my-experience-with-typescript-710191610
Related
I need to write a library that can be compiled to Java-classes (to be more specific: Android) and JavaScript or TypeScript (modern Browser and Node.js).
The lib will deal with lists of objects with a lot of numbers and has to calculate statistics and filter/manipulate the lists. No rocket-science, dependencies can be bridged for each environment. No problems with decimal arithmetics. (=> The libs could be developed in TypeScript and Java, but nobody wants to maintain 2 semantically equal sources.)
I've no fear to learn a new language, but integration should be smooth (i.e. create a .jar with standard Java interface and Java types and a .js file for JavaScript/TypeScript without hundreds of kilobytes of runtime).
Could I choose Scala/Scala.js for this?
Would it work with Kotlin?
Has anybody of you guys managed an equal task successfully? What are the caveats?
Well, the basics are very normal for Scala/Scala.js these days -- many libraries cross-compile with no changes. The Scala.js compiler is highly optimized, and only includes code that is actually invoked, so the output is reasonably lean. (Unless you need bulky external dependencies, which the SJS compiler can't do much about.)
Managing the dependency differences will be some extra effort, if you need to deal with them differently on the two sides. This isn't terribly unusual for Scala/Scala.js, but does require that the project be structured for that. The documentation of CrossProject gets into the details.
But overall -- yeah, that's all fairly common at this point...
I currently have a large JavaScript application with a lot of code written in vanilla Javascript for a specific platform for where I work.
I need to transform this into a web application I can open in the browser. This should be able to be done relatively easy by swapping out the components from my current application to the components of another web technology.
However since Angular2 is written in TypeScript, if I was to choose it as the framework I use, should I really also be rewriting the rest of my non-component JavaScript to TypeScript to or will I not need to do this.
Would it be a bad idea to have an application which was half TypeScript and half JavaScript like this?
It's not a bad idea to mix TypeScript and JavaScript. I do it every day. But you have to now that it may be very painful in some cases. So I can only advice to enforce migration to TypeScript as fast as possible.
I would suggest you to read this introduction to migration from JavaScript to TypeScript: https://www.typescriptlang.org/docs/handbook/migrating-from-javascript.html
This might also be a valuable source: https://basarat.gitbooks.io/typescript/content/docs/types/migrating.html but I have the impression that the author has a very narrow opinion on how to work with typescript so just don't take everything there as it is, but just as a suggestion.
There are also a lot of other resources about migrating from JavaScript to TypeScript.
For the last month of migration to TypeScript I can say, that in many cases you can simply change your JavaScript to a TypeScript file and add exports. Than you need to add the needed imports in the other places and everything works just like before.
If you can make sure, that you only use old JavaScript in your TypeScript and not the other way round you can split your project into to packages. Load the JavaScript into global as done before and than create Typings for the parts of your JavaScript you use in TypeScript.
I just started learning QML, with no previous experience in Qt or GUI development in general. My first task is to write a file manager. So far what I like about QML is that I can do design in plain text, but it's been quite challenging finding the way around to achieve even simple things. Currently I use Qt.labs.FolderListModel 2.1 as the work horse for directory listing, and I haven't even touched C++ or PyQt yet, it's purely QML now.
So I have a few questions regarding the future path of my little file manager:
Is FolderListModel powerful enough to do all the things a
versatile file manager can do? As far as I see,
QFileSystemModel looks more feature complete? And the fact
that the former is in Qt.labs worries me a bit. If indeed
FolderListModel is meant to be used as a "quick-and-dirty" thing,
does that mean that it's better to switch to QFileSystemModel
sooner? Since I approached the Qt world from QML rather than the
traditional C++ angle, what is it like to replace my current
FolderListModel code in QML to something backed by Qt/C++ or PyQt?
Related: I heard that it's actually possible to write complete applications in pure QML (with JavaScript). If the application is driven by some back-end, e.g. a database, I can see that QML alone is probably not expressive enough. However, in my case of writing a file manager, despite the "performance" argument, is it a good idea to try to stick to pure QML, using JavaScript for all the business logic?
I have been working recently on a simple file manager in QML. The problems you will face if you stick only to QML are:
not being able to know how many drives are currently plugged in.
not being able to easily sort files by name. Using provided sorting flags will result in having B.txt before a.txt because of the case.
Fortunately it is easy to connect C++ classes with QML so you will always be able to expand default QML features.
How to connect C++ and QML: http://doc.qt.io/qt-5/qtqml-cppintegration-topic.html
In all the ways I've worked with Javascript, I find that nothing ever satisfies my desire for self-documenting code. I want to be able to see the APIs of modules, functions, "struct" fields, and event payloads within my own code.
I'm curious if any IDEs or transpiled languages help people easily keep their internal API visible? For example, with many languages, often an IDE will give an expandable tree view of packages/modules/classes/functions. Javascript makes this difficult as there are so many ways to code all of these entities.
I find when writing an application in Javascript that after it reaches a certain size, I have to keep jumping between source files to remember these things. Consistent naming, clear coding style, and such good habits only go so far. In a language that has no static typing, very loose rules around function arguments, and passing functions as callbacks, JS code can be hard to scan and immediately see the higher-level structure. It's hard to separate interface from implementation, as all JS code is implementation.
In large projects with many programmers, it makes sense to enforce rules about documenting functions in comments and maybe auto-generate docs. But doing independent development, this is like a lot of manual work just to remind oneself of the architecture and internal API, and likely to be out of date most of the time. I'm not going to look up a function to remember what params it takes, see that it has no docstring comments, add them and rebuild the docs so I can go read them.
TypeScript sounds promising but seems too tied to Microsoft tools. CoffeeScript saves typing and can make for cleaner code, but I don't think it solves the problem of exposing a high-level view of the structure of an application.
WebStorm actually exposes some of what I'm looking for, but I wonder what else exists.
I'm looking for any tips, tools, techniques others use to mitigate this issue.
I'm building a JavaScript engine. I used a simple function as a class, added subfunctions, strings... and used prototypes to add other objects...
Everything is fine. The problem now, is that I'm using one class (or main function), because I need it to be so. It's becoming huge, to the point that I can't control it any more and debugging the code is becoming as hard as hell.
I'm a C# developer, who used Visual Studio. I never come across this problem, because I have different files/classes/forms...
I wonder how developers here deal with large JavaScript files. What tools/strategies/techniques do you use to solve this issue.
Thanks
You can still create multiple objects analogous to your classes and objects in C#.
I suggest you go look at some JavaScript frameworks like YUI3 ( http://developer.yahoo.com/yui/3/ )
These provide nice mechanisms for structuring your JavaScript code and behaviours. For example YUI3 provides the Y.extend method to allow you to extend one object from another much like you do in C#. There's a whole suite of other mechanisms you can use in JavaScript that are actually a lot more powerful than what you've learnt in C#.
Go look up prototypal inheritance, and maybe watch some of the videos by Douglas Crockford on the YUI Theater ( http://developer.yahoo.com/yui/theater/ ). All really excellent stuff that'll show you how you can do this sort of thing in JavaScript without the major headache of giant scripts.
To answer you question more specifically, I use the module pattern in YUI3 to allow me to split my code up into mulitple files. It allows a mechanism where you can define modules then use them from other files, while auto-resolving the required dependancies. So you define multiple JavaScript files containing your behaviours and code defining various modules, which can then be 'used' in other files.
YUI().use('my-module', 'my-other-module', function(Y) {
Y.MyModule.doSomething();
Y.MyOtherModule.doSomethingElse();
});
'my-module' and 'my-other-module' can be defined in completely different JS files, which I then tell the YUI loader where to find, and it automatically includes them into my pages.
This is really powerful, and lets you break up your code for maximum reuse and simplicity. Lots of other developers are also putting their code up on the YUI Gallery so you can mix and match behaviours into your projects.
jQuery. It's a great tool to help you write less and better code. It's a simple JS framework/library you link to on every html page. It should be quite simple to learn, and there's a lot of support, manuals, books.
Google created GWT to solve this problem.