This is the route I've gone. The core CRUD part of the app is PHP, and the real-time chat and document collaboration aspect of my app is node. Works beautifully. I've had so much fun working with node for the last few days.
185 karma · joined June 20, 2011
The rounded corners problem I referred to was a rendering problem that made pages using the CSS3 rounded corners
Any test cases for this? It really is important to see a simple test case. I've never had any issues with either Chrome or FF with corners.
Sure h.264 is a mess. If it bothers you then don't use it. The fact is that Flash is still defacto standard for video, so for consumer facing pages that's probably what you should use.
Sounds like you're upset because you got burned by a recent issues with firefox. It's reasonable to expect such a big breaking change to be caught in their regression testing. Unfortunately it slipped through. The reality is that software has bugs. All software. Yours, and mine. Every product ever shipped has gone out the door with bugs. It's unpleasant, especially when you have no control over the fix.
Seems to me that a rapid release cycle actually works in your favour. Certainly better than the MS cycle where you can expect to have to live with bugs for 18month-2years between releases. Auto updating in particular is a boon for developers. If you look at the Chrome version stats, most people are on the latest stable build and this is mostly due to auto update.
Compare the difference between the graphs for IE and for Chrome under 'Version Adoption': http://arstechnica.com/business/news/2012/04/internet-explor...
Also, if you're developing an app which is actually used for 'multimillion $ deals' then why aren't you distributing it as an application inside of some kind of wrapper such as Qt? Sounds like deploying as a regular web app was a bad technical choice for you product.
Right now, for example, Chrome has taken so many shortcuts to try to improve responsiveness that it's just plain broken when it comes to refreshing the page layout or even just repainting in timely fashion after a DOM or CSS change. That means even popular UI toolkits have trouble with basic things like displaying dialog-style content, an everyday task if you design browser-based UIs. And because it's not repainting properly in the first place, presumably because some internal events aren't invalidating some cached data they should be, there's no clear workaround nor any guarantee that you'll get the same breakage from one update to the next.
This one sounds like a biggie. Do you have a reproducible test case to demonstrate this behaviour? I know it's time consuming, but you really should file bug reports for this type of stuff. I've filed a number over the years and they do get worked on and they do get fixed (sometimes a lot quicker than you'd imagine).
Are you building apps or websites? I can't imagine seeing the fundamentals of layout, box model etc breaking from one release to the next.
On the other hand if you're building applications that rely on vendor prefixes then I agree you do have to tread carefully.
Moving on to Firefox, when they pushed out the LTS release a few weeks ago, they included a bug that basically stuffed every site that used such obscure technologies as Flash and Java applets.
Software breaks life goes on. If i'd never personally shipped a line of code with a bug in it I might complain louder.
The pace of innovation is blistering. Just look at all the stuff that's come out recently websockets, webgl, flex-box, css columns, dnd, offline storage, css animation, audio, video, filreader, canvas the list goes on.
If you're building just another brochure website none of this will interest you. On the other hand life is sweet if you have the luxury of using these features. Sure they're sometimes broken. Sure we're all effectively beta testers. But everyone knows that.
table > tbody > tr:nth-child(3) > td{-webkit-column-count: 2; }
2 column layout is v.cool. Makes the front page as well as the comments section much more readable for me.
example: http://imgur.com/a/oidEM#1
I really don't get why MS don't fork their browser into corporate and consumer versions. Let the corporate users run on ie6/7 or whatever legacy crap they need and let the rest of the web move at a reasonable pace.
Anyway that's where I think the hostility to IE is coming from.
*The ORM automates things like tersely expressing the object associations I've built, leaving room for fewer syntax mistakes.'
Maybe it depends on the system you're working on however mitigating syntax errors seems like a small benefit. For me the SQL for most projects is fairly static i.e. once a given set of queries has been defined and tested they can lie there untouched, so once I nail a query and it performs the way I like I hardly ever need to go back and touch it again. However the performance penalty of sitting behind an ORM is ever present, for each query (at least for a cache miss). Personally I just don't like having 100s of lines of code sitting between:
model->get(('model.field' => 'value'));
and actually receiving the data.
It just seems so.... unnecessary.
of course YMMV, and perhaps the benefits kick in when you're working in a team (I'm not).
I now need to buy-in to the entire (framework) mindset to progress which slows things down (because it doesn't necessarily match my own way of doing things).
Had the same experience with cakephp. All those freebies which eventually caught up with me.
Ties in well with the whole libraries vs frameworks debate. I'm now in the libraries camp.
I wonder if Meteor packages are decoupled from each other so that I can pick and choose which ones I'd like to use in my project.
Turns out there really is no such thing as a free lunch.
Had a look at the product. Looks v.solid. Just a couple of things:
- When I attach a file via /projects/project_name/stories/ it completes the upload then the files seems to disappear? What I mean is that the progress indicator goes to 100% and nothing else happens. Then if I go back to root and back to stories there is no file.
- I think you need labels on the 4 symbols on the left hand side. The only one which is self evident is the '?'. The others I have to hover over to find out about and that is annoying from a UX pov.
Cheers and good luck :)
Slow speed of execution in IE might well be considered a vast improvement compared to the current state of affairs
Unfortunately the general public doesn't think like that. To the average Joe your site is slow therefore it sucks.
Now factor in support costs. I can picture it now:
Customer: Uhhh your app sucks it's so slow.
Support: Hmm looks like you're using IE6. We've worked really hard to make our app function in every browser, however if you'd like the best possible experience then please upgrade.
Customer: What's a browser?
The best solution is to use chrome frame. The installation can be made seamless and if your app is worth using then your customers wont mind the extra 60s it takes to install.
In the last 4 months or so I've written around 10k loc for a JS app. and probably 3x that many lines of combines CSS and HTML. Number of hours troubleshooting differences between Firefox and Chrome? I'd say about 8. So one developer day's worth of work to sort out some minor issues with vendor prefixed css. I've gotten to the point now that I routinely go days without testing in FF, and when I do fire it up.... everything just works.
My estimate that supporting ie6+ would have put my progress back by about 2 months. On top of that is the ongoing technical debt of continuing to support IE.
I don't want to say goodbye to potential IE customers and that's where Chromeframe comes into play. Chrome frame is AMAZING. Takes about 60s to install. Allows you to create your own install procedure i.e Your_Site -> Install_Chromeframe -> Your_Site. Doesn't require a browser restart and no admin rights needed. Wow.
Of course if you're just building a regular website then sure suck up the few hours it takes to make it work in IE and bill 2x for the trouble.
Some interesting reading:
http://www.wfs.org/content/postemployment-economy
http://www.impactlab.net/2011/10/11/post-employment-era-huma...
ahh now I get it. you're one of those guys. you're just smarter than everyone else right? good luck with that.
Clearly your opinions differ from the majority of the web community.
Why do you think we now have document.querySelectorAll?
Have a look at the mdn article: https://developer.mozilla.org/en/DOM/Document.querySelectorA...
example given on that page: var matches = document.querySelectorAll("div.note, div.alert");
also :
http://www.w3.org/TR/selectors-api/
Makes perfect sense.
That's what recursion/tree traversal algorithms are for
No. That's what highly optimized browser internals are for.
I test all the way back to IE 5.5
Why? ie5.5 is 12 years old.
Those 'Frankenstein' queries are ridiculously easy to read and to type.
'massive speed losses from parsing'
Nobody is searching the entire dom for matching nodes.
The single biggest performance killer... far more important than tree traversal is event overhead. As long as you think long and hard before applying a new event handler (and use delegation whenever possible) you'll be fine even with those 'Frankenstein' queries hehe :P
The DOM is not CSS.
What does that even mean in this context?? How does it further your point?
illustrates a continued ignorance of the DOM
enlighten us then...