|
Orrrr, just go ahead and make a crazy form using angularjs. Are you being paid for this? If not, go nuts, see what works, what doesn't and experience first hand why. At least you're not going the usual route of "guys I just learned to program but I think I want to make my own compiler/framework/operating system" (which is also a fine way of learning stuff the hard way).
|
#
¿
Dec 4, 2013 20:39
|
|
|
|
| # ¿ May 2, 2024 10:15 |
|
|
Eh - I do think complexity overhead really is one of those things that is somewhat hard to explain/internalize until it's caused you personal pain. Also, many forms actually hide quite a bit of irreducible complexity behind them - interdependent fields and validation rules and all that. It's not a bad candidate for a data-binding MVC-esque solution IMO.
|
|
#
¿
Dec 5, 2013 00:20
|
|
|
Pollyanna posted:Well, okay. Here's the implementation I was thinking of: There's a text field with the "upsetting event", then a list of smaller text fields with associated 0-100 numbers, then a table with three column and variable rows, and I'm imagining a button that lets you add more rows as you need them. Then there's a radio button 'do you feel better' prompt and then you can like hit submit or something to record your log to a database/JSON thingy. Having said all that stuff I said above, I do think that either way you are worrying far too much about picking the best sword to kill a mosquito with. Pick whatever looks cool (knockout is fine) and do it. What you want can be done in any framework or not using frameworks at all.
|
|
#
¿
Dec 5, 2013 01:57
|
|
|
Ok so having done ~5 month or so of full-time-ish angular.js, the love affair is over, and I don't think I shall be pushing to use it for anything any longer. The main scary thing is performance. Everyone knows it's is poo poo, but people keep saying "don't worry, it's Google, they'll fix it". I am not so sure. The problem is dirty checking - it is basically the worst way of doing this sort of thing, there is just no avoiding have to re-evaluate every single loving binding on your app whenever you hit $apply. Object.observe may or may not happen at some point, but that doesn't matter - they will still have to re-write the whole loving thing from scratch to use it and change the way the API works. It won't get you dependency tracking in computed bindings for example. I am also far form convinced Google is actually going to bother putting too many resources into this no matter how popular it gets as long as they aren't using it for any of their core money-makers (and they aren't - apparently it's used for an internal CRM tool and some really basic proof-of-concept UI work and that's it). It will never be used for gmail or docs in its current state and I really doubt you could ever make a business case for re-writing either of those into something new even under ideal circumstances, let alone into a framework that needs substantial reworking to even be able to handle the product that is working perfectly fine without it. Remember AppEngine? Google is quickly getting an (imo, entirely well earned) Microsoft-like reputation for simply loosing interest in poo poo without warning. Beyond that it's just a bunch of smaller things - like just how many really terrible bugs, inconsistent implementations and undocumented features you run into. Also how poorly thought-out a whole bunch of the core functionality is - like ngResource absolutely cannot handle nested resources (don't even try, you're going to have SUCH a bad time) and ngRoute cannot loving conceive of the idea that maybe you just want it to handle a subset of all possible URLs instead of absolutely everything you don't explicitly whitelist using target="_self". Also the way ngRepeat works is really aggravating because the way it does identity tracking a really weird way that is easy to gently caress up and having to manage all your state changes using in-place array state manipulation is a HUUUUUGE pain in the rear end and pretty much forces you to do every single thing involving collections the hardest way possible (yes i know about "track by", no it doesn't solve all these problems, and it introduces a few new ones). There are a lot of good ideas here - I still think any JS developer should give Angular a try to learn some new things and broaden your horizons a little. But don't try to actually build a huge single-page-app out of it, it's just not there yet, and may never get there. It's a bit like LISP and SmallTalk that way - a bunch of good ideas, completely unusable in the real world. Ember has the same scope as Angular and despite the much smaller eco-system has already worked out all these hosed-up little problems and overall does things much more sensibly. Or better yet just use something much smaller that solves templating and data-binding specifically and build your own frameworky bits on top of that as needed. Knockout is absolutely perfect for that - way smaller, way easier to understand and much more flexible.
|
|
#
¿
Mar 20, 2014 22:28
|
|
|
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
|
|
|
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
|
|
|
Use a grid component of your choice? It is indeed a common thing.
|
|
#
¿
Apr 3, 2014 20:34
|
|
|
|
| # ¿ May 2, 2024 10:15 |
|
|
Kobayashi posted:Now I think I should just go back to something like Node-SQLite. But, what gives me pause is how much more difficult the syntax seems to be. Instead of an API, it looks like I basically construct query strings and pass them to the DB. It seems like I'm missing something, because it looks my choices are either 1) a nice, easy-to-use Javascript API, but a database that doesn't really deal with relationships or 2) lots of string manipulation. So I guess my question is, am I misinterpreting how relationships are modeled on the NeDB side? Alternatively, am I missing the API layer for the SQL side? Or perhaps I just need to harden the gently caress up? Those query strings you speak of are the SQL language, and for better or for worse pretty much all relational databases work with some flavor of it. Although the syntax might not be very pretty and often counter-intuitive, the core structure of it (conditions, joins, selects etc) is more or less just relational algebra which, barring some unfathomable advance in theoretical mathematics, is the be-all end-all model of working with relational data, period. Point being: it may look weird, but it's actually the best way of doing those sort of things. But anyway, you don't need to worry bout any of that - as you suspect, you are indeed missing an API layer here, usually you don't have to work with SQL strings directly (and there are in fact good reasons you should actively avoid it) - the thing you are missing is an ORM library. I don't have any specific experience with node ORMs but it looks like there's no shortage of them. You'll be able to just work with JS objects. The SQL strings are still going to be there, and it's good to remain peripherally aware of that fact, but for the most part it will just be magic "put object into database" -> "get object form database" and most will let you set up relations and stuff without getting too bogged down with joins and stuff, at least for the trivial case. I know this is just for prototyping and whatnot but I really thinking picking up some SQL basics is going to serve you well over the very long term, even if you never ever write production database code. It's not really that complicated a model but it's extremely powerful and widely used, it's going to help you make sense of a lot of stuff.
|
|
#
¿
Apr 16, 2014 18:55
|
|