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.
It's a shame you don't have a reproducible test for the rendering issue in Chrome. Until you can reproduce it there's really no telling what is going on. Do you have any links to similar issues already reported? I'd be curious to read up on them.
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.
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.
Seems like about half the issues you've mentioned relate to differences in syntax/behaviour. This is to be expected. That is what vendor prefixes are for. They are a known (and necessary) evil. Would you prefer to allow the design by committee approach to continue? We've already suffered through 10 years of stagnation due to this approach.
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.
No offence taken. Sounds like burnout was the wrong term to use. Maybe I staved off actual burnout from developing later on by taking this time off. Either way some manual labour felt good :)
I was starting to feel some burnout a week ago after a couple of months of 10+ hour days 6 days a week. Refurbishing my roof worked wonders for me. Spending 3 days pressure cleaning, replacing tiles and painting did wonders for me. Obviously not the kind of advice that applies to everyone but it worked for me. Plus my roof looks great now :)
A few people have mentioned information density as being important. I've got the 'Stylish' chrome extension installed with a userstyle for hn which looks like this:
How was the original author acting entitled? He's merely saying that instead of insulting his intelligence just give him some screenshots and info about your app in the noscript. If your app is worth it he'll flick the js switch to the on position.
That's an important question to answer. Creating a site that works sans js then layering on js is great, but it does entail duplication of effort, a larger testing burden etc. It's important to work out if the ROI for going the extra mile makes good business sense. Especially given the (excellent) point the original post makes: if a user has turned off js then if your app is worth their time they'll find the js switch again without difficulties.
the problem isn't whether ie10 is good or not. It's that microsoft's update schedule runs at a glacial pace compared to chrome and firefox, both of which are on a 6 week(!!) rolling release schedule. Compare that to IE where literally years can go by between releases.
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.
I've not used the Rails ORM so I can't comment on how good it is or how easy it is to debug queries (peer behind the magic).
*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).
Yeah, said much better than I could. I don't regret any of the time spent with these frameworks because it really broadens your horizons and makes you think in new ways. Lots of the techniques I've seen now make regular appearances in the versions I roll myself. Other ideas I've completely rejected. Eg. ORMs. A few years ago they seemed like a godsend. In reality they simply shielded me from the basics of SQL and were inflexible black boxes.
Such a great question. I spent a lot of time working with ExtJS having been lured in by all those great, straight out of the box components which had their own healthy dose of added magic. Fast forward a year or two and suddenly when I need to do anything that is non standard then reality kicks in.
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.
Awesome! Must be such an amazing feeling to receive that first payment. I'm about a month away from my first launch and I'm terrified of launching and then hearing.... crickets. So congrats to you!
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.
Seems win-win to simply use chromeframe. Given this is a web app which presumably customers are already invested in using (since they're paying for it), requiring a 60s one-time install seems like the best course of action for everyone involved.
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.
Supporting IE means taking on board a technical debt that will follow you for the life of the project. There are lots of things that can be accomplished in ie6 but then you need to consider performance. If you're building an app that means a lot of JS and possibly DOM manipulation... which is dog slow in ie.6,7,8
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.
Choosing not to develop for IE makes perfect sense if you're building an app. Here's my own little anecdote:
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.
Yeah that's a fair enough comment. The truth is that I'm probably using more like 2% of the program. I think for someone like me the perfect balance of features/performance was at about cs2/cs3 maybe even cs1, I cant remember. So I most likely will be downgrading.