|
Hello Friends! I think I might need one of these fancy bespoke frameworks for my summer-scarf! I am writing a web page 'app' that does the following: - Uses GET/POST ajax calls to a crossdomain server. - The user can alter the json objects retrieved from the server. - The user's altered json values are then 'saved' to the server, via ajax POST calls. - The new state of the server's json object is retrieved via ajax GET. - The web page UI is redrawn to reflect the server json object state. I have this all working, but I am doing this all manually. For example, when I get a json object array from the server, via ajax/GET callback, I iterate through the json array using a for-loop. I then use something that looks really gross like: code:
I discovered Backbone and Agility yesterday, which seemed like exactly what I needed! If I could 'bind' json objects to HTML templates, and easily sync the html UI with the server's state, that would be awesome! However, it appears that it is impossible to use Backbone, because the HTML5 'History' object will not use crossdomain URLs. Is there something else I can use? I am fine using my manually-written ajax POST/GET calls if I have to, but I would at least like to 'bind' json objects to html templates. If I could use something to 'sync' with the server state, that would be great too! :3 Questions: - Is there an Ember/Backbone-y thing that works across domains? - If not, is there a good html template-y thing that simply 'binds' json objects to html forms/elements? Edit: Knockout.js appears to do exactly what I want! Yay! Captain Pike fucked around with this message at 20:41 on Aug 20, 2014 |
# ? Aug 20, 2014 16:59 |
|
|
# ? Mar 28, 2024 21:22 |
|
Analytic Engine posted:Can someone please brutally rip apart my resume? I'm shooting for internships or entry-level work in web dev and data visualization in NYC. May want to try the newbie/get a job megathread. A lot of that stuff seems irrelevant to me to get a job as a developer. If I going to be interviewing developer candidates, I wouldn't really care that you worked as a convenience store clerk. I wouldn't really care about much of the rest of it either besides the "Web Developer and Designer, Freelance, Newcity, NY Jan ‘14 to Present". Consider adding a link to your github. If you don't have one then start one and get some small projects up on there. I remember another posted mentioned making a quick pastebin clone or something (maybe without syntax highlighting). I don't think it is necessarily a requirement, but I bet seeing some of your actual code would help get you to the interview stage.
|
# ? Aug 20, 2014 17:01 |
|
Knyteguy posted:May want to try the newbie/get a job megathread. Lose the clerk, but keep the other parts. Explaining technical stuff to non-technical people, jamming together tools to get the job done, teaching people -- those are all valuable skills and experience to show off. github for sure, though.
|
# ? Aug 20, 2014 17:03 |
|
I'm having trouble structuring an Ember application in Middleman. I have my directories set up like this:code:
code:
code:
code:
code:
Pollyanna fucked around with this message at 18:19 on Aug 20, 2014 |
# ? Aug 20, 2014 18:16 |
|
^ I don't know what Middleman is, but that doesn't look like any Ember app I've ever seen. I normally wouldn't chime in since this is not really my area of expertise, but Ember is really opinionated about how things get done (which is why I like it). If you're not going to do things "the Ember way," then you're going to run into poo poo like this at every turn. Right now, "the Ember way" seems be Ember CLI. As it stands, it looks like you're using a combination of standard Javascript (app.js), Coffeescript? (controllers.em), and whatever Emblem is. Any one of those could be breaking Ember's "convention over configuration" assumptions. Anyway, to answer your question, the Ember CLI documentation expects outlines where it expects to see things. Personally, I prefer pod structure. The Ember core team has indicated that pod structure is the future, but the tooling isn't as good yet. On an unrelated note, HTMLbars just landed in canary, so soon the world will be freed from the scourge of metamorph tags!
|
# ? Aug 20, 2014 18:32 |
|
Cross posting from the Screenshots thread... I made a JSON viewer in React: You can mess with it here: http://eskimospy.com/stuff/react/json/ and there's links to the source if anyone wants to use it and / or look over the code and tell me what incredibly stupid things I am doing since I'm still trying to figure out React for the most part.
|
# ? Aug 20, 2014 18:43 |
|
^^ Ooh, I like! I've considered using React for generating views 'n all, but I'm not sure how it'd interact with Ember. Maybe I should work on Backbone again for a while...Kobayashi posted:^ I don't know what Middleman is, but that doesn't look like any Ember app I've ever seen. I normally wouldn't chime in since this is not really my area of expertise, but Ember is really opinionated about how things get done (which is why I like it). If you're not going to do things "the Ember way," then you're going to run into poo poo like this at every turn. Right now, "the Ember way" seems be Ember CLI. As it stands, it looks like you're using a combination of standard Javascript (app.js), Coffeescript? (controllers.em), and whatever Emblem is. Any one of those could be breaking Ember's "convention over configuration" assumptions. .em is EmberScript, a CoffeeScript dialect that has first-class support for Ember objects, extensions, etc. It helps make it clear exactly what I'm doing and keeps me in the Ember "mindset". app.js is because I wanted to use Sprockets to include everything under the job-app-tracker scripts directory. Emblem is a templating library. I've used Ember CLI, but I'm not sure if it's meant to be used in conjunction with Middleman. The whole thing about Middleman is that it's basically "drop your stuff here, reference it when you need it", and the Ember CLI generates a whole bunch of crap like Bower packaging and also apparently it uses import foobar which I have never seen used like that outside of Python so I'm like what. It confuses the hell out of me, since it seems to expect me to use the tools it supplies for developing and deploying the application, which is not what I'm doing. If all it did was generate the directories and placeholder controllers.js/models.js and all, I'd be happy. Maybe I'll see if it can do that. I'm absolutely not doing it by convention at all simply by trying to work Ember into Middleman's structuring. There's no official support for Ember like there is with Rails, so I kinda have to work from the ground up. I'm tempted to port my site to Rails, though, cause of how much of a pain it is
|
# ? Aug 20, 2014 18:45 |
|
Knyteguy posted:Great stuff and tips on code hosting Subjunctive posted:More great stuff and a good github reminder At least one person responded well to my current version (along with my project) but they're not programming at the startup. Should I expect the majority of small companies to have developers screening resumes? I've heard big firms use HR and auto-scanning systems to handle the larger volume.
|
# ? Aug 22, 2014 03:37 |
|
Pollyanna posted:I'm absolutely not doing it by convention at all simply by trying to work Ember into Middleman's structuring. There's no official support for Ember like there is with Rails, so I kinda have to work from the ground up. I'm tempted to port my site to Rails, though, cause of how much of a pain it is There's no 'official' support for Rails either, you're just swapping one problem (issues caused by not following the conventions of opinionated framework a. and instead attempting to jam it into opinionated framework b.) for another one (issues caused by not following conventions of opinionated framework a. and instead attempting to jam it into opinionated framework c.); the ember-rails gem was last updated 3 months ago, ember-appkit is dead, &c &c &c. Middleman should make it easier to do what you want to do because it's an extremely simple application with fewer conventions to [learn how to safely] circumvent. What you're doing's more than possible and not particularly difficult (it.is.just.easier.to.keep.things.separated). You're just exacerbating your issues by trying to combine multiple other flavour-of-the-month technologies. Note that I don't know poo poo about Ember, and maybe there's some magic gem I couldn't find that glues Ember CLI functionality into Rails and scaffolds and builds your entire app to match [insert arbitrary tutorial]. poo poo, I like playing around with new stuff, but honestly
|
# ? Aug 22, 2014 18:04 |
|
Man I wish all these frameworks would take an immediate timeout in the documentation when they introduce some cute/non-obvious functionality. Examples being Ember's function prototype extensions for computed properties and observers (meaning stuff like getButt: function(){}.property('leftCheek', 'rightCheek')) and Angular's usage of function.toString() and then parsing the parameter names from the string representation for dependency injection. When I notice things like that, it's like an immediate needle scratch moment and I spend the next several minutes trying to find out what the hell is happening.
|
# ? Aug 27, 2014 12:12 |
|
Wheany posted:Man I wish all these frameworks would take an immediate timeout in the documentation when they introduce some cute/non-obvious functionality. Not sure if this is relevant since my Javascript isn't fundamentally that strong, but I was just reading over Ember's prototype extensions documentation. The computed property stuff is mentioned at the end. I'm not sure how long that page has been around though, and it would be nice if the page indicated when it was introduced, perhaps by version number, or if there was a feed for non-trivial documentation updates.
|
# ? Aug 27, 2014 14:28 |
|
What's the point of the push/pull classes in bootstrap? (I think) I understand what they do, but I can't imagine how I might end up with divs who A) aren't in the order that I want to present them, and B) I know in advance that this is the case, so you push/pull them in order to switch their order.
|
# ? Aug 29, 2014 19:50 |
|
I usually need push pull when I want to rearrange a row that is text block / image to flow to image / text block on extra small. Edit: though in code it's reversed because of mobile first and all that jazz.
|
# ? Aug 29, 2014 20:31 |
|
I wrote a very basic blog post about mixins in react: http://simblestudios.com/blog/development/react-mixins-by-example.html You can either hopefully learn something from it, laugh at my writing, or both!
|
# ? Aug 29, 2014 21:09 |
|
Lumpy posted:I wrote a very basic blog post about mixins in react: http://simblestudios.com/blog/development/react-mixins-by-example.html Nice post. I like mixins. I like them in other languages/frameworks too. One thing to note is that you should try to avoid getting too clever with your mixins. It gets hard to reason about the functionality if you get too many implementing the same method.
|
# ? Aug 29, 2014 22:39 |
|
The Dave posted:I usually need push pull when I want to rearrange a row that is text block / image to flow to image / text block on extra small. I think the most common use is navigation on the right for desktop, but at the top for mobile
|
# ? Aug 30, 2014 01:12 |
|
Oh, jeez. Push/pull applies when you want different orders on different view sizes. Thanks
|
# ? Aug 30, 2014 12:22 |
|
I hate AngularJS. Is it ok to say that here? Like really hate it.
|
# ? Aug 30, 2014 15:53 |
|
how come
|
# ? Aug 30, 2014 16:02 |
|
Lots of reasons I guess. I hate Javascript from the outset. I despise the dev environment i.e. node, bower, grunt, etc. I hate Typescript, I also hate people who don't use Typescript. I hate the lack of best practices, I hate the piss poor documentation, I hate that tests are so annoying to write.
|
# ? Aug 30, 2014 17:27 |
|
NtotheTC posted:Lots of reasons I guess. I hate Javascript from the outset. I despise the dev environment i.e. node, bower, grunt, etc. I hate Typescript, I also hate people who don't use Typescript. I hate the lack of best practices, I hate the piss poor documentation, I hate that tests are so annoying to write. Tell us how you really feel I feel the same, coming from something like C#, oh my......
|
# ? Aug 30, 2014 19:04 |
|
Mr Shiny Pants posted:Tell us how you really feel Even coming from Rails it's pretty brutal. I'm glad I don't have to work with it too much, just one lil guy that pulls data from an API that one of our client's Oracle team is building. Though, I am considering a play project in Ember to see if that is more sensible to me. A buddy said it's more Rails-ish in philosophy
|
# ? Aug 30, 2014 19:20 |
|
I'm working on a single-person/hobby Node+Ember app to up my "full stack" prototyping game, and am certainly not a "real" developer by any means, but I sometimes have to laugh at how much of a clusterfuck the tooling is. Between idiomatic Node and idiomatic Ember, I am using three package managers (NPM for Node, NPM again for Ember, Bower for Ember) and two task runners (Grunt for Node, Broccoli for Ember). The working directory for my little tinker app is over 300+ Mb... Beyond that, even though both the client and the server are nominally Javascript, their module loaders are different enough to trip me up whenever I switch from one (Ember and its resolver) to the other (Node's require system). Then there's the context switching between callback-based, event-based, and promise-based code styles (which I suppose is useful for people like me who are trying to get a better grasp on the fundamentals). Aaaand the fact that my project has more dotfiles/config files than my home directory.
|
# ? Aug 30, 2014 20:23 |
|
NtotheTC posted:I hate AngularJS. Is it ok to say that here? Like really hate it. Yes. AngularJS isn't that bad, but the documentation is lovely given how idiosyncratic it is in doing stuff, and the actual best practices for it aren't used much by the community(like 'controller as').
|
# ? Aug 31, 2014 07:41 |
|
I have nothing really to to say about this article but some of you might have a laugh/rage over it: http://codeofrob.com/entries/you-have-ruined-javascript.html
|
# ? Sep 1, 2014 17:18 |
|
Heskie posted:I have nothing really to to say about this article but some of you might have a laugh/rage over it: The arguments can be applied to any language and the abuse and misapplication of programming patterns. And it certainly isn't unique to enterprise level software.
|
# ? Sep 1, 2014 19:00 |
|
It's a good thing he is now writing things in Erlang because that's not enterprise yet (?)
|
# ? Sep 2, 2014 13:50 |
|
I have two input fields with date pickers. I need to validate them and verify that the date in the second input is greater than the one in the second input. I'm using Angular. Is there a standard approach for this that I've missed in my limited googling?
|
# ? Sep 2, 2014 13:59 |
|
Does anyone have any tips or ideas on how to implement a 'week picker' via a calendar. Essentially I want to have a user open the calendar widget, but it highlights the week (set Sun-Sat) for them instead of the day. I'm fine with output of something like the Sunday of that week picked or whatever. I'm more concerned with usability and visibility for the user.
|
# ? Sep 2, 2014 15:58 |
|
Ahz posted:Does anyone have any tips or ideas on how to implement a 'week picker' via a calendar. Essentially I want to have a user open the calendar widget, but it highlights the week (set Sun-Sat) for them instead of the day. I'm fine with output of something like the Sunday of that week picked or whatever. I'm more concerned with usability and visibility for the user. Well, here's the first google result for 'week picker' http://stackoverflow.com/a/6743049
|
# ? Sep 2, 2014 16:05 |
|
Maybe my google is different, because nothing in SO showed up on my initial week picker googles. But this might work, thanks!
|
# ? Sep 2, 2014 18:04 |
|
NtotheTC posted:Lots of reasons I guess. I hate Javascript from the outset. I despise the dev environment i.e. node, bower, grunt, etc. I hate Typescript, I also hate people who don't use Typescript. I hate the lack of best practices, I hate the piss poor documentation, I hate that tests are so annoying to write. You sound like me when I first started using Angular. Honestly - if you try to apply just about ANYTHING you learned in another language to Angular - it will be obtuse and annoying as poo poo. Until I finally embraced the "stop thinking in _________ and think IN Angular" concept, where ________ is whatever other language you know - which for me was basically any C-style language - I thought Angular was stupid and annoying as poo poo. Why? Why would anyone try to write a full MVC stack in Javascript? Javascript?!?? The language that pioneered the technique of giving you enough rope to hang yourself with, AND showing you how to tie the noose to boot? Once I finally worked through some tutorials and really let go of everything else I knew - I understood the power/flexibility of it. And now I love it. But yeah - if you don't think in Angular, it sucks. Even just off the top of my head - the ability to have an app up and running in minutes with writing almost ZERO boilerplate is amazing. Once you've used it long enough you wind up with little libraries of your own directives and things you can pull out as needed. It's awesome to be able to start a new app and before the end of the first day, you are writing the APP, and not still scaffolding or laying out architecture.
|
# ? Sep 2, 2014 18:37 |
|
HaB posted:You sound like me when I first started using Angular. This is why, even now that I'm comfortable with Angular, I don't really like it. I mean, it's OK, but it doesn't bring enough to the table to make me think the tradeoff of dealing with it's ... different ... nature is worth it.
|
# ? Sep 2, 2014 20:41 |
|
HaB posted:You sound like me when I first started using Angular. I think this nails why I'll never like Angular. Not because I can't make myself "unlearn" everything else, but because Angular demands I do so. When I can say "Oh, this is like ___ from ____, I get it!" in anything: a language, a framework, a game... I learn faster and can get to actually accomplishing things quicker, and that's the whole point of a framework. I imagine if my sole job was to write Angular, spending the time to think in it would be a good investment (possibly.) As someone who flits between languages and frameworks weekly, if not daily, "the Angular way" is overhead I can't afford.
|
# ? Sep 2, 2014 21:36 |
|
Yeah, definitely echo Lumpy and Thermopyle. I started out with Angular, and even built a bunch of things in it, I'm even working on a project where we're still using it as a sort of dependency injection wrapper, but I think there's a big problem with the Angular centric approach to doing everything. This would be fine if Angular scaled well to performance sensitive applications, but I've come to the conclusion that if you do so you're so far beyond writing things the Angular way that a more capable UI framework would get you the results you need. Guilty as charged as a major React fanboy on this thread, but there are some pretty compelling reasons for being so: - Javascript direct templating through React components is god drat powerful, and allows you to have a very concise, and non wasteful DOM - React is fast by default, and doesn't have a wasteful scope digest like Angular. This advantage can be smoothed over on strong desktop machines, but becomes extremely apparent the moment you get a weaker CPU on mobile. - React is a small library in terms of Public API considering what it does, and its documentation is well written and concise. You can pretty much learn everything there is to know about React - in a general sense - in a day. From there, you have a very strong abstraction that I have yet to break, even with some fairly optimised use cases with reuse of elements. - It's still JavaScript, good JavaScript devs just become better JavaScript devs with React, and the React itself is better suited to embedding in any project. Angular is not really JavaScript at the end of the day, it's a mishmash of templating and javascript code, forming a web of tangled concepts like services, controllers, directives, and filters. Now, while it is true that React can't do everything Angular can do (which is why it's still a dependency injection wrapper in one of our projects - also we don't want to slow down on the rewrite), the core problems with rendering Angular templates cannot be discarded without also discarding the majority of concepts, scope, directives, filters, controllers, all almost stripped bare. While big frameworks will always have a place, I think for serious app development they'll go the way of the dodo in favour of small libraries that do one thing well. I'll have more to say on this over time I imagine, (I'd love to write a book on this poo poo, dunno if anyone will listen but I'm kinda keen to put it to txt file), but I think that'll come after I've gotten deeper into some projects I have under way. Maluco Marinero fucked around with this message at 23:05 on Sep 2, 2014 |
# ? Sep 2, 2014 23:03 |
|
Thermopyle posted:This is why, even now that I'm comfortable with Angular, I don't really like it. I mean, it's OK, but it doesn't bring enough to the table to make me think the tradeoff of dealing with it's ... different ... nature is worth it. Lumpy posted:I think this nails why I'll never like Angular. Not because I can't make myself "unlearn" everything else, but because Angular demands I do so. When I can say "Oh, this is like ___ from ____, I get it!" in anything: a language, a framework, a game... I learn faster and can get to actually accomplishing things quicker, and that's the whole point of a framework. I imagine if my sole job was to write Angular, spending the time to think in it would be a good investment (possibly.) As someone who flits between languages and frameworks weekly, if not daily, "the Angular way" is overhead I can't afford. Maluco Marinero posted:Yeah, definitely echo Lumpy and Thermopyle. I started out with Angular, and even built a bunch of things in it, I'm even working on a project where we're still using it as a sort of dependency injection wrapper, but I think there's a big problem with the Angular centric approach to doing everything. I'm not disagreeing with any of you. For the length of the contract I am on, my job is pretty much exclusively Angular, which definitely gives me an advantage on project overhead. I've been allowed time to embrace "the Angular way" and that's been mostly fruitful. Plus I'm a big fan of the phrase "if all you have is a hammer, everything looks like a nail." Like most things, Angular is a tool. When it's the right tool - it's awesome, when it's not...well...you get the idea. All I was trying to say is - you can hammer nails with a screwdriver handle, but it's not the best way to utilize the screwdriver. Or the best way to hammer nails.
|
# ? Sep 3, 2014 12:37 |
|
HaB posted:you can hammer nails with a screwdriver handle, but it's not the best way to utilize the screwdriver. Or the best way to hammer nails. Hmm, this could explain why so many of my home improvement projects turn out the way they do.... And I agree with your assessment about Angular. It's a very specialized tool that requires a lot of "training" to use. I wish I had time to focus on one thing that long...
|
# ? Sep 3, 2014 16:03 |
|
So I've kind of poked my head in here a little bit before. I'm not a web developer, by any stretch of the imagination. And javascript is far removed from what I typically do day-to-day at my job. That said, I've been researching the various MV* frameworks because I am looking to build a desktop first node-webkit or atom-shell based application. I say "desktop first" because the initial plan is to get a standalone desktop application up and running but with the possibility of supporting a web deployed and in-browser build of the application far in the future. Really my focus is on a stand alone desktop app via node-webkit or atom-shell though. My head is kind of exploding with all of the different frameworks but I think I've narrowed my options down to either: 1. React 2. Knockout 3. Vue Unless I've missed discussion on it, I haven't seen anyone here mention Vue before and I was curious what people's thoughts on it were. It seems to incorporate some of the better ideas between Knockout and Angular. I'm hoping someone could give me some better direction. As in "you are writing a node-webkit based desktop app? Then use XYZ because it is meant to work best in that kind of environment". Personally I'm more drawn to something like Knockout or Vue because I have a C# background with WPF/XAML (which uses MVVM heavily). I'm leaning towards Vue just because it seems to be Knockout but better. But the immaturity is definitely unattractive, even if it is developed by a Google employee. Knockout on the other hand seems to have more history and a bit more proven, but I don't need IE6 or Blackberry levels of backwards compatibility and it leaves me wondering if its API suffers a bit because of it. Thanks for any thoughts.
|
# ? Sep 4, 2014 08:25 |
|
If you like the look of Vue go for it, you'll be learning anyway so you can't expect quality engineering from your first pass no matter how much you try to analyse and plan. Get runs on the board, you're working with HTML/CSS/JS and Vue looks pretty straightforward so jump on in. However, knockout will have more community resources available to learn from, even if the API is older and doesn't have as much magic, you will be able to get the job done. Another shop I've worked for in the past use Knockout to good effect and move pretty quickly with it, so I wouldn't say its a bad choice either. In the end of the day, at this stage you should optimise for months of your life because you don't know enough yet to optimise for anything else, with your project or with the frameworks. Vue is a bit unknown to me, and Google isn't exactly a tick of approval when it comes to libraries and APIs (they don't tend to document or support them particularly well), but all you're risking at this point is a bit of time where you were learning anyway. Pick one and start coding, don't delay.
|
# ? Sep 4, 2014 11:07 |
|
|
# ? Mar 28, 2024 21:22 |
|
I've been using angular and ngRoute to make very basic static sites. Basically my only logic is a list of routes like:code:
code:
Is there another JS framework that is good for this kind of thing? Maybe a little more lightweight? I want to try something other than angular. e: I guess backbone with LayoutManager? e2: actually ember looks a lil easier fuf fucked around with this message at 14:13 on Sep 4, 2014 |
# ? Sep 4, 2014 13:34 |