Seems like some variation of this article gets posted every few weeks
Second-guessing the modern web (2020)
31–40 of 309 posts
Re: Second-guessing the modern web (2020)
#32I'm no fan of React, and I'm building a new back-end and front-end that is probably heretical to... well.. everything.
What I have found is that if you have reactivity from your back-end, then front-end reactivity is... easy.
My focus is on board games, but the idea generalized pretty well. As an example, my dumb chat room: https://github.com/mathgladiator/adama-lang/blob/master/demo...
I really need to focus on this, but I believe what we are seeing is an interesting adversarial game between client and server. For instance, if you build your server with a strong API, then clients are going to build tremendous complexity.
My personal bet is that we need a streaming protocol such that applications look more like X11.
Re: Second-guessing the modern web (2020)
#33Earlier quoted context omitted.
React famously claims not to be a framework. Many, myself included, would argue that it is very much a framework in every way that matters.
Which ways are those?
The definition I’ve seen is “you call a library’s code; a framework calls your code.” You don’t decide when to run your components — React does.
Re: Second-guessing the modern web (2020)
#34I choose React for personal projects because it's easy. I'm not too concerned with performance. This article doesnt spend much time on developer experience.
Re: Second-guessing the modern web (2020)
#35As mostly a user that doesn't develop web apps anymore, all this feels very true to me. I'm soooooo sick of interfaces that load an empty useless shell of UX chrome and then slowly trickle in content at some later time, and leave spinners, or even worse, gray boxes simulating text. Send the text content in the initial reply, please! It's bad enough having to wait for webfonts, but when you wait to start doing the slo…
> gray boxes simulating text
This is one of the worst UI trends in the last decade. Mock content gives devs permission to ship slow APIs, and they can even look janky when your API is too fast. It feels like watching a half hour of trailers before the movie starts.
Re: Second-guessing the modern web (2020)
#36As mostly a user that doesn't develop web apps anymore, all this feels very true to me. I'm soooooo sick of interfaces that load an empty useless shell of UX chrome and then slowly trickle in content at some later time, and leave spinners, or even worse, gray boxes simulating text. Send the text content in the initial reply, please! It's bad enough having to wait for webfonts, but when you wait to start doing the slo…
I liked the overview i remember myself having 15 years ago, today there's a new library/API/service to learn everyday to keep even the simplest things working.
Everything is sluggish, everything takes ages to load, to compile, to understand.
Also simple web apps i try to prototype takes ages to make and debug. Anyone else feel this?
It's like something always goes wrong with some dependency, some build process, some versioning error, some service, so you end up using 95% of your time setting up services, reading manuals, and debugging instead of coding which was simpler in the just-post-spaghetti days of web-dev.
I don't know if it's feasible yet but i hope switching to less technologies with more mature JS/CSS and a few minified libraries run locally will work out for me - harder with teams of course.
I don't know what's a good simple backend with the same philosophy, Laravel Lumen maybe? I feel like you need some layer above sql unless you wan't crazy complexity - or maybe a simpler database / api system.
I want the simplest system possible! (who doesn't)
Re: Second-guessing the modern web (2020)
#37Earlier quoted context omitted.
React famously claims not to be a framework. Many, myself included, would argue that it is very much a framework in every way that matters.
Which ways are those?
- It "calls you" (i.e. you never explicitly call your React components, React does)
- It permeates your codebase (e.g. migration from moment to date-fns is something you can realistically do piecemeal, React to Vue or vice versa not so much)
- It enforces a specific architectural paradigm (components) to the exclusion of others (e.g. MVC, MVVM, etc)
- Its direct competitors are frameworks (Angular, Vue, Backbone, Aurelia, Mithril...)
- it is composed of multiple libraries (react, react-dom)
- Experience in it is considered a primary hiring criteria in many shops (which typically isn't the case for libraries)
Re: Second-guessing the modern web (2020)
#38I have a very good idea of how the web used to work 10 years ago. But when I try to learn Modern Javascript frameworks, the tutorials rarely do a good job of explaining that they won't teach me how to create a normal, traditional website, or if it's even possible to create a normal website with the framework. They simply assume that the modern way is the standard way. I want a modern alternative to PHP, but the JS co…
There's nothing particularly weird about client-side rendering (at least, it's no weirder than server-side rendering was in the era when most pages were static data).
It could, of course, be considered "weird" if one's mental model is that patching together document description declarations on-the-fly on a server to later be re-interpreted and rendered on the client is "normal."
Re: Second-guessing the modern web (2020)
#39> "There are decent patterns in the form of GraphQL, but for a React component that loads data with fetch from an API, the solutions have only gotten weirder. There’s great documentation for everything else, but old-fashioned data loading is relegated to one example of how to mock out ‘fetch’ for testing, and lots of Medium posts of varying quality." What is "old-fashioned data loading"?
JSON or XML, using REST or websocket maybe? One request per "page load" is an anti-pattern in SPA's though - you should send all static data once, lazy load large assets like images, and sync only the dynamic non cacheable data.
It kind of depends on your mental model for your user. For mobile devices in many countries outside the United states, you're doing your user no favors shipping them a bunch of static data that they don't actually need yet because you've wasted their bandwidth if they never use it and bandwidth costs money.
Re: Second-guessing the modern web (2020)
#40The amazing part to me is that SPAs are so much harder to do right compared to old-school server-side rendered HTML. One could be forgiven if they think a "simple" SPA is a good starter project, but they'd be very wrong. Async programming (Javascript Promises and/or async/await) is difficult, error-prone, and should be avoided whenever possible. On top of this, understanding how data flows through these SPAs is no small task.
Compare this to server-side rendering where you run some DB queries, generate some HTML based on those results, and send it to the browser to be rendered.
There are some cases where you actually need a rich experience in the browser. In those cases, I would start by seeing if plain old Javascript would work.
In writing this, I definitely feel like a "get off my lawn" guy. But I've just seen too many junior and senior engineers (me included) fall flat on their face trying to use these SPA frameworks.