291–300 of 521 posts
I miss the passive nature of the web. A page got loaded and then it was idle. Now I can stare at a page of text with my cpu spinning at 100% in the background, it adds nothing extra to my experience except for a quiet hum from the CPU fans
And then there are user interfaces where the developers actually tried to make a difference but stopped somewhere in the middle, like with current Firefox versions. Don't get me wrong, I think the UI customization feature is fantastic and I love that it now supports a large zoom indicator/control in addition to larger address bars and tabs - as the first line of support for my relatives I appreciate that this is now more visible. But then there's that tiny download button/indicator which, for less tech-savvy people, is often simply invisible. As much as I dislike the huge bar at the bottom that was introduced with Chrome, I have to admit it is better out of the box than a tiny blue arrow that desperately tries to be more visible than all kinds of website animations and ads.
Earlier quoted context omitted.
No, not at all. It is more like saying that I make better food than almost all restaurants in town. Which of course is not true, and that’s the point. Because I do make better websites than almost any I come across in the wild. Your question about handling traffic is orthogonal to the topic of design. The answer is that any of my sites would do better, given the same server architecture, because I deliberately limit…
I think their analogy may still hold. My mom claims her cooking is better than the restaurants (arguable) but she's not operating under the constraints of cooking at the variety, consistency and speed that my local diner does. The diner needs to be able to provide hundreds of dishes on short order including on days when the main chef is out. So maybe my mom's once-in-a-while pot of chilly is great but she couldn't ru…
What upsets and concerns me the most is when I see poorly developed SPA on really important sites. For example, government service application websites. If reddit or nytimes has a bloated, intermittently failing SPA site, that's an annoyance. When it's a form to apply for unemployment, ACA health care, DMV, or other critical services, it's a critical failure. Especially since these services are most often used by exa…
Why do these things even need to be an SPA? What function does that serve when the standardized and infinitely more compatible form-with-a-bit-of-javascript approach works just as well if not better? I work on one such project and it absolutely drives me nuts -- it's a rails app, but the customer front-end (which is literally just a form to fill out) is a React SPA. There is nothing there that couldn't be done with T…
And the tech doesn't really matter. I hate React with a passion, because Angular is so much more sane - in my experience. But it's fine. It's mature, it can be made to perform completely well.
The tech doesn't really matter. The people doesn't matter either. Even the costs doesn't matter as much as people think. What matters is political will, procurement culture, so systems and structures. This will influence (and bring) all the others in line.
Regardless of my tweet, that is a personal opinion based on my feelings, background and experiences, the discussions in the replies are interesting from the POV of understanding what different people think in the programming community. Some will say that critiques are only from old people, in the style "when I was young we had only zeroes! You now have ones and zeroes". Others say that the web is slow because of ADs…
If ECMAScript, HTML, and the DOM didn't exist and you were asked to create a specification for applications where the client UI is remote, possibly very resource constrained with a connection to the back end that may be slow and only mostly reliable, what would you invent? Is there a better model already out there that isn't used because Javascript + HTML has sucked all of the oxygen out of the room?
My big problem with web application (in a true application sense - not things that are just hypertext and shouldn't be applications at all!) development is that the DOM+CSS model is not made for rich UI experiences. Basic paradigms from desktop applications like spreadsheet cell selection, draggable cards (think Vizio/UML), modals, and MDI / multi-document interfaces are non-standard and brutally challenging to construct in a reasonable way using the DOM.
What I'd invent would pretty much be Silverlight without the Microsoft, honestly - a typed UI framework built on a widget and widget-binding model which would allow a smooth mixture between OS-level widgets (and the accessibility affordances they provide) and hand-controlled rendering/drawing, with a stripped-down runtime enabling resource constrained clients to execute client-side code which would hide / paper over the resource constrained backend connection.
Anyway, I also think this is orthogonal to the argument in this thread, because I think that most of the conversation and the sentiment of the original tweet is to call out applications that SHOULD be hypertext, not applications. For applications that need to be applications, I think things have gotten better, not worse, although they're still pretty bad.
Earlier quoted context omitted.
Because I don't know it's not React. Twitter could be using a stripped down minimal version of React with limited functionality. Standard React could still be a bloated mess.
> Standard React could still be a bloated mess. React is ~6KB (even less g-zipped). React is very performant and its performance was one of it's original claims to fame over previous frontend frameworks like Angular.
Plus, it’s dishonest to look at react core size. react-dom, which is absolutely required, is 40KB minified AND compressed. Plus the usual plugins to handle icons, SVG, animations, and on on. A base React application easily crosses the 200KB gzipped mark.
Has anyone found a frontend JS framework + backend combination with the developer ergonomics of say Rails, Django or Phoenix? Would love to hear.
Earlier quoted context omitted.
>Modern frontend development provides many opportunities for failure I think this is the important thing here. Everything feels less stable, and more prone to breaking, on the modern web. You write some simple HTML, style it with CSS, and write vanilla JS for the parts that need it, and everything feels solid. You start a new project with a framework, and it seems like there is this whole area of your project that is…
At some point, there is an irreducible amount of complexity. At that point, adding things like over-wrought frameworks to “make things easier” for the developer ends up pushing the complexity around, like an air bubble trapped under a screen protector.
IMHO, a lot of frameworks just add extra complexity. Now that we're in the twenties, you don't need nearly the level of browser compatability shims like at the turn of the century. Sure, bleeding edge features need that, but most sites don't need any of that. Certainly news and shopping fit well enough with turn of the century browsers, so everything else is fluff (and retargetting, ugh).
It's the same with a lot of server side frameworks; especially PHP frameworks. I've never been able to grasp what a PHP framework can do that PHP can't, other than burn 50ms of cpu before outputting anything.
