|
Mister Chief posted:Thank you. I'll switch over to that and report back. http://www.html5rocks.com/en/tutorials/speed/high-performance-animations/ The long story short with animations on mobile is if you want it to be smooth you absolutely must not trigger layout. Layout transitions require recalculation of every side effect in layout it triggers, for example the width of an element changing the available space for things around it, possibly reflowing text, divs, etc. If you want smart transitions you need to do it with CSS transformations + transitions to get the silky smooth change. The reason for this is the animation is conducted entirely at the graphics acceleration level, its just taking a 'layer' (the DOM element plus contents) - and applying a transformation to it. This means the browser can bypass a whole host of CSS recalculations inherent in transitioning width, height, etc. The article goes into more detail on this, and as an aside poo poo gets tricky with how translation also affects the positioning of fixed elements by resetting their constraints (never used position:fixed within a transformed element, basically)
|
#
¿
Jun 1, 2014 20:10
|
|
|
|
| # ¿ May 15, 2024 11:59 |
|
|
MrMoo posted:Try to work on a jsfiddle that highlights the problem the pastebins are not easy to understand. 60fps animation is difficult, read up on the guides on http://jankfree.org/ for more but it sounds like you have the fundamental 3d transforms in place it is other things that are breaking the performance. Use Chrome's developer tools to help diagnose performance problems, such as repaints and re-layouts. The tools change a little every release so it is an annoying moving target at times, plus docs are non-existent. Didn't know about that page, that's a great resource.
|
|
#
¿
Jun 1, 2014 22:54
|
|
|
Not exactly. If your classes are still affecting layout properties (which max-height is) you will still be triggering expensive layout calculations for every frame. You'll get silky smooth by not touching the height or width, and instead using css transforms to achieve the movement you are after. Now as for what that means for you, that entirely depends on the effect you're after, how the menu looks, what you expect the content to do, etc.
|
|
#
¿
Jun 2, 2014 11:06
|
|
|
Mister Chief posted:I basically want a menu like what bootstrap uses: http://getbootstrap.com/ Okay, so looking at it on mobile it looks to me like its just a height transition, which is why it drops a ton of frames on my Android phone. If you wanted to get that with transform, likely what you would do is have the content cover the menu and zindex above it, and then when you show the menu you simply transform: translateY(200px); or whatever is suitable. Key issues here would be how you handle the fixed element and scrolling (never said this would be easy)  You can potentially just have two elements here that fill the screen, the menu and the content, and have the content be overflow: auto. You'll be able to scroll inside and you can add this to get momentum scrolling ( http://css-tricks.com/snippets/css/momentum-scrolling-on-ios-overflow-elements/ )In a way this is preferable because of how bad position:fixed is on iOS (when the keyboard shows it cancels the position updating of fixed elements so you can scroll past them) Anyway that's my 3 minutes armchair dev opinion of how to do that implementation. If you only have the top menu as a 'fixed' element that should work.
|
|
#
¿
Jun 2, 2014 12:50
|
|
|
Android Firefox trusted it, Chrome did not.
|
|
#
¿
Jun 6, 2014 03:34
|
|
|
I think its pretty bad because it doesn't account for any cases where a user may have associations with more than one company within your system. Not knowing anything about your system, of course, but I think it would be wise to have a top level classifier, a slug of the company, either in the directory structure or as a sub domain to make context clear. Even if you're not intending to, what about admins who may be managing multiple client companies, if it was a service. A URL should be able to get you to support points reliably, and making it dependant on user state is probably a bad idea.
|
|
#
¿
Jun 13, 2014 23:31
|
|
|
Subjunctive posted:That's a very common thing. Consider that http://www.facebook.com shows different content for every person who loads it. I think it depends on the resource being presented. facebook.com is a dashboard. facebook.com/joe_blow is a specific resource, presented differently depending on who you are certainly, but always the same resource.
|
|
#
¿
Jun 13, 2014 23:34
|
|
|
Subjunctive posted:Scrolling question: are there any events that fire reliably during inertial scroll on iOS (for lazy loading of images in my case)? I haven't found any yet, but thought I'd see if anyone had a magic trick before I resorted to bridging from native or iScroll. This is impossible to do unless you have completely control of the scroll. During a native inertia scroll iOS does not fire any setInterval, setTimeout, or requestAnimationFrame calls. JavaScript just stops for all listening purposes so yeah, managing the scroll with iScroll or equivalent is your only option to track on the move.
|
|
#
¿
Jun 17, 2014 22:29
|
|
|
Subjunctive posted:Does it defer timer delivery, or actually block all JS execution, such as triggered by a call from native code? I thought the former, but that might have been more hope than realism. Like from a phonegap or webview? Beyond the scope of my current work (web app with no container). You'd need to test more thoroughly for your use case (and I'd love to know how it goes), as I'm developing from a position (at least for now) where the browser capabilities are my limit.
|
|
#
¿
Jun 18, 2014 01:08
|
|
|
How is your Node/javascript dev? I guess the reason I ask is there are a lot of languages I'd prefer to write a thin back end in other than Node, purely due to better maintained libraries for the things that matter, session management, OAuth, database persistence, even frameworks for an entire REST API. My experience with Node has always been a story of flaky dependencies, either poor maintenance, documentation, or both. As such, front end you're obviously contained to JavaScript things, but I usually wouldn't recommend node for back end if you have familiarity with other languages and tech. You've got a huge pick of front end frameworks, Angular, Ember, React (more a library than Framework), so really I just recommend picking whatever works for you from an understanding point and go from there. It doesn't sound like the kind of app thats going to stretch any front end framework to its limits, so optimise for your own understanding and ability to maintain, debug, etc.
|
|
#
¿
Jul 6, 2014 09:39
|
|
|
Sounds good. I'd always warn against people using Node if that was their first step in to web dev, but if you're used to it already go hog wild.
|
|
#
¿
Jul 6, 2014 10:34
|
|
|
Sails is okay on the face of it, but the inconsistencies in documentation are annoying, and the ORM is quite limited, no relationship support whatsoever. Its automated REST routes are fine if all you need is a 1 to 1 database table to REST resource mapping, but provides little scope for growing beyond that, bar writing the endpoints yourself, which you can do, sure, but at that point your directly dealing with Node middleware and scrapping about with the ORM. If CRUD using REST resources and JSON (or any serialisation really) is what you're after, its hard to go wrong with Django plus the Django REST Framework, which for a little bit of extra effort gives you a far better toolset to build, document and grow your API over time. You don't get socket.io for free like you do with Sails.js, but what you get in return is far more valuable.
|
|
#
¿
Jul 9, 2014 10:29
|
|
|
Subjunctive posted:I was able to get scroll events in JS for non-inertial scroll, and with native code I was able to get inertial scroll. I was wondering about that. So all JavaScript Is deferred til the end of momentum, not just timers, yeah?
|
|
#
¿
Jul 10, 2014 23:02
|
|
|
down with slavery posted:http://www.codecademy.com/courses/css-coding-with-style/0/1 Yeah. The issue is not your post quantity alone, its that you have been trying to tackle various technologies over the last year without taking even short efforts to learn the fundamentals of how they work. You're in danger of becoming/remaining a copy pasta programmer for the rest of your career because it feels like you're refusing to actually learn the fundamentals of the trade. Take a night to work on through some of these code tutorials and understand the basic premises of HTML and CSS. Learn what each tag means semantically, if you had done this you would've never posted a code snippet trying to put a paragraph tag in a header tag. You can't learn this effectively through Q&A on the forum because you don't know what the right questions are. Use the learning resources until you have enough knowledge that you can ask meaningful targeted questions, otherwise you are wasting your time and crippling your education.
|
|
#
¿
Jul 15, 2014 15:48
|
|
|
Yeah, if you just want to get runs on the board Django and Python is a good way to do it. The language is fairly easy to get a handle on and the framework has been around for years. Between the good tutorials out there, the wealth of Stack Overflow Q&A, and the amount of community add-ons and support available; you should be able to make good progress on the thing you want to build without reinventing the wheel or smashing your head against poorly documented/buggy dependencies. That's not to say you won't have problems, but at least the odds will be stacked as best you can, and then once you've got a little more experience under your belt you can make a more informed decision regarding your technology.
|
|
#
¿
Jul 20, 2014 04:09
|
|
|
jackpot posted:Thanks! You can block ranges, http://stackoverflow.com/questions/18483068/how-to-block-an-ip-address-range-using-the-htaccess-file. You'll have to check what the outgoing IPs are going to be, hopefully they're static at your company.
|
|
#
¿
Jul 20, 2014 04:13
|
|
). Is there a way to block that site from being viewed by anyone on your office network? You wouldn't want to block anyone more than that, obviously - just the occasional curious coworkers who you'd rather not know about it (and obviously this doesn't stop anyone from just picking up their phone and going there, or looking me up at home - that's fine). I know I can use the htaccess file to block a specific IP, but can I block a range of IPs that would represent my company network? Or am I just showing how little I know about all this?
|
Yeah, the issue isn't that responsive isn't a good thing, but that doing it is hard and requires a lot of attention to detail. I see some old school government CMS shops round here try their hand at responsive and it ends up being a 32mb loving disaster. When a lack of experience with front end optimisation and strict deadlines collide, 'responsive' design becomes anything but. Connections struggle to pull it down and then iPads cark it due to limited memory for the images.
|
|
#
¿
Jul 28, 2014 14:25
|
|
|
Kobayashi posted:How do y'all do stuff like Chrome Dev Tools on mobile? Specifically, I'd like to do some simple request profiling in various network conditions. You can use an Android Debugging Bridge to get at everything an Android phone does, us able as a chrome extension, connect with USB. For iOS you need a Mac and Safari, connect by USB and you'll get dev tools in Safari. In both cases you need to activate developer mode on the phone. Google for that. If you just want network traffic you can use a inspector proxy such as Charles Debugging Proxy or Fiddler, which will show you everything. They're also good to use as a DNS spoof as you may need the phone to point to proper URLs, for example if running oAuth, so you don't want to access the app via IP address. You really need a proxy to properly debug mobile in these cases, because you want to work off a dev instance rather than live staging or something.
|
|
#
¿
Aug 1, 2014 05:58
|
|
|
pipes! posted:From using Slim instead. Yeah HAML was a good stepping stone when it was the only templating lang around, but the jade styles of syntax have cut even more visual noise out of HTML editing with no added problems.
|
|
#
¿
Aug 4, 2014 01:26
|
|
|
This is a pretty good article about writing CSS for the long term. It has plenty of rationale for the resulting guidelines too, well worth a look even if you don't agree with every point. http://benfrain.com/enduring-css-writing-style-sheets-rapidly-changing-long-lived-projects/
|
|
#
¿
Aug 9, 2014 10:13
|
|
|
Yeah. To be exact, you cannot transition to any property that is auto, the only way to do it is to use JavaScript to measure the desired height, then set the height back to what it was and then in the next frame (using requestAnimationFrame or setTimeout for 20ms) set the height to the measured height. When that transition finishes you could then turn the height back to auto to clean up.
|
|
#
¿
Aug 12, 2014 23:22
|
|
|
Valeyard posted:So I have a Django powered website, with its set of Users. I am thinking of letting users of my site connect/authenticate their Github account on their account on my site. And then I would like to pull information from their Github account once the authentication is, permanently, in place. Googling, I'd say have a look at django-social-auth and see how much all this makes sense to you, it has a github back end and I imagine you explore the github API more depending on what it is you need to pull. http://django-social-auth.readthedocs.org/en/latest/configuration.html
|
|
#
¿
Aug 15, 2014 23:53
|
|
|
Subjunctive posted:Are microformats still a thing? Do they have to be? I figure if they were a thing Google and Facebook would be looking for them when parsing stuff, which I'm assuming was the whole idea. Seems to have fallen by the wayside as a concept.
|
|
#
¿
Aug 26, 2014 05:57
|
|
|
Lumpy posted:So you don't like front end work because you don't understand typography. Got it. Yeah, frontend is hard but if you can't even get on top of font-stacks you've got a lot more coming.
|
|
#
¿
Aug 29, 2014 02:23
|
|
|
Sedro posted:I think the proper way is to reference their LESS or SASS, so you can use their styles without copying and pasting them. Yeah, my approach in one project is to avoid using the fa classes in my markup at all, as eventually we'll be swapping in custom iconography. I use the fa classes using @extend or the content variables, ie $fa-var-chevron-down. I know the font awesome scss in the repo/bower is just fine for this approach.
|
|
#
¿
Sep 3, 2014 20:50
|
|
|
Thermopyle posted:Django. Would emptyquote if allowed. Its a great beginner framework, the Python language and libraries within are set up with good documentation and are fairly easy to get runs on the board with.
|
|
#
¿
Sep 4, 2014 23:46
|
|
|
My Rhythmic Crotch posted:I've gone from Python back to Java for back-end stuff at work. It's much higher performance and there is excellent support for json, databases, etc. The downside is that most Java web frameworks are very heavy, in the sense that they seem to include every piece of the stack for you and make it difficult to deviate from that. I'm sticking with the Spark "micro framework" and while it's definitely not perfect, I really like how minimal it is. I wouldn't argue with that necessarily, my heavier back end work for a major project is being done in Scala right now, but I think I would never have been capable had I tried to dive in right away. Python is a good Lear ing platform to spring off of. It has enough best practises built in to ensure you don't build up too many poor habits (no monkey patching as wat of life like ruby/rails) whilst being simple enough to get runs on the board. Bashing your head against the wall is not the best state for learning, you need to have struggle a little, but make enough progress to keep morale up, and Python/Django is a pretty good framework for enabling that without being heavily limited in capability.
|
|
#
¿
Sep 6, 2014 22:17
|
|
|
I'm a big fan of this talk, "Integration Tests are a Scam" - http://vimeo.com/80533536, the tldr version is when you approach unit testing you have to create a bubble around your code and 'their' code. Everything in 'your' code is unit tested in complete isolation, so you establish what consumes it's API, and what it calls to, and then test those pathways (which he talks about in more detail). The only places where integration tests occur is at the outer edge of your codebase, where you reach the code you can't control. Considering an API that calls out, either you need to figure out a way to mock it (easier in languages like Javascript with sinon, but still possible in Java, Scala, etc using a mocking library), or you need to create a little wrapper that you CAN mock properly. Unfortunately there's no hard and fast rules for how to build out your test suite, but isolated tests while difficult to 'get', are the only way to keep it manageable over a long time frame.
|
|
#
¿
Sep 11, 2014 03:13
|
|
|
prom candy posted:What's the deal with Django? I haven't read much about it since about 2007 or 2008. Why is everyone excited about it? I wouldn't really call it exciting. I think it just sits at the right end of the getting poo poo done spectrum of web frameworks. It does what it says on the tin, has good documentation and is written in a language that is very readable and as a result, easy to learn. It may not carry you through more specialised use cases, but it certainly can carry long enough to where you'll be able to make that decision yourself.
|
|
#
¿
Sep 11, 2014 04:27
|
|
|
fletcher posted:drat I didn't even get around to trying Grunt yet, and there's already a new hotness? How can anybody keep up with this stuff. Rather than big config files, your build steps are code. Its a really nice structure for combining various build steps without passing files around constantly. My experience is gulpfiles are much cleaner to maintain, extend and organise in general. Grunt files get to freaking massive levels of configuration on non trivial projects, that are hard to maintain and require a large amount of temporary files as you progress through build steps.
|
|
#
¿
Sep 12, 2014 02:10
|
|
|
Ahz posted:Would I care about some of these tools like grunt/gulp for deployment when I'm using an IDE like Pycharm for a Django project? For example, Pycharm has built-in watchers that compile my LESS files for me on every change. The problem with an IDE doing all that stuff is that there is certain elements required to actually do work on your project, that are tied to the IDE and not into the project files. I think the target should be always to have a project repository contain everything a developer would need to get started from scratch given some base dependencies like Node, Vagrant, Virtualbox, installed. If you do this from the get go, you will have the assurances that your build and dev environment are reliably repeatable. My minimum standard for my projects these days is to have Gulp for working tasks, front-end compiling, etc, and Vagrant for creating a VM for holding the backend dev. That way I can work with a designer/dev who has no familiarity with Django, give them the project repo, and all they need to do to run up a server is: code:
|
|
#
¿
Sep 13, 2014 00:26
|
|
|
If you can guarantee that every person in your shop and all your potential contractor resources use PyCharm/WebStorm, go for it. If not, they should not be tied to the project like that. My point is that you should be able to onboard developers with a fairly minimum set of dependencies, IDE is not always a good dependency to have compared to say a base like Node/Vagrant, because they are both freely available with installers on all platforms.
|
|
#
¿
Sep 13, 2014 01:37
|
|
|
Yeah, I did a contract job last year where I was required to ssh in to edit project files with vim, and also restart the services manually. Thank god it was for only 2 weeks on an uncomplicated site. never again
|
|
#
¿
Sep 13, 2014 01:58
|
|
|
down with slavery posted:What's so bad about this? git/vim/linux is pretty much ideal for remote editing, especially if you use dotfiles Its the best of a bad situation though, editing remotely in a shared environment where you can't work on the same file as another , encounter horrible lag (here in Australia good internet is hard to find), and no reliable way to do TDD because of the way it was all setup. Nothing against vim, the shell, or fit, they're my primary dev tools, but being stuck remoting onto a server that I didn't set up, not really set up well for isolated work, is terrible and took a sledgehammer to my productivity.
|
|
#
¿
Sep 14, 2014 01:12
|
|
|
caiman posted:The lack of response to my Velocity.js question makes me wonder: is anyone using Velocity.js? I just recently discovered it by way of this article. I haven't personally done any performance comparisons, but apparently it outperforms not only jQuery's .animate(), but also CSS animations. The performance section on this page is pretty convincing. The articles that claim performance improvements actually say it outperforms CSS animation libraries, which is just a weaselly way of saying it runs better than another library's approach to animating with CSS. GSAP and Velocity are pushing JavaScript animation TIMING, and when you have a particular complex animation requirement they will be a perfect tool HOWEVER the claim that they outperform CSS animations/transitions is just dumb as hell when taken as a broad statement. The deck is stacked in that particular performance example for two reasons: 1 - css animations can't animate seperate elements using the same calculation, so it can't batch, but since when are you animating that many objects in unison without just animating the containing layer. 2 - it's animating a layout property (left) rather than a layer property (transforms, opacity), so the CSS transitions have to trigger layout with every tick, further exacerbating the performance and sync problem with a CSS animation library. Using computation in JavaScript allows you to do things not possible in CSS transitions, like animating two transform properties separately, but if you use correct CSS properties and simple state changes through classes you will have better performance and less overhead. You can also hook the animation end events for your callbacks too. The key thing with CSS anims if you want to make sure those state transitions are smooth, is to restrict yourself to transform and opacity whenever possible, as they leverage hardware acceleration and don't trigger repaints or layouts. The CSS vs JS animation thing is sorta self serving, its about library implementation, but for a lot of basic state transitions you don't want the library overhead anyway, you just want to set the declarative CSS and be done with it. I would definitely pick it over something like transit for complex stuff, but I guess for simple animations/transitions I don't feel its yet worth dropping declarative CSS.
|
|
#
¿
Sep 24, 2014 18:06
|
|
|
Yeah, to be real clear Angulars templating lang is actually pretty poor at complex interactions. That's where you drop back to jQuery but that's through the aforementioned directives. That way you can turn your complex interaction into a reusable component that's ready to be dropped in to templates.
|
|
#
¿
Oct 7, 2014 18:06
|
|
|
Macaw ( http://macaw.co ) is what you want to look into for a good attempt at a responsive and effective WYSIWYG web design tool. It looks alright, and potentially means a lot of PSD choppers will be out of a job in a decade, but I haven't had a reason to use it yet. I think as standards get better and flexbox becomes fully supported for all your expected browser targets, designers directly building into a system like this might be the big thing.
|
|
#
¿
Oct 9, 2014 22:14
|
|
|
Yeah, thin back end is the way to go these days. For better or worse, JavaScript is now the view layer for modern web applications. This is great because it really enforces proper separation of concerns. This can be bad however because like it or lump it, you will need to get to know JavaScript or a compile down variant pretty well, along with a front end framework like Angular, React, Ember, etc. This means you will have a few new technologies to get up to speed with all at once. You may be well served by trying to isolate tasks by technology, so sort out your back end API first without worrying about your front end, just so you're not constantly switching between tech you're not familiar with.
|
|
#
¿
Oct 12, 2014 02:04
|
|
|
down with slavery posted:Disabling/enabling zooming doesn't really have anything to do with responsive design You'd have to be pretty narrow minded to believe responsive design has nothing to do with accessibility. We respond to screen size, input device, etc, and all with the goal of making our website more accessible to that browser. Turning off user scaling is contra to that goal unless you are kicking goals in every aspect of the accessibility department, and let's be honest, most of us aren't. As an aside, any goon web devs going to the Web Directions conference? I'm a gonna be there, not sure what to expect having never been to a conference of any kind.
|
|
#
¿
Oct 29, 2014 08:50
|
|
|
|
| # ¿ May 15, 2024 11:59 |
|
|
Withnail posted:We are using angular which I don't think plays well with the jquery datatables... You can use a directive to wrap where you would put your data table. Use attributes on that directive and then let jquery do its thing inside it. In the template. code:Creating the directive, look up the actual synatx for hooking it up though. code:Phone posting so that nay not work, but that's the general structure you want for your directive maybe, and then just let the directive handle all the jquery stuff in there.
|
|
#
¿
Nov 7, 2014 22:35
|
|