|
fletcher posted:Very interesting perspective Mr. Wynand, just wanted to say thanks for sharing your experience! Yeah. To be honest that post is me about 2 months ago. We changed core functionality to React js and have not looked back since. We pulled page loads down from 35seconds in large data sets, down to 3 seconds, and ended up being able to easily augment components to start reusing DOM elements in an infinite scrolling setup, for even greater mobile efficiency gains. I feel the same way about Google's support of open source as well. They lose interest rather than admit defeat, and they're not resolving core issues. Our container is still angular at present, but the hard work is done by react, and that balance is only going to shift further away from Angular as time goes on. As an aside, I've been doing some pure react work lately and really enjoying it. Couple it with some extra modules like director for page routing, and precompiled jade templates and you end up with this super maintainable structure that runs like lightning. Never going back to angular that's for sure. Its full of quick wins but hits it's limits far too early to maintain viability, and that's probably one of the key issues. Back end frameworks that are slow, like Django and Ruby, can at least be scaled by throwing hardware at the problem, at least to a point. You don't have that option on the client side, especially if you're involving mobile, so the only sustainable option is something that's fast by default.
|
# ? Mar 21, 2014 05:04 |
|
|
# ? May 7, 2024 00:23 |
|
Cross-posting this from the general webdev thread, since Nebulon Gate pointed me here: I have a webapp that I want to design that's mostly just frontend stuff, with a bit of backend to store the relevant data (I wrote it in Flask). Considering that the JavaScript/templating logic is going to be fairly heavy, I'd like something that makes it as painless as possible; i.e., something with some kind of module system and some reasonable way of writing templates, as well as some workflow for writing CSS in a more reasonable language like SASS. What are my options? One thing I guess I could do is use Yeoman or one of those other frameworks and keep that in a separate folder from the backend; then, when I want to actually deploy it, run `grunt build` and just shove the backend and dist folder up on Heroku. It's really frustrating that none of the examples I ever see for stuff like this have an actual *backend*, only localStorage or whatever;
|
# ? Mar 21, 2014 05:48 |
|
I have to second the love for Knockout. I've been using ever since it got first released, wrote the mapping plugin (sadly not too much time to maintain it nowadays) and have been happily using it ever since. For some reason it was never considered to be as 'sexy' as Angular or Ember, but it's really well thought-out and really fast. Certainly the performance tuning has some caveats (i.e. it's still faster to render a huge grid just by concatenating strings instead of doing it using nested templates) but it's amazing for what it is. But what I especially like about it, is that it works on any reasonably recent browser. This includes IE7 and 8. Those browsers suck terribly, but it's much better than what Angular is doing. Especially the whole Angular 2.0 thing where they're going 1) mobile-first and 2) dropping support for anything below IE11.
|
# ? Mar 21, 2014 14:14 |
|
Sagacity posted:(i.e. it's still faster to render a huge grid just by concatenating strings instead of doing it using nested templates) I would expect that to generally be the case, really. At the end of the day you have to get the browser to create a bunch of nodes and insert them in the tree, and the parser is pretty much the fastest way to do that in a modern browser. Anything on top of that is extra work to be done, ideally in exchange for some better ergonomics. (innerHTML is generally faster than DOM calls, too.) String concatenation is O(1) on all remotely modern JS engines, so it's going to be really hard to beat. It also helps that innerHTML and friends have been optimized to hell and back because of how widely they're used, to the point of browsers reaching a gentlemen's agreement to all violate the standard in a certain way and avoid node allocation in one common circumstance. Sometimes frameworks can, through those ergonomics, make optimizations feasible that weren't before, like React's diffing, but for initial subtree creation I have trouble imagining a way to beat the parser. Maluco Marinero posted:Yeah. To be honest that post is me about 2 months ago. We changed core functionality to React js and have not looked back since. We pulled page loads down from 35seconds in large data sets, down to 3 seconds, and ended up being able to easily augment components to start reusing DOM elements in an infinite scrolling setup, for even greater mobile efficiency gains. I shared this with the React team, and they were very smile. It's exactly the experience they want developers to have (though they don't care very much about competition with Angular or other frameworks), and it's great to hear you're enjoying it. quote:Back end frameworks that are slow, like Django and Ruby, can at least be scaled by throwing hardware at the problem, at least to a point. You don't have that option on the client side, especially if you're involving mobile, so the only sustainable option is something that's fast by default. Twitter and Instagram and probably other sites throw hardware at some of these problems by doing rendering on the server side in some cases like initial load, because latency tends to be a bigger issue than the bandwidth loss from sending more verbosely encoded data. Twitter has a bunch of mustache libraries for this (Hogan!), and Instagram uses React that way IIRC.
|
# ? Mar 21, 2014 16:24 |
|
Sagacity posted:I have to second the love for Knockout. I've been using ever since it got first released, wrote the mapping plugin (sadly not too much time to maintain it nowadays) and have been happily using it ever since. For some reason it was never considered to be as 'sexy' as Angular or Ember, but it's really well thought-out and really fast. Certainly the performance tuning has some caveats (i.e. it's still faster to render a huge grid just by concatenating strings instead of doing it using nested templates) but it's amazing for what it is. I liked Knockout, but I never managed to get every data-bound input field in my old app to correctly change into text on unfocus. It either didn't work or made getting data a huge pain. ...Incidentally, I'm thinking about another approach. Is it possible to disable the input box "border" on an unfocused input box, such that it looks like the input is text before you click on it, or is there a better way to do what I'm describing?
|
# ? Mar 21, 2014 17:00 |
|
Maluco Marinero posted:Back end frameworks that are slow, like Django and Ruby, can at least be scaled by throwing hardware at the problem, at least to a point. You don't have that option on the client side, especially if you're involving mobile, so the only sustainable option is something that's fast by default.
|
# ? Mar 21, 2014 17:05 |
|
Pollyanna posted:...Incidentally, I'm thinking about another approach. Is it possible to disable the input box "border" on an unfocused input box, such that it looks like the input is text before you click on it, or is there a better way to do what I'm describing? Like this, right? http://www.appelsiini.net/projects/jeditable/default.html
|
# ? Mar 21, 2014 17:53 |
|
That's what I tried to do in Knockout, but it wouldn't work for more than one input. I tried adding flags to the VM data to keep its focused/unfocused state, but that made storing and retrieving the data a huge pain in the rear end.
|
# ? Mar 21, 2014 18:50 |
|
Sooo I'm trying to write jasmine unit tests for our big angular web app (which was not designed with unit testing in mind) and there's something funny happening. We have a checkValue() function that basically checks if a field is blank/invalid and if not, returns that value. The strange thing is, the logic (which was not written by me) seems to be checking for an array. But the <select> directive we are using only makes the value an array if you change it in the view, as far as I can tell. When I'm running jasmine tests I can't seem to replicate this effect (since I am not affecting the value from the view but just manually reassigning values from the unit test), so the tests always crash when the checkValue() function tries to run .join() on the value. Basically I am at a loss of how to make our app think we changed the value from the view and not manually from inside the test, I guess. Sorry if this makes no sense-- I'm a scrubby intern just learning the ropes with little/no supervision edit: To make matters worse, I'm not sure if the <select> directive is angular native or a custom one written by us
|
# ? Mar 25, 2014 17:20 |
|
Is there any kind of super-light, file-based database I can use with something like Node? I ask because I do a lot of prototyping. I deploy to a lot of different environments that I do not control. Anything that reduces the number of dependencies I need makes my life so much easier. I don't care about performance, scalability, or even data integrity, really. I just need something that looks vaguely like a DB that I can use for prototypes.
|
# ? Mar 27, 2014 00:12 |
|
SQLite?
|
# ? Mar 27, 2014 00:20 |
|
Kobayashi posted:Is there any kind of super-light, file-based database I can use with something like Node? I ask because I do a lot of prototyping. I deploy to a lot of different environments that I do not control. Anything that reduces the number of dependencies I need makes my life so much easier. I don't care about performance, scalability, or even data integrity, really. I just need something that looks vaguely like a DB that I can use for prototypes. How vague? If you just need a key value store a hashtable of json objects works great . . .
|
# ? Mar 27, 2014 00:46 |
|
MongoDB would be my suggestion.
|
# ? Mar 27, 2014 00:48 |
|
MrDoDo posted:SQLite? Yeah, if you can't get away with just serializing objects as JSON, sqlite is the go-to choice these days. If you don't need the relational stuff, leveldb is pretty straightforward and pleasingly fast.
|
# ? Mar 27, 2014 01:47 |
|
For god's sake just use sqlite before jumping into mongodb. In real life, most things have meaningful relationships to eachother, and 99 times out of 100 a relational database is a much better model for that than a document store or an object graph. This whole kneejerk nosql movement drives me batty to no end. Sure it has its applications and many things can be used for some fine optimizations, but I don't hold with breaking it out for no specific reason.
|
# ? Mar 27, 2014 02:02 |
|
an skeleton posted:Sooo I'm trying to write jasmine unit tests for our big angular web app (which was not designed with unit testing in mind) and there's something funny happening. We have a checkValue() function that basically checks if a field is blank/invalid and if not, returns that value. The strange thing is, the logic (which was not written by me) seems to be checking for an array. But the <select> directive we are using only makes the value an array if you change it in the view, as far as I can tell. When I'm running jasmine tests I can't seem to replicate this effect (since I am not affecting the value from the view but just manually reassigning values from the unit test), so the tests always crash when the checkValue() function tries to run .join() on the value. Basically I am at a loss of how to make our app think we changed the value from the view and not manually from inside the test, I guess. If I were you I would seriously be working on just getting some high level black box testing going. If you have large app like you are describing adding unit tests like this is going to drive you crazy, as you might already be experiencing. Not to completely detract from your original question but I see you continually running in to these types of things on the road that you are on.
|
# ? Mar 27, 2014 02:18 |
|
Mr. Wynand posted:For god's sake just use sqlite before jumping into mongodb. In real life, most things have meaningful relationships to eachother, and 99 times out of 100 a relational database is a much better model for that than a document store or an object graph. This whole kneejerk nosql movement drives me batty to no end. Sure it has its applications and many things can be used for some fine optimizations, but I don't hold with breaking it out for no specific reason. Not only that, mongo is a broken garbage NoSQL, and slower than Postgres to boot.
|
# ? Mar 27, 2014 13:26 |
I'm hearing a lot of good things about Knockout and their approach to documentation and the community seems pretty impressive, as well as the product itself being a no-fuss, common sense sort of affair. I'm learning Laravel now and I'm finding that, apart from the woeful lack of proper documentation (I just recently found the API which looks to be a lot better a resource than their website), that also has quite a low learning curve without limiting or dumbing down the final product. Is knockout the same? I'm not going to run into any weird glitches or hacked-together workarounds for pretty common use cases because of a weird design philosophy, or spend 4 months learning it and then find out that I'd have been better off spending 5 months and learning a more powerful framework? I'm primarily looking for just a simple and elegant way to manage javascript elements and input that lets me focus on the more important non-front end logic. I don't need my javascript to do anything terribly fancy, it just needs to be clean and simple and extensible for when I add functionality/complexity later. So far everything I've seen points towards it being perfect at that, especially in terms of not having to go back and re-write everything each change or expansion.
|
|
# ? Mar 27, 2014 16:09 |
|
Personally I loving hate knockout, but that's because it's full of pseudo-anti-patterns (like obtrusive unobtrusive javascript*) and is a pain in the rear end to figure out if you weren't the one to write the app in the first place. Angular is a bit sexier, but I still don't like writing method calls directly into markup. 15 years worth of web development experience just screams that it's a bad idea. I've been using Backbone with Marionette, requireJS, and plugins as necessary, and I like it a lot other than its total lack of model binding, though Backbone.Stickit is a decent plugin for that.Ender.uNF posted:No. We already replaced the Win32 client with a web one, it just has much worse performance than it should because everything does post backs on WebForms, or uses massive callbacks containing the world (that has to run the entire page's post back logic anyway). I managed to get WebForms and MVC to interop and our new features are using MVC, so performance wise we are in much better shape, but my grand plan to make the UI clean and more maintainable was promptly turned into spaghetti code once everyone else was let loose on it. Honestly whenever I find myself in a position like this, I see what I can convert over to an events-driven pattern. Being able to trigger custom events with data payloads (or just embedding data into elements with jQuery and then retrieving it via $(event.target)) makes decoupling components a LOT easier than trying to define interfaces and getting everyone to implement them properly. Backbone.Wreqr's request-response pattern also comes in incredibly handy - you can trigger an event that requests a resource, and have an event subscriber actually return a variable directly to the requesting code. For example, in the project I'm working on, we have a "Master" model with several sub-models, each of which is a subset of the master. If we ever need to get a reference to the master from code that wouldn't normally have it, we just use the Event Aggregator (which we've modified to also include request-response behavior) to trigger a request for the master model, and the master model itself responds with a reference to itself. That means getting a reference to an object that's in a completely different context/scope/whatever is as easy as doing this: JavaScript code:
Dangerllama posted:^^ For the next two hours, Manning has all their JS books at 50% off, including AngularJS in Action. I've been pretty happy with ng-Book for learning the fundamentals of Angular. isochronous fucked around with this message at 22:54 on Mar 27, 2014 |
# ? Mar 27, 2014 22:42 |
|
I'm no where near qualified enough to dole out hardened recommendations, but I really like Ember. Their approach to the router, and data bindings, and the forthcoming Ember Data just works for me. I also like Handlebars. It has a huuugggge learning curve though.
|
# ? Mar 28, 2014 05:23 |
|
As far as templating systems go, my team has been very happy with Dust templates (the linkedin fork), though those have a pretty steep learning curve as well. Dust-linkedin provides (of course) basic token replacement, but also advanced features like loop index tokens, setting custom contexts, template helper methods, conditionals (if, eq [equal], ne [not equal], lt, gt, etc), parameterized partial views, enum support for select elements, token preprocessors, and a lot more that I'm sure I'm forgetting. They've got a basic tutorial, but I still had to play around with the syntax a good bit myself before I got comfortable with it.
|
# ? Mar 28, 2014 18:03 |
|
Having done Angular and other JS MV* apps for the past year+ I'm now starting on a large Adobe AEM (used to be CQ) run static content site and it just seems totally loving backward to me. Even if your site is almost totally static and doesn't have much in the way of interactive crap the requirements of a large modern corporate site (this is a mid size insurance company's .com) are still very app-like and it just seems like a weird 1998 throwback to be putting together JSP templates and editing properties and all this nonsense. I get that not everything has to be an SPA and things are cached and all that but you can't tell me it's not a significantly better experience to only be loading what you need per "page" rather than a doing a whole new get and re-rendering everything just for a few dinky paragraphs, especially on a super lovely cell data connection where even the initial page call could just timeout. At least with an SPA if you change you're mind while it's taking forever to load you can click/tap some other link or whatever. I don't get why this poo poo is so popular still. Also even though I've only just done some tutorials I already hate AEM/CQ pretty solidly. poo poo failing completely silently because you forgot a preceding slash in a node property somewhere? YAY.
|
# ? Mar 29, 2014 02:19 |
|
Cocoa Crispies posted:Not only that, mongo is a broken garbage NoSQL, and slower than Postgres to boot. So what's a good ORM or some kind of library to make the mapping between tabular data and ~magical objects~ easier? The reason Mongo is so easy to plug in is you literally just feed it JSON objects and it barfs JSON objects back, no translation required. Also, what's the thread consensus on React.js? I kind of like it because it's basically like writing Razor syntax from C#-land (which is where I started coding).
|
# ? Mar 29, 2014 08:27 |
|
Urit posted:So what's a good ORM or some kind of library to make the mapping between tabular data and ~magical objects~ easier? The reason Mongo is so easy to plug in is you literally just feed it JSON objects and it barfs JSON objects back, no translation required. I've been telling everyone who'll listen that it rocks. Fast and sensible model with well written documentation, that makes it really easy to reason about the state of your application.
|
# ? Mar 29, 2014 08:42 |
|
Since Maluco Marinero convinced me to try out React.js a few days ago I was looking into React.js support in my favorite IDE, PyCharm. I noticed that WebStorm (of which PyCharm is mostly a superset of) has a new update with greatly improved AngularJS support. https://www.youtube.com/watch?v=rlNmYgNdOkM In particular I'm really liking the AngularJS refactoring and autocomplete support. Just thought I'd throw this out there. (In case you're wondering, WebStorm doesn't yet have React.js support, but it's coming.)
|
# ? Mar 29, 2014 16:49 |
|
Thanks to all the React noise in this thread I spent Friday figuring it out and implementing it in a new webapp project. It seems really neat so far and I'm excited to see what kind of speed improvements it can bring to some of my other apps.
|
# ? Mar 29, 2014 18:15 |
|
Chenghiz posted:Thanks to all the React noise in this thread I spent Friday figuring it out and implementing it in a new webapp project. It seems really neat so far and I'm excited to see what kind of speed improvements it can bring to some of my other apps. One warning that I've found with it - I'm obviously somewhat a novice with it myself, but from what I can tell, you want to make it re-render as late as possible AND you should put "key" properties on your collection members, because one of its coolest features is that it's doing a diff re-render and batches the DOM updates. This means the more of them there are, the faster it is, relatively, and if you have a key property it will not have to do a full scan of the collection members to determine which one to update - it can then just use a hash table for diffing, which is of course loads faster than a full scan. Otherwise, it's actually SLOWER than any of the other frameworks at large data changes. Also, anyone have a good VIM HTML plugin? I can't seem to find one that indents properly. In other news, I may have hit peak hipster - this just arrived at my house - a brand new Dell Sputnik.
|
# ? Mar 29, 2014 18:30 |
|
Urit posted:So what's a good ORM or some kind of library to make the mapping between tabular data and ~magical objects~ easier? The reason Mongo is so easy to plug in is you literally just feed it JSON objects and it barfs JSON objects back, no translation required. What else are you running on the backend? I mostly use Rails, and as such I use ActiveRecord as an ORM with Postgres.
|
# ? Mar 29, 2014 22:32 |
|
Cocoa Crispies posted:What else are you running on the backend? I mostly use Rails, and as such I use ActiveRecord as an ORM with Postgres. Oh, sorry - Node.js is what I'm currently playing with. I know about ActiveRecord, but I wasn't using Ruby. If I was using C# I'd probably use EF or just straight Linq, but Node is where there seems to be hilariously little support for relational databases.
|
# ? Mar 30, 2014 03:30 |
|
So am I stupid for not trying out Node and all the weird poo poo that goes with it? At my current (new) job I'm basically doing all javaScript all the time and I'm wondering if it's worthwhile to learn / mess with it. I see the OP mentions Grunt, would that be a good first thing to try out with Node? Node just seems weird to me. Also is there a consensus on Kendo around here? Previous projects used KnockOut but for the one I'm working on they've decided to go with Kendo.
|
# ? Mar 31, 2014 03:05 |
|
Grunt doesn't really have anything to do with programming with node.js. It happens to use node, but unless you're modifying Grunt itself that's mostly irrelevant.
|
# ? Mar 31, 2014 04:00 |
|
Tres Burritos posted:So am I stupid for not trying out Node and all the weird poo poo that goes with it? At my current (new) job I'm basically doing all javaScript all the time and I'm wondering if it's worthwhile to learn / mess with it. I see the OP mentions Grunt, would that be a good first thing to try out with Node? Personally I don't think it makes sense to make a decision to use Node to be based off what you use for a frontend framework. I'm assuming you're talking about using Node for backend? I spend a lot of my time working with Javascript frontends but the browser does the bootstrapping so I have no choice but to use JS. With that, I prefer .Net for non-web clients and backends so therefore I use C#/.Net, by the time the JS frontend is talking to whatever backend you have, it's really only going to be about serializing/deserializing & mapping your data structures. I've heard people tout that with Node they can reuse their data structure objects between client and server which just sounds crazy to me. Kendo is alright, I like Telerik, but Kendo and Knockout aren't mutually exclusive. Kendo is just a set of web front end libraries, mostly UI controls and other such helpers. Knockout comes with Observable/subscribable values/arrays and a declarative html data binding syntax to bind DOM nodes to Javascript objects. I don't think Kendo does any of that? Though I know it has some layout manager stuff ..
|
# ? Mar 31, 2014 04:16 |
|
ShaunO posted:Kendo is alright, I like Telerik, but Kendo and Knockout aren't mutually exclusive. Nah, Kendo does that. That's pretty much all I've been using it for. The only Kendo widget I've used so far is their date picker. ShaunO posted:Personally I don't think it makes sense to make a decision to use Node to be based off what you use for a frontend framework. I'm assuming you're talking about using Node for backend? I was just talking about dicking around with Node in general. It seems really weird to me to write server side code with JS is all.
|
# ? Mar 31, 2014 07:48 |
|
How do people feel about Dart? I've tried JS in the past and absolutely hated it. Dart + Polymer let me create a ridiculously nice website sending JSON objects to the backend with pretty much no hassle at all, and I feel as though it will be very easy to expand when the time comes.
|
# ? Mar 31, 2014 10:42 |
|
Womens Jeans posted:How do people feel about Dart? I've tried JS in the past and absolutely hated it. Dart + Polymer let me create a ridiculously nice website sending JSON objects to the backend with pretty much no hassle at all, and I feel as though it will be very easy to expand when the time comes. Dart is pretty much JS for people coming from non-web background. Polymer is basically the webdev future available today. As long as you're not trying to force down Dart onto someone, I see no reasons why you should refrain from using it.
|
# ? Mar 31, 2014 23:15 |
If I start playing with Dart + Polymer, does anyone think it's likely to be a completely wasted skill down the line, with nobody ever using it?
|
|
# ? Mar 31, 2014 23:40 |
|
Womens Jeans posted:How do people feel about Dart? I've tried JS in the past and absolutely hated it. Dart + Polymer let me create a ridiculously nice website sending JSON objects to the backend with pretty much no hassle at all, and I feel as though it will be very easy to expand when the time comes. Dart is interesting and although this is not a very hip opinion I think type checking is quite valuable (even if it isn't fancy inferred typing). The main problem with Dart is Google. Some crazy guy on HN maintains this insanely complicated regression analysis that tries to predict how long until Google looses interest in any given project, based on usage, weather or not it's open source, does it make the money etc etc. He put the odds of Dart still being around 5 years from now at around 20% and I can't say that seems at all unreasonable. Polymer and Web Components is sort of cool but just doesn't provide any real benefits over a more pragmatic and tried framework. Like all W3C projects it is only useful once people build around it, and on its own is merely a very complicated spec with lots of dubious design choices. By all means, play around, but I wouldn't seriously pursue it, let alone start a real project with either.
|
# ? Apr 1, 2014 01:26 |
|
isochronous posted:Personally I loving hate knockout, but that's because it's full of pseudo-anti-patterns (like obtrusive unobtrusive javascript*) and is a pain in the rear end to figure out if you weren't the one to write the app in the first place. Angular is a bit sexier, but I still don't like writing method calls directly into markup. 15 years worth of web development experience just screams that it's a bad idea. If you're doing a lot of wiring in your binding code you probably can (and certainly should) extract that to a component in either framework. Short of that though, I don't think it's that much of an anti-pattern - behaviour is still part of the meaning (semantics) of your elements. Semantic purism isn't a very useful sentiment since exactly nobody is actually making serious use of semantic data in HTML (short of microformats of course, but those will happily live in whatever tag-soup disaster you want), nor do I think this is likely to change any time soon. The semantic web just isn't going to happen for a long long time now if ever. Relax and just worry about immediate architecture and maintainability.
|
# ? Apr 1, 2014 01:32 |
Mr. Wynand posted:Some crazy guy on HN maintains this insanely complicated regression analysis that tries to predict how long until Google looses interest in any given project, based on usage, weather or not it's open source, does it make the money etc etc. That sounds pretty interesting, do you have a link to it?
|
|
# ? Apr 1, 2014 01:39 |
|
|
# ? May 7, 2024 00:23 |
|
fletcher posted:That sounds pretty interesting, do you have a link to it? http://www.gwern.net/Google%20shutdowns His entire site is fascinating analyses of things that I would never have thought would be interesting to analyze before reading them.
|
# ? Apr 1, 2014 01:45 |