I've been looking at quite a few of the MVC for JavaScript frameworks lately and I quite like the overall feel of Spine.js as well as the fact it is using CoffeeScript. That said, my primary concern at this stage is I need to be able to drop an MVC framework iteratively into a fairly large existing application. Most of the documentation that I have seen on Spine.js focuses on creating new applications.
Does anyone have any suggestions on the best way to go about doing this; if there is a good tutorial somewhere that would be great too, but Google was not my friend on that one.
Or is this just a bad idea and I should go elsewhere when dealing with legacy? While Angular didn't click with me in the same way; it did however seem pretty straight forward on how I could use it iteratively with a legacy application.
I think it's rather a bad idea to do it "iteratively". I'm working as freelancer for a company where they decided to do a complete UI rework splited over a few releases. In the first stage it was planned to drop the existing JS and use spine js as MVC and require js as AMD. So far so good - but the process was "iteratively". The project/App is quite complex and it took over a half year (I'm involved since 2,5 months).
It was a big mistake to leave all the existing JS and "iteratively" replace the functionality for the release. We ran into multiple problems, because of that. If you have hundreds of js files, inline scripts, dependencies it's much easier to simply throw them away, because you can tell literally if your new code works or not. Otherwise you always have to distinguish whose fault is it: new or old code.
This was also responsible for trouble that could have been avoided, or at least alleviated, if it were a hard cut:
The product owner was not really aware of the status, because he couldn't see any visible progress. He only figured out bugs and misbehaviour. That was unsatisfying/frustrating for both parties. One quote I've heard over and over again: "It did work the other day/before - now it's not"
You start to update some outdated libs, plugins that sometimes will cause compatibility issues, because API's tend to change, so you have to fix that in your old code as well. Means: at some point it starts to feel like hacking around problems and not to develop a cool/good App. Thats's extremely frustrating too.
It took waaays longer than expected/estimated.
You've been developing in dependency of your old code that does not exist in the very end.
My personal advice is: don't do it iteratively. Do hot fixes for the live App and develop the new one on a separate branch.
I can't see how conforming any legacy app that didn't have an explicit mvc structure into a spine.js or backbone or angular etc. is likely to be a drop in experience.
Iteratively converting is going to be a lot like writing a new app minus the boilerplate stuff for defining the app GUI interaction. Start by focusing on models and controllers by pulling out components that fit well into the MVC structure. I would suggest early on to avoid certain app interaction components of Spine like stacks, and routes as those make a lot more sense once everything else is ready to be used according to spine convention.
Related
As far as I know, Aurelia does not support server-side rendering as mentioned here.
But the question is: is it possible to do this with some hacks/workarounds?
The most obvious idea would be to use Phantom, Nightmare.js or whatever to simply render that page in Chrome on server and serve that to client, but this is very likely to cause big productivity issues.
Thanks!
UPD
According to Rob Eisenberg's response on FDConf today (16 Apr 2016), server-side rendering will be implemented in 2016, there's one core team member working on that and there's a deadline for this feature.
There is an open issue for Universal/Isomorphic Aurelia which you can monitor. In particular EisenbergEffect (who is Rob Eisenberg, the creator of Aurelia) states that they are gradually working towards providing Universal support for Aurelia. This post from him provides most of the detail:
EisenbergEffect commented on Aug 25
We are trying to lock things down within the next month. That doesn't
mean we won't add anything after that, but we need to work towards
stabilization, performance and solid documentation without
distractions of lots of new features for a little bit.
Primarily, "isomorphism" isn't a use case we want to tackle for the
initial v1 release. Again, that doesn't mean we won't do it later.
But, we want to have a solid framework for browser-based apps as well
as phone gap and electron/nwjs desktop apps first. That was our
original goal and we want to make sure we handle those scenarios
better than any other framework or library.
After that, we've got some other features we want to do, which are
valuable in their own right, but will also take us closer to
isomorphism.
Enable all aurelia libraries to run on the server. This enables some
new testing scenarios, so it's valuable if only from that perspective.
Once code can run on the server, we can then implement server view
compilation. This isn't isomorphic rendering, but rather the ability
to run Aurelia's view compiler as part of your build and bundle
process. This enables more work to be done ahead of time, as part of
your build, and then it doesn't need to be done in the browser at
runtime. So, this will improve the startup time for all apps and
reduce initial render times for all components. It also will make it
possible to store compiled views in browser local cache to improve
performance of successive runs of the application.
After both of those
things are in place, then we can look at doing a full server render
for each route. This isn't quite isomorphic in the truest sense, but
it solves the SEO problem without needing 3rd party libraries. So,
it's nice to have a solution there.
Finally, we can then "sync" a
server pre-rendered app with a stateful Aurelia app running in
browser, giving us 100% isomorphic support. So, those are the stages.
The first two would be beneficial to all developers, even those who
are not interested in isomorphic apps. The 3rd stage can be done today
with 3rd party libraries, so this is a nice to have for us, for those
who don't want an extra dependency. All of that leads into 4 which
adds the final pieces.
We have already begun some of the work on 1. That might get into our
first release. We aren't going to push it, but it's already in
progress and we're looking for the problem areas so we can make it
work. Steps 2-4 involve significant work. Really, we are talking about
a collection of features here, each one being rather complex. So,
those will probably come in stages after v1, as point releases.
We really don't want to do what Angular 2 has done. They have
massively complicated their architecture...to the point that very few
people will be able to understand it and developing applications with
it has become much more complicated, with many nuances. We really
don't want that, so we're focusing on the developer experience we want
first, then we'll come back and see about isomorphic support (yes, we
already have ideas how to do this cleanly, but want to give those
ideas some time to mature). In all of this, our goal is to be modular.
So, if you don't care about isomorphism, you don't have to think or
worry about it. If you do, you would install the necessary packages,
agree to the "constraints" of the system and be on your way.
So, to all who are interested in this topic, I would just ask you
kindly to be patient. For those who aren't interested in isomorphism,
don't worry, we aren't going to brake the developer experience on you.
For those of you who want it badly, you will have to wait longer and
it will come in stages and in modular pieces so as not to disrupt
others.
Just for now
The only way I can propose: render pages with phantomjs + use redis to speedup that process.
But you will have lots of trouble restoring the state at client side.
.......
Dirty solution
Load rendered page from server and at the client side render new one in the usual way, than switch UI's.
It won't be a truly isomorphic, but something like https://github.com/rails/turbolinks on first page load.
.....
I hope soon Aurelia team will provide simpler stuff for that case.
In the current Aurelia there is the possibility to enhance existing html.
The document says
So far you've seen Aurelia replacing a portion of the DOM with a root component. However, that's not the only way to render with Aurelia. Aurelia can also progressively enhance existing HTML.
Check out enhancement section # http://aurelia.io/docs.html#/aurelia/framework/1.0.0-beta.1.0.8/doc/article/app-configuration-and-startup
I'm looking forward to get a better documentation of this feature.
It seems to me like rendering the html on the Server and inject aurelia will work with it and google will like it as well.
a hack i just came up with is to put a static copy of the initial rendering into the index.html file:
<html>
<body aurelia-app="main">
<h1>static copy of the website here</h1>
<script src="scripts/vendor-bundle.js" data-main="aurelia-bootstrapper"></script>
</body>
</html>
this is of course completely manual and if the initial rendering contains any content from a database then the static copy may need to be updated
every time the database content changes. (which is of course what isomorphic rendering is supposed to solve)
however for my needs, which is a simple website with some information that is rarely updated, this solution is good enough. it will at least suffice until i am able to implement proper isomorphic rendering.
I am building a massive real-time collaboration web application. It is a Web IDE that has support for HTML, CSS & JS programming and a stage area that would reflect the results a la JSFiddle, Plunker etc.
Now, the twist is that, it would support multi-user real-time collaboration, where people viewing the same instance of the web application would be able to write code together that would reflect across all the open instances. I have figured out the race conditions, session management et al
What I am having trouble with is
how to reflect the typing and/or deleting along with caret positioning
across these multiple instances giving the illusion that when one
person is typing, he is actually typing on all the instances.
The other thing is that RactiveJS says that it
updates only those parts of the page that are out of date. Tedious DOM
manipulation is a thing of the past.
Which is a very nice effect in their Demo. Imagine, you are on JSFiddle and you don't have to re-run every time. So, my question is, how do they do it? What is the concept behind it?
I don't want to use any library for this. I am pretty good in JS. I am having a hard time figuring out the algorithm.
Things I have considered:
Dirty Checking [but, its dirty right?]
Delta Differencing [but like ReactJS, it would have to update the entire application state every time]
Object.observe [the browser compatibility is not realistic yet]
So, if you have anything that can help me go in the right direction, I would be really thankful.
Realtime-collaboration tools, that allow concurrent editing/manipulation of objects/texts etc, usually use a variant of the Operational Transformation algorithm.
OT is not trivial to understand, much rather implement so I'd suggest you take a look at already-cooked libs for this such as:
ShareJS
Racer for Node
OT works, in some very basic way, similar to GIT
As an update to what you posted in the comments.
You say you are using Python. You wouldn't rebuild your whole codebase, I guess, but keep in mind that real-time collaboration tools usually benefit a lot from using an event-driven server-side language.
Since you are using Python, you could check out the Twisted Framework
I've been asked at work to convert a popular mechanical engineering excel application to a single page web application. It requires no database so my idea is to put everything on the clientside in javascript.
First version is gonna be pretty small but more complexity will be added further along. Canvas graphics is gonna be drawn in realtime as user changes input. So performance is important. My question is: Should I use a MVC framework such as Angular JS? Or is it better to stick with Jquery? If I should use a MVC, which one is best suited for this app?
Everyone at my company uses IE9 so I dont need any support for older browsers.
Angular bills itself specifically as a way to build CRUD apps - basically database front ends. The app you're describing doesn't sound like it's doing a ton of that, so Angular would probably be more trouble than it's worth.
jQuery is a helper library - it makes dealing with the DOM easier, but doesn't do a thing to provide overall structure to your application. jQuery is a "necessary but not sufficient" in my book - you're going to want it, but it's not enough on its own.
Personally, I'd lean more towards Backbone, specifically because it's so minimal - it gives you some useful data binding stuff and some hints on how to organize your app, then gets out of your way to let you build the abstraction you want. Based on the fact that you mentioned the original is in Excel, some sort of data binding / change notification system is going to be important. This way you can emulate the spreadsheet's "change a cell and the chart redraws" system that everyone's already used to.
In the end it's hard to say without more detail on the app in question, and what kind of calculations / how often they have to happen are. Figure out what your app architecture should be, find (or build) a library that helps implement that architecture. It might be MVCish, it might not.
Well jQuery will get very messy as complexity increases. Angular JS is an amazing library but there are also a myriad of different ones out there. Depending on the Mechanical Engineering principles you are working with using AJAX may prove to be more perform-ant, due to the lack luster power of some older browsers.
It really depends on the complexity of the calculations, but in terms of dealing with events and managin the structure I would suggest using Jquery as well as Angular on top of it. then make the decision about whether or not to move some functions to the server or not, based on performance.
I was recently hired at a startup as the front end developer. As our product is a user admin that will be used by financial organizations, we want the app to run as much like an application as possible. I have been tasked with finding the clientside framework.
After researching, I have chosen backbone.js. When I presented this choice today, I was asked some questions that I do not have the full answers for but thought you guys might.
Is backbone.js production ready?
Is it rock solid and is there any proof?
I will only be using models, views, and collections for this app. My question is, how confident can I be that backbone will not just randomly fail when dealing with models. Are there any official tests I might be able to look at? What are your experiences with backbone?
Is there any sort of support network in place for dealing with backbone related issues?
Answers to either of these questions as well as any insights you have that I could present to my boss would be most appreciated! I Really want to use backbone as I think its a perfect fit, but because its so new, I need to sell it.
Thanks in advance!
Is Backbone.js production ready?
Take a look at Backbone's example section. Some of its better known users include:
DocumentCloud themselves.
37signals for BaseCamp Mobile.
SoundCloud for their mobile site.
BitTorrent in a manner that is not immediately obvious from the description, but seemingly related to a beta product.
Is there a support network in place?
There is, of course, no guarantee that it will be supported by its authors indefinitely, but it has gained a lot of traction very quickly so I don't see it going anywhere soon. The authors recommend reporting issues on GitHub.
There is always Stack Overflow itself for support!
I too was looking for a front-end app framework a few months ago. Here's the list of requirements that we had and how Backbone.js responded to each of those:
1. Browser support (IE8+)
There is one caveat here: The backbone.history module makes use of hashchange event, which doesn't work in IE7 and below. There are ways to hack around this problem, so it's not a show stopper, but kind of an annoyance.
2. The ability to apply our own look and feel to UI elements
As backbone only enforces the MVC structure of your app (unlike frameworks like cappucino or sproutcore) this was a perfect fit for us.
3. Being able to hook up any other external JavaScript libraries
We were using jQuery already, and backbone supports it, so that was fine. However, it seems like backbone is trying to take a library agnostic approach (for instance you can use zepto.js instead of jQuery if you like).
4. Community Support
There is a lot of introductory material on backbone (like people posting tutorials on blogs). Unfortunately, when your APP get's complicated it turned out there were quite a few "architectural" parts we had to figure out by ourselves, there was no obvious way to do it. The DOCS are good, but not great.
I guess on of the pitfalls of opinionated frameworks (like rails), is that sometimes you get caught up in a "am I doing this right" feeling.
5. Real world examples
It's always convincing to see that someone else has actually done something "REAL" with backbone:
http://documentcloud.github.com/backbone/#examples
We ended up using Backbone, and it was overall a nice experience, and I will definetively be looking into it again for our next project.
Who is to say that something is production ready better than the product users?
I'm working with backbone.js on a relatively large project (livechat operator application, 13k+ lines, currently at early beta). I have more than three months of experience with backbone and in my opinion it's excellent. I haven't had any unpleasant surprises because of backbone. I can't imagine developing an app of this size without clean and well-structured code. With backbone you can achieve that easily.
There's also an excellent bonus when using backbone - underscore.js. You will use that a lot.
StackOverflow backbone.js tag is there for you!
Your company, being a startup, cannot be afraid of new things. You should adapt them and spread your experiences. Remember, that your product is also going to be new.
A little late to the game with this answer but I felt compelled to respond to the question "how confident can I be that backbone will not just randomly fail when dealing with models".
No code just randomly fails; code fails for a specific reason which can always be traced back to somewhere. Often code appears to randomly fail because it's so complex and obtuse you can't follow it. In the case of backbone.js, the source is small (1,500 lines FULLY documented) and REALLY well documented.
If you need to trace down what is breaking, it's a simple matter of diving into the source and seeing what is going on.
Anyhow, I hope you got to try it out at your job!
At Planbox We've been using Backbone JS in in production for over 6 months without any problems. I wrote a few posts about our experience here and here.
We even use Backbone JS for our mobile version along with jQuery.
Disclaimer & Long Winding Question Approaching
I know topics like this have been beaten to death here so suffice to say I'm not asking about which framework is better, I don't really care about opinions on the better framework. They all do pretty amazing things.
The Question
Given that I have an existing web application, made of mostly regular HTML+CSS (jQuery where needed), which is the optimal framework to integrate a few "rich" pages into typically a regular stream of HTML.
Reason
I am trying to bring our proven application into the realm of awesome desktop like UI but I want to do it one small piece, one screen at time. But for our users, support personel and especially me taking it slow is the only option.
Also, with our branding requirements having a framework that just takes over the viewport isn't an option, it has to play nice with other HTML on the screen.
Imagine the example being a rich user manager in an otherwise plain HTML+CSS environment.
Experience Thus Far
Dojo + Dijit
Pros: The new 1.5 widgets plus the claro theme is the cure for what ails us. Dojo seems to be able to use markup to create the UI which is very appealing and has a fair amount of widgets.
Cons: Holy bloated lib Batman! Dojo seems to be enormous and I have to learn a custom build system to get it to stop requesting 4,800 javascript files. This complex empire of Javascript makes me believe I won't be able to create much that isn't already there.
ExtJS
Pros: Amazing set of widgets, does everything we could possibly want. Seems quick, every version brings new improvements.
Cons: I'm not sure how to use this without the entire display being EXT. I'm still building a web site, so I would prefer something that could integrate into what we already have. Some pointers here would be great.
YUI
Pros: Well, it's Yahoo isn't it? AWS console is downright wicked. Plenty of support and a giant community.
Cons: Well, it's Yahoo isn't it? AWS console is the only wicked thing. Complex for someone who's used to jQuery.
Help Me
I am willing to accept experience, links to ways to solve problems I've outlined, new toolkits (even though I'm pretty sure I've seen most by now) or even just advice.
Regarding ExtJS, it's pretty easy to start it in an existing div with something like this:
Ext.onReady(function() {
App = new Ext.Panel({...})
App.render('div-id')
});
The App panel can then have it's own layout manager.
This might be useful if you're familiar with jQuery, but not yet familiar with YUI 3 syntax: http://www.jsrosettastone.com/
Each of the libs you listed is excellent. When embarking on a larger scale project, the quality of a lib's documentation, community, and commitment to support become more relevant.
With Dojo, keep in mind that outside of dojo base, it only ever loads what you tell it to. But yes, without a built layer, that means it could easily end up requesting 50 JS files at startup for a large application using a bunch of widgets.
There are several pages in the reference guide documenting the build script: http://www.dojotoolkit.org/reference-guide/build/index.html
Rebecca Murphey wrote a nice blog post outlining an example app and build profile that you might find illuminative: http://blog.rebeccamurphey.com/scaffolding-a-buildable-dojo-application
If you get stuck, there's likely to be people in the Dojo IRC channel that can help.
RE ExtJS: I'm not sure what your exact situation is, but keep in mind that if you're intending to use it in commercial non-open-source software, you need to pay for licenses: http://www.sencha.com/store/js/
I'm a little curious as to why you think the size / number of requests is specifically an issue with Dojo though. I haven't used the others, but I'd expect it to be somewhat of a potential concern with any of them.