71–80 of 120 posts
I'm actually really disappointed that I found out about them because they're shutting down. This looks perfect to me because I've been wanting to make some sites fast but I don't have the time to expand my React skills currently. Does anyone have a good recommendation for an alternative?
One absolute rule for success in software is that there are no absolute rules. From their post mortem https://medium.com/@gabriel_20625/technical-lessons-from-bui... > Performance is never a justification for anything if you haven’t measured it This just isn't true. Anyone with a reasonable amount of experience is often able to look ahead - well before any code is written - and see how performance could be better if…
Only 20k LOC in 3 years is impressive. And I agree that you should watch out for premature optimization an premature abstraction. What i found most interesting was using coffeescript that compiles to js that compiles to react that compiles to js. They might have been too focused on the technical side. You should probably pick the most boring and proven tech stack and focused more on the actual problem.
Earlier quoted context omitted.
Well, as someone else said, it's not always black or white. Videogames MUST deliver performance, it's not only sales. Some desktop AND web applications could benefit from some performance boost here and there, and I mean being fast enough and not some abominations I've seen/heard about (minutes to get Excel files and examples like that, just because they're "thousands" of rows from a database). You know, sales is eve…
Minecraft is generally known to be fairly poorly optimised, and the graphics weren't great. Mist was mostly a series of static images. They are two of the best selling games of all time.
That they managed to pull it off for home computers in 1993 is nothing short of a performance focused mindset which led them to static images and QuickTime overlays. As soon as they had the ability, they released realMyst which was a realtime 3D version of the original, followed by realMyst Masterpiece in the last 5-10 years.
For that matter, Minecraft may be poorly optimized (it is) but without the effort spent on the chunking system that renders 16x16x(128/256) blocks as a single mesh, it wouldn't run at all. There's plenty of low hanging fruit (which may be more difficult to retrofit into the existing engine, or in the JVM itself) that other games have found and utilized, but without that initial performance optimization Minecraft wouldn't run at all.
I like the subtle nod through capitalization in the phrase "It’s been An Incredible Journey".
For those that haven't seen it: https://ourincrediblejourney.tumblr.com/ (though unlike most of the startups on that blog, Pagedraw seems to be shutting down in the most open and responsible way)
One absolute rule for success in software is that there are no absolute rules. From their post mortem https://medium.com/@gabriel_20625/technical-lessons-from-bui... > Performance is never a justification for anything if you haven’t measured it This just isn't true. Anyone with a reasonable amount of experience is often able to look ahead - well before any code is written - and see how performance could be better if…
Its comments like this that make people hate HN. I agree with their writeup fully. They focused wayyyy too much on performance and not enough on an MVP, pivoting, marketing, growth, and staying agile. I would love to get all these "Performance First! Its so easy" engineers in a room for a week. Hell, give em three weeks and they still wouldn't have a single line of code written. But they would still be arguing about…
Except that's not the argument in the comment you're reacting to. Here's what the comment actually said:
> Anyone with a reasonable amount of experience is often able to look ahead - well before any code is written - and see how performance could be better if road A is taken instead of road B.
In other words, some optimizations come with no significant cost. As a banal, perhaps exaggerated example, if you're writing code that needs to store data in a collection and you know that it's going to perform random access to that data on a regular basis, you're not likely to pick a linked list over some kind of array.
What @abraae is criticizing is the practice of asserting "best practices" that are likely to be taken out of context, widely propagated and misinterpreted.
Knuth's famous assertion "premature optimization is the root of all evil" is an excellent example. People love quoting it, but few seem to take into account the context, to the point that it has been largely forgotten. Here's the quote in its context:
Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
To be clear, it's not Knuth's fault that people are taking his very rational and sensible advice and reducing it to "yeah, you should totally disregard performance when first writing your code". This is not about pointing fingers and assigning blame, it's about being responsible when offering advice. Knuth's advice was reasonable and nuanced, and it still got taken out of context and reduced to something different and arguably harmful. Now look at Gabriel's advice, which is arguably a lot easier to take out of its context and misinterpret, and imagine the consequences it could have.
That is what @abraae is reacting to.
EDIT: There's another thing that really, really bothers me about your reply:
> Rule #1 of any business: Sales cures all.
This, right here, is what I personally feel is wrong with software nowadays. It's how we end up with poorly written, bloated, bug-ridden, unstable, unreliable, insecure crap that we end up using anyway, because there's no better alternative.
Earlier quoted context omitted.
Minecraft is generally known to be fairly poorly optimised, and the graphics weren't great. Mist was mostly a series of static images. They are two of the best selling games of all time.
> Minecraft is generally known to be fairly poorly optimised, and the graphics weren't great Perfect example. You're not making games, you're selling entertainment. Focus on the latter first, and optimize accordingly. I see this time and time again - beautifully architected and performant platforms that completely bomb because noone actually wants it.
I agree with that. And yet, Minecraft is possibly the worst example:
- It's an exception to the general wisdom that games do have to worry about performance in order to deliver fun. Just because Minecraft became popular despite it's abysmal performance, doesn't mean games can get away with that in general.
- Notch never expected Minecraft to become that popular. In a sense, Minecraft was an accident.
- Minecraft's performance was so bad, a lot of people had to install a mod called OptiFine just to be able to play it on their hardware.
The really funny thing that the same cycle repeats in jsland that we have seen in java land a decade ago. XD I can't even put into words how hilarious is this. We need visual editors. We don't need visual editors. We need visual editors. We don't need visual editors... Etc
Earlier quoted context omitted.
Its comments like this that make people hate HN. I agree with their writeup fully. They focused wayyyy too much on performance and not enough on an MVP, pivoting, marketing, growth, and staying agile. I would love to get all these "Performance First! Its so easy" engineers in a room for a week. Hell, give em three weeks and they still wouldn't have a single line of code written. But they would still be arguing about…
> I would love to get all these "Performance First! Its so easy" engineers in a room for a week. Except that's not the argument in the comment you're reacting to. Here's what the comment actually said: > Anyone with a reasonable amount of experience is often able to look ahead - well before any code is written - and see how performance could be better if road A is taken instead of road B. In other words, some optimiz…
See https://medium.com/@jaredpochtar/on-performance-and-software... and the full section on https://medium.com/@gabriel_20625/technical-lessons-from-bui...
> Most of the code we wrote was fast enough (<2ms) that making it faster wouldn’t be noticeable, so it would definitely be a waste of time to optimize. Making code that’s 0.1% of your runtime 100x faster only makes your latency <1% lower.
Earlier quoted context omitted.
> Minecraft is generally known to be fairly poorly optimised, and the graphics weren't great Perfect example. You're not making games, you're selling entertainment. Focus on the latter first, and optimize accordingly. I see this time and time again - beautifully architected and performant platforms that completely bomb because noone actually wants it.
> You're not making games, you're selling entertainment. Focus on the latter first, and optimize accordingly. I agree with that. And yet, Minecraft is possibly the worst example: - It's an exception to the general wisdom that games do have to worry about performance in order to deliver fun. Just because Minecraft became popular despite it's abysmal performance, doesn't mean games can get away with that in general. -…
That being said, I agree that performance might actually be integral to your product. Quake 3, for example, probably would have bombed if everyone was playing sub-10fps.
Either way, the priority is "figure out who wants your product and why." That helps determine when and where to focus your optimization efforts.