This is too funny. I predicted that when I entered this post the first comment would be HN people bemoaning complexity. And indeed it was.<p>The commenter's proposed solution was WASM. Wasm doesn't solve the issues in this post. What does this post talk about:<p>- serving content from the edge (wasm doesn't do anything there)
- asset optimization (wasm doesn't help)<p>- pre-rendering complex pages to static HTML+css (wasm doesn't help)<p>More broadly, minimizing network trips, pre-fetching data, etc. etc. these are all things where Wasm won't help any more or less than JS.
Look, I can sometimes be pretty quick to bemoan the state of modern web dev. I don't do it enough these days to be able to keep up with the current trend. So once or twice a year when I get the itch I inevitably spend more time than I should screaming about having to learn React's latest way to do some new thing, or that everyone has switched from npm to yarn and back again, or... there's always something. Lots of somethings.<p>The discourse on HN whenever this topic comes up is tiresome though and not at all to the level you'd expect on most topics from this audience. It's the unfiltered dumping of that emotional reaction I outlined above.<p>You know what? You can still build things the old way! Nobody has taken that away. It still works exactly as you'd expect. Do a bunch of HTML, lay it all out using tables, do inline styling. Host it on an Apache server. It'll be fine.<p>To think these were the glory days of dev though just washes away the fact that it was "good enough" for the subset of people that were lucky enough to have access to the internet back then. who were probably only a hop or two away from an academic backbone that was servicing them. Who, if you were in a relatively remote part of the planet like myself, would likely have a caching proxy server in there to improve the performance because most universities being able to cache the content of a huge part of the internet was a totally feasible undertaking back then.<p>But now half the planet is connected. With huge variance in the speed and latency on which they connect, huge variance in the types of devices they're using, incredibly distributed relative to where the content is served, and with entirely new expectations for the type of content they want and the way they expect to interact with it.<p>Sure, modern dev has lots of room for a simpler devex. Read through the OP though and you'll see it's because there has been a shift to prioritize the experience of the end users above that of the developers. That's what those list of features are for. You're still free to ignore it and build stuff the old way, just accept whose needs you're putting first in the process.
What a sad state “modern” web dev is in.<p>I’m glad that I’m living in a much faster and simpler world, but I fear, for end users and developers alike, that it is an ever shrinking one.<p>I really can’t understand the appeal of what, to my eyes, amount to endless layers of needless complexity.<p>I wish articles such as this one were more common:<p><a href="https://alexcabal.com/posts/standard-ebooks-and-classic-web-tech" rel="nofollow">https://alexcabal.com/posts/standard-ebooks-and-classic-web-...</a><p>This is the web I want and love.
As a back-end engineer focusing on distributed database, I nearly have no knowledge of web development. I rarely write JS, can't tune CSS, etc.<p>But when I met Next.js and Vercel, I found that they are very friendly to beginners. I can build the demos on the web, more beautiful and intuitive (Previously, I had only to build demo on the console).
Do we ever think we'll collapse all of the complexity layers for programming on the web? Coming from other languages, I'm finding that the agreed-upon web standards make development super hard (we have to collectively build these towers of babel on top of them, since we can't fix the underlying stuff)<p>I guess WASM maybe is one possible solution here
This is precisely the most common mistake doomed project managers make.<p>There are aspects to modern web interfaces which one cannot know a priori. Thus, the first design will almost always be implemented incorrectly, and it is usually better to choose an existing framework.<p>Many have found these useful:<p><a href="https://www.phoenixframework.org" rel="nofollow">https://www.phoenixframework.org</a><p><a href="https://keystonejs.com" rel="nofollow">https://keystonejs.com</a><p><a href="https://quasar.dev" rel="nofollow">https://quasar.dev</a><p><a href="https://angular.io" rel="nofollow">https://angular.io</a>
This is a nice overview of modern front-end development but I'm constantly disappointed with what 'web framework' means in node-land. None of these things are strictly necessary when building a web app but authz/authn, user management, databases, server-side logic vs client-side logic, are pretty much always needed. When I see the phrase 'web framework' these are the things I am interested in seeing and they all seem to be treated as afterthoughts in the node community. Most tutorials either point you to paid/proprietary services or to really bad local solutions like back in the hotscripts days of php. If you google 'node user login' the first tutorial has you storing a password in plain text and checking the password with the equivalent of '=='. The first result when googling the same for php, python, and ruby all returned solutions using a hash.
React made me like frontend for the first time since I was writing html by hand with maybe some PHP. Next has made me love full stack again, I just wish the api server was express by default.
I’ve been looking a lot at RedwoodJS, but it doesn’t seem to be “just right”. Don’t know if I’m bike-shedding, either.<p>I do think React is a requisite for a rich application (not blog). I think auth + DB + deploy + fe/be in one asset is challenging. I certainly get why folks build their own constantly. But you burn out before you make any real progress.<p>I’m not sure we’re really achieving any higher level abstraction on our technologies.
Having this page open for ~10 seconds on my iphone SE (I believe recently hailed as the greatest of phones) crashes safari every time.<p>Can someone able to read the page tell me if this article is ironic or not?
For people concerned about the growing complexity of all this stuff, I'd appreciate you taking my approach for a spin: <a href="https://github.com/cheatcode/joystick" rel="nofollow">https://github.com/cheatcode/joystick</a>. It's intentionally boring and simplistic.<p>Good ol' fashioned HTML, CSS, and full-stack JavaScript (Node.js on the back-end).
The more I see these announcements, the more I wonder - what is the appeal of something like Vercel and the likes? On the surface it seems like AWS/GCP/Azure/whichever big cloud provider can replicate literally everything they build within their infrastructure quite easily. Why host your core infra in a BigCo cloud and then the site on Vercel?