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 7 years ago.
Improve this question
I recently discovered Typescript. Coming from an OOP C# background, I find Javascript very difficult to work with and am naturally thrilled about Typescript.
I'm currently using Backbone.Marionette.js in my application to manage future complexity (future because it's still the early stage and not yet that complex).
Now I understand there is still room for Backbone.js to play an important role in my application even if I'm using Typescript, but the more I learn Typescript (and begin to love it), the more I start thinking that its objective in managing complexity in enterprise application overlaps too much with what Marionette tries to accomplish. I understand they do it in two completely different ways but coming from C# I of course prefer the OOP approach instead of yet another JS plugin.
Are my considerations to phase out Marionette out of my application justified or is there less overlap than I think? Keep in mind, I'm new to all 3 Backbone, TypeScript, and Marionette and this is the first application I've used them in, which makes it difficult for me to assess this question.
"TypeScript vs Marionette" is the wrong perspective. That would be like "C# vs WinForms", and asking "Should I stop using WinForms when I switch from C# to VB.NET?" This question doesn't make any sense because it is trying to compare a language to a framework.
There are some things that TypeScript will prevent you from doing with Marionette or any other JavaScript framework that takes advantage of JavaScript being dynamic. But that doesn't mean TypeScript replaces Marionette or any other framework. It only limits the usefulness of the framework due to restrictions that TypeScript places on you.
My answer would be based on the following considerations.
Firstly, what parts of Marionette are you using? If it is just the module loading then you don't need it. If you are using a lot of the templating and eventing it may be useful still. If you aren't sure yet what parts you might use, don't use it until you have a compelling reason to use it.
Secondly, how much can you write before you need to make decision? For example, if you start coding today, how long can you defer the decision. The longer you wait, the more information you'll have to help you make the right choice. If you write plain TypeScript, you can wait until you actually need to bring in a framework or toolkit and then choose the one that solves your real problem.
So really, my answer is start without it and wait until you have a problem to solve before choosing how you solve it.
Related
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 2 years ago.
Improve this question
My goal is to fully understand the differences between a library and a framework
I have been able to have a basic understanding of the differences between the two. Except for one basic description that is commonly given out:
"The key difference between a library and a framework is "Inversion of Control". When you call a method from a library, you are in control. But with a framework, the control is inverted: the framework calls you"
programcreek.com
What does it mean for a framework to call you?
I have done research on what it means to call a function, method, etc. and now have a full understanding... But I am not able to comprehend nor find any information on what it means for a framework to call you
I have tried looking this question up with multiple different ways to frame it and all I am able to find is: MFC Framework how a framework calls your code. I am not able to find anything in the realm of languages or frameworks I am familiar with
Arguably any sufficiently complete library is indistinguishable from a framework. By inversion, any sufficiently thin framework can be treated like a library.
In simple terms, the more a library dictates how you code, what practices and conventions to follow, and how to organize your code, the more it resembles a framework.
The "inversion of control" is something that doesn't necessarily happen in a clean-cut way. Some frameworks are very light in that they don't force a lot on you, that you can yield control incrementally. Others dictate strict terms, that you either do it their way or you don't do it at all.
There's a huge spectrum here of framework-like-libraries and library-like-frameworks.
When a framework "calls" your code, it usually means that you've followed the patterns laid out by the framework itself and your code slots into pre-defined locations in that pattern.
That's not to say libraries don't call your code as well, they just impose fewer constraints on where, when and how that happens.
So here's a library call:
// Tell the library to perform a user registration
let user = FancyLibrary.registerUser(...);
Here's a framework-like structure:
// Start up the framework and ask for notifications if/when a particular event occurs
let app = new SuperFramework({
onRegistration: user => { ... }
});
Though there's often a blurry line here. Some situations are very clear, but there's a lot of toolkits that have strong conventions, even if they are libraries.
For an example of something that's sort of in the middle, consider Sequelize which is an ORM. Is it a framework? Most would consider an ORM to be similar to that, it has strong conventions and so on, but it's also a library that can be used to make simple SQL calls, nothing more. It's hard to say exactly what Sequelize is other than a robust toolkit that can be used to perform complex tasks.
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 6 years ago.
Improve this question
First I learned HTML, CSS, JavaScript (es5, I believe I have a firm understanding of the foundation, like event loop, hoisting, closure, binding etc), then jQuery, PHP.
Then I started using frameworks. Built some pages with ReactJS (really liked the the uni-direction and dividing everything into components structure), built a restful API with Slim.
Then I realize ES6 has been out for a while now, and now I should covert all my React code to that. I also find out about requireJS, and Flux (design pattern), redux (but I need NodeJS to even get started). And a lot of other frameworks.
I'm just so overwhelmed by all of these, I don't know where to start or what to use, for example:
should I be using requireJS or just learn ES6 import/export or should I be using nodeJS? Sometimes it is tough to even understand example from Git, their files are all over different folders.
what other framework should I learn, AngularJS, backboneJS?
I have a Computer Science degree and just want to get into a junior web developer position, and I need a job. But I feel like new frameworks keep on coming, by the time I catch up, new ones will come out, how am I ever going to get into the field?
I'm in despair, will someone with knowledge please give me some direction? I really need advice and have no idea who or where to ask beside here.
To answer your questions specifically:
...now I should covert all my React code to that.
Just use new features as you become aware of them, no need to convert everything!
I also find out about requireJS, and Flux (design pattern), redux (but
I need NodeJS to even get started). And a lot of other frameworks.
My advice is forget about requireJS, flux and redux( -take a look at mobx)... Get webpack/babel/react set up (there are template projects you can use as starting point) and you are good to go with es6 and learning cutting edge skills that will easily land you a job. IMHO.
should I be using requireJS or just learn ES6 import/export or should
I be using nodeJS.
Yes, just use es6 import, why not? You'll need node/npm installed as many things depend on them.
what other framework should I learn, angularJS, backboneJS.
Nah, these are old hat now - continue with react as it is in demand right now. Look at mobx as an alternative to redux. Other libraries? Knockout is old, but good. RxJS is interesting. Learn about functional programming, protocols like HTTP and fundamentals that will distinguish you in an interview context. Make demos.
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 acting as web developer for a small startup, taking over as the only in-house developer to maintain and adapt the application that was initially put together by a team of contractors. I would consider myself to be at an intermediate level with Ruby on Rails. I know enough about front end technologies like HTML and CSS to use Bootstrap or Foundation effectively and write my own tweaks when necessary. However, I only can read the JavaScript code of other developers well enough to make small modifications to what's already in place.
I would like to become proficient in JavaScript to help round out my skillset but there seem to be a lot of JavaScript "options" out there and I'm not sure what's on the way in, what's on the way out, what's popular, what's most useful, easiest to start with, best fit for Rails applications and so forth. And by "options" I mean "regular" Javascript, jQuery, Node, Angular, etc etc.
In hopes that my question will meet SO terms as "answerable" I'd like to focus on the question of what kind of Javascript fits best with Rails and which technologies are the most generally relevant today (i.e. not on the way out of popularity already).
Your choice should depend on what you're doing. One case might be using Rails primarily on the back-end, pulling data from it, and then generating your markup and displaying content primarily on the front-end with JavaScript. In that case, you should look into a JavaScript framework like Ember.js or AngularJS. If you're going to be generating your markup primarily on the back-end with Rails, having that markup being pre-populated with content before being sent to the user, you might be better off using jQuery for DOM manipulation and the occasional AJAX request to your Rails back-end.
In the case you're looking for a framework: Yehuda Katz is a leading voice in the Ruby on Rails core team, and has a similar role inside of the Ember.js project. While this isn't strictly objective, I'd say that Ember is the JavaScript framework that most closely matches "The Rails Way". That said, any framework will integrate well if you're using Rails as a backend, and AngularJS is currently more popular and might be easier if you're looking for examples and helper libraries.
I'd like to point out that Ember is just a framework, just like jQuery is just a library. Knowing JavaScript from the bottom up is a very helpful thing when working with anyone's code. I highly recommend checking out the Learn JavaScript page on MDN, and maybe picking up a copy of JavaScript: the Good Parts by Douglas Crockford. The former has a bunch of free information about getting up to speed on JavaScript. The latter is a dense, and somewhat controversial book, but (in my opinion) is one of the best books about dealing with the language's rough edges.
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.
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 9 years ago.
Improve this question
We are a student team maintaining a mobile app written mainly in javascript (also jquery) and PHP.
We recognized that we have to improve the structure of our code and have to implement structures and workflows within the Team.
Status of the code:
By now the code is still very tangled, not loosely coupled.
Classnames with identical names in different folders.
Wide usage of == instead of ===.
Wide usage of global variables.
We reinvented the wheel for parts of the code. (where frameworks already existed for certain purposes)
Status Methods/Tools:
We are now implementing SCRUM
We use Redmine Backlogs which works good for us.
We implemented a usable branching model for git. (http://nvie.com/posts/a-successful-git-branching-model/)
We started to use jsdoc to do an inline documentation of the code.
We stumbled across SonarQube (a code quality checking tool) and think this might be helpful.
We are still new to TDD and skeptic about it.
We do not have expertise in designpatterns but would like to apply them.
Only few in our team of round about 6 people know the basic concepts of MVC, MVV, MVP.
We want to start with refactoring our code (to unobtrusive js?) around the first week of september.
Which steps would you suggest so that we don't stumble too much and that the process is kept transparent and motivation is high?
Would you start by fixing little issues like the == / === thing? (things SonarQube comes up with)
Would you start with implementing a TDD framework but without having a testable MVC/MVV ?
Would you start with separating js from html and css?
Would you start with bugfixing of old, not yet resolved tickets to have absolutely clean branches?
Thank you very much for any suggestions/ideas/best practices
Marc
Well .. step nr.1: read this book. You have time enough for that till September.
Watch following lectures:
It Was Like That When I Got Here
Recognising smelly code
Unit testing
These materials should give you some sense of the subject.
As for real first steps, separating the HTML from JavaScript is a nice place to begin. If you know how to do event delegation in javascript - good. If not, look into it.
Then you can move on to fixing the part of page that spews out the HTML. Separate the SQL, add some abstraction, some OOP principles.
If you end up aiming at something MVC-shaped, then this list of links might help a bit.