661–670 of 731 posts
Earlier quoted context omitted.
This seems demonstrably untrue. Basic html development is vastly cheaper than “modern JavaScript” which would give any company w an HTML-only strategy a huge advantage. Why aren’t HTML-only companies dominating in every market?
You mean like amazon or ebay or paypal or yahoo? Or like how facebook was so html that they wrote their own php interpreter?
Earlier quoted context omitted.
I would add one word to this: > There was nothing anymore preventing web development from becoming so complicated The early web was much simpler because of the resource constraints of the 90s and early 2000s. Pages only started serving 10 MB of JS when browsers got to the point where they could chew through 10 MB of JS at a barely acceptable pace. Also: > Managers don't really feel like pointing out "the project I'm…
So , is it a result of the VC funded bubble? If that's the case it will not outlast the next bubble burst maybe.
But, you know, I guess we'll find out sometime in the next couple years.
The answer to "why is ___ so ___?", is very nearly always best when phrased as the question, "what was supposed to stop __ from __?" The answer is nearly always...nothing. There was nothing, technologically or organizationally, preventing web development from becoming so complicated, such that websites whose desired functionality would be satisfied by static html are now several meg of thousands of lines of javascrip…
The answer to "why is ___ so ___?", is very nearly always best when phrased as the question, "what was supposed to stop __ from __?" The answer is nearly always...nothing. There was nothing, technologically or organizationally, preventing web development from becoming so complicated, such that websites whose desired functionality would be satisfied by static html are now several meg of thousands of lines of javascrip…
I'm not sure if I fully agree with your point about developers or managers not wanting to suggest they aren't needed. You're argument relies on the idea that most business needs could be sufficiently met by static html doesn't really fit how businesses works. If a business in an industry has additional functionality on their page that gives them an edge beyond just text on a page, then it is needed. Additionally, whe…
I'm not blaming the tools, but too often, at least (for me) based on multiple interactions with various devs/engineers - yes, sometimes on Twitter :) - tools are proudly spoken of as a proxy for quality product. That is, I'm using the latest wiz-bam shiny new object tool so the users of the product must be overjoyed. Nah. Nobody cares. I think that bears repeating...Nobody cares. My mum has __never__ said to me "I lo…
You see that everywhere. In my field unless a dedicated statistican was a coauthor, chances are they picked the wrong test to use for significance. And if you look through their past papers you might find that they only use that one test that they always run, despite whether or not its relevant for their data. In any field you can find people putting blind trust in tooling without knowing how the tool works or what i…
A solid idea well executed will beat a great idea poorly executed.
Sure, we all love to learn new things and/or push the envelope. That's what side projects are for. But when such things come at the expense of "the product" with a real user base than something as gone wrong.
"I love dealing with fast-moving things that are broken," said no user ever.
Earlier quoted context omitted.
90% of Web applications are database frontends. What they do to the end user might be different, how the pieces come together, it is always the same, unless one is doing curriculum driven development.
I wish we could get away from the fashion show in this industry. Currently we have a React frontend, which just adds extra complexity for no real benefit. But its fashionable.
Forget everything about responsiveness or whatever (which I find way more valuable than the tradeoffs one makes)--the lack of tight coupling is the real win of React and similar. I mean, if you'd like you can pretty easily build a server-side React app with NextJS and still get a lot of these benefits while using React purely as a pretty-dang-good templating language.
Earlier quoted context omitted.
The important thing is: Picasso knew what to study. Over time art had established a canon of things which helped people to get better at classical arts. Only after he studied that canon in depth and for a long time he could then break into new territories and start breaking rules intentionally to develop his own style/school. Our craft is very bad at providing such a canon. It is even anti-intellectual in parts ("wha…
We absolutely have a canon. You show me someone who has studied Dikjstra, Turing, Hoare, who has taken the time to pour over the Art of Computer Programming and Structures and Interpretations of Computer Programs, and poured over Ivan Sutherland, is familiar with the early days of IBM, Fairchild, Xerox PARC, and hundreds of other classics we consider to be "canon" that I am surely missing (just shooting from the hip…
I do not believe in the idea of a bimodal distribution of software development (not just programming) aptitude, but I sometimes wonder.
(Regardless, I don't call myself an engineer. Engineers get sued if their stuff doesn't work. I'm a software developer, no matter how good and careful I might be.)
Earlier quoted context omitted.
> "sure, that material might not be the most durable on the market, but unobtainium would have added $35 million to the project cost and ongoing maintenance costs would have gone up by another $5 million / year." > That right there is a comparison that developers can never, ever offer anyone that's writing the checks for a project. Sure they can. At Google there was an internal cheat sheet of "numbers every engineer…
> At Google there was an internal cheat sheet of "numbers every engineer should know" which included the cost in dollar terms of trading off engineer time vs. memory vs. CPU vs. network vs. user-perceived latency etc. Could someone alert Google's web developer teams (in particular the GMail frontend team) about that cheat sheet? If released products are considered as evidence, it doesn't seem like this cheat sheet is…
Earlier quoted context omitted.
> "sure, that material might not be the most durable on the market, but unobtainium would have added $35 million to the project cost and ongoing maintenance costs would have gone up by another $5 million / year." > That right there is a comparison that developers can never, ever offer anyone that's writing the checks for a project. Sure they can. At Google there was an internal cheat sheet of "numbers every engineer…
>> internal cheat sheet of "numbers every engineer should know" which included the cost in dollar terms Would love to see that. For companies determining what's worth what, this would be great to see, even just for the format.
1 engineer-hour =
W ms/search of latency
X GB-year of RAM
Y CPU-years of processing time
Z TB-year of hard disk space
etc.