It’s like they are either getting old and don’t like to keep up with modern web development but it’s easy to see this behavior elsewhere too.
Aversion towards new way of doing things where people feel like the old way was just working is too common and predictable sometimes. “Things work” using old way, but, does that mean that no optimizations are to be made? Optimizations further lead to reiteration of the way we do things.
Also, an individual can stick to their old way of doing things but to rant over the new way is just- tasteless.
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.
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.
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.
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.
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.
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.
> there has been a shift to prioritize the experience of the end users
I was mostly on the same page with you till I got to this phrase. My immediate reaction to this was laughing in disbelief. The internet has never been more outright hostile to end users than it is today, even when the underlying intent is morally good (Would you like some cookies?).
Devex and the web in general (back end, front end, user experience, etc) is very different than it was. It's better in many ways. It's worse in many ways too. To assert that we've "sacrificed" devex for the sake of the end user is laughable though.
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.
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).
It's because almost no one uses React the way it was created, but ultimately depends on what you mean by Web Framework. I don't think react includes enough to be a web framework.
It's a library to make components for web pages. Notably, Facebook's chat window. Later, one people decides that it's a good idea to have one giant component mounted at `body` or `div` directly underneath the body that would hold everything else and even the sun.
React didn't have much for state management and doesn't have anything for navigation support. It was released in 2013 and Create React App, which is actually a framework, was released only in 2016. Even that isn't a framework, but rather a template.
Now, Next.js and Gatsby are actually frameworks based on React. Backbone.js is an MVC framework.
You could swap out React here for another solution (e.g Svelte) and it would mostly read the same. The Build Output API[1] mentioned is how React, Vue, Svelte, and their "metaframeworks" run on Vercel today.
I think it’s easier to consider when you look at the frameworks that provide React + some other features. Of course you could swap React with something else, or write your own rendering + state management.
I think it’s similar to how Java web servers often use the library Netty under the hood. Why re-solve a problem?
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)
This is exactly why I started building "Linux on the Web" about a decade ago. LOTW is meant to completely abstract away all the weird "browser-isms" that seem to overwhelm people like you who just want to sit down and do Plain Old Programming.
I am currently in the midst of supporting a good selection of game console emulators (GB, NES, and SNES are already working), and WASM is indeed a blessing for that!
If you want to, you already can. It's what's so great about the web, you don't have to use anything beyond HTTP and HTML. But each of those layers introduces its own costs and benefits, so you can pick and choose to get what you want.
Well, when you start with a "tutorial" (or whatever you call this thing) like this one, you get a false idea of just how complex web development actually is.
I once wrote an e-book on how to use the now mostly defunct Kitura web framework. It started with teaching you how to make a one-file script to output a "hello world" message. After that it talked about using templates and database connectivity and all that, very iteratively. Client-side scripting or "serverless functions" (whatever those are) were not a part of it at all.
on the note of babel, I don't usually do front end stuff but the other day I wanted to transpile one single javascript file to support older browsers, one time and then never again. I tried for like an hour and I could not figure out how to do it, without setting up like a whole environment/pipeline for it. My expectation going into it was "surely there's some sort of command that just lets you do input file -> output file", but i struggled until I just gave up and used their web demo thing to do it (which tbh I should have just done to begin with, but I had not anticipated it would be so difficult).
I mean I'm sure it's possible somehow, but it sure isn't obvious. And I get that this is not at all the usual use case for it, but still
> Do we ever think we'll collapse all of the complexity layers for programming on the web?
Yes, and this is what Vercel has been doing with Next.js. Used to be that I'd had to manually maintain a bunch of different tools to get them to work together, and then if I wanted to add, say, automatic image compression, I'd have to figure out how to connect that to everything else.
Nowadays, I just let Next.js handle it. I don't even have to think about (and remember, for every new project) what optimisations would be good ideas, as they'll do it for me.
I think the problem is there aren’t standards. For backend we have decades of proven architecture but for frontend people are still trying to hammer out the philosophy.
This is precisely the most common mistake doomed project managers make.
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.
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.
Its pretty hard to trust a lot of the eng content on the web right now; so much blogspam, self promo stuff from frankly underqualified people who are trying to build up a profile to get hired.
Somehow I still don't feel that way about StackOverflow. Google and random results though... yikes.
I am still holding my breath for a Node framework that does everything Django does for me.
Honestly, we are most of the way there but for three holdouts; 0 config auth, easily extensible admin, and migrations.
User stuff isn't so bad with bcrypt but I'd really like to be able to type `framework create superuser` and `framework create user` instead of fiddling with user access and re-imaging user groups and permissions for the hundredth time.
Admin stuff always seems to be something relegated to a separate tool. No, please, please, please include it in the framework.
Most frameworks have you choose your own ORM (which is fine if they consistently use the same one in documentation), but for some reason Node ORMS always treat migrations as an afterthought or second class citizen (if they even consider it). Changing table structures in development to add a new column? Half of them just say, sorry, we're going to have to blow that away. The rest have either manual migrations or partially automated migrations written in the SQL dialect you happen to be using during development. My favorite of the lot I've seen so far is Prisma and even they have recently indicated they don't want to support transactions in migrations because they don't want to give you a "false sense of security" (well yeah, how about a real sense of security?). To be fair, even in python land Django is really the only one to have ever gotten migrations 100% right.
This is largely why I built Nodewood [1]. Every time I wanted to start a new project, almost always a SaaS idea, I'd skip over the "boring stuff" like building user management, subscription management, teams, admin, all that, to get to the meat of the business logic, to make sure I had a valid idea. But I still needed all that stuff eventually, so I'd have to lose time later building it all in!
So I decided to just build it all once so I could re-use it, and then I found that others had the same problem and are happy to pay a reasonable amount to have it solved for them, and now it's doing pretty okay for itself.
It did end up taking a lot longer and involving a lot more work than I expected, but I figure that's alright, it just means a more-reliable base to start from each time.
The only framework of that scale and quality I’ve found in node-land is Adonis [0]. It’s why I chose Adonis 5 for my latest product—it needed to be built in JS or TypeScript but I wanted the “batteries included” feel of Laravel or Rails.
Im building with featherjs[0] right now and I love it. Jwt, user handling, routing, and (most notably to me) real-time functionality is all built in. Probably the most rails-like backend framework I’ve worked with in Node so far.
The fact that googling 'node user login' returns an insecure result is more indicative of the quality of Google's search results than it is of Node. Node has had a built in password hashing function since before it even hit version 1.0 (pbkdf2) [1]. It also has a built in timing safe comparison function for safely comparing values without leaking data via timing attacks [2]. The crypto module is actually pretty extensive.
If you're looking for a traditional web framework (something similar to Flask or Sinatra) I would take a look at Hapi (which has no third party dependencies and is maintained by one of the original authors of the oAuth spec), or you could always try Express (the most popular Node framework), or Fastify (the fastest Node framework).
Sorry but that’s a pretty un-generous take on the state of the Node ecosystem. There’s so many mature solutions for all of these problems and tons of great examples online.
That said, I agree that in the Vercel/Next universe, everything on the backend seems to be an afterthought.
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.
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.
I’m not sure we’re really achieving any higher level abstraction on our technologies.
Maybe it is and maybe it isn't, but your comment would be a lot more useful to the discussion if you pointed out specific issues and/or ways of doing things differently that you think are better, and why.
It quite literally starts with, "ever wondered what it takes to build your own web framework that also deploys to edge and serverless infrastructure?”. They are not suggesting you to do this to get your “simple application up and running”.
If you dislike it so much, simply don’t use it. I don’t use it either but calling it stupid is not a stretch. It’s worse.
For people concerned about the growing complexity of all this stuff, I'd appreciate you taking my approach for a spin: https://github.com/cheatcode/joystick. It's intentionally boring and simplistic.
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?
At the end of the day, even when it's running sever-side or on the edge, it still all exists to deliver a front-end experience. Vercel makes delivering such an experience more palatable. This includes isolated environments that can easily be shared and a CDN-as-default deploy model. It's like someone sprinkled a little Heroku magic on a specific front-end deployment workflow.
[+] [-] marmada|3 years ago|reply
The commenter's proposed solution was WASM. Wasm doesn't solve the issues in this post. What does this post talk about:
- serving content from the edge (wasm doesn't do anything there) - asset optimization (wasm doesn't help)
- pre-rendering complex pages to static HTML+css (wasm doesn't help)
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.
[+] [-] tr1ll10nb1ll|3 years ago|reply
Aversion towards new way of doing things where people feel like the old way was just working is too common and predictable sometimes. “Things work” using old way, but, does that mean that no optimizations are to be made? Optimizations further lead to reiteration of the way we do things.
Also, an individual can stick to their old way of doing things but to rant over the new way is just- tasteless.
[+] [-] iratewizard|3 years ago|reply
[+] [-] glenngillen|3 years ago|reply
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.
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.
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.
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.
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.
[+] [-] Zandikar|3 years ago|reply
I was mostly on the same page with you till I got to this phrase. My immediate reaction to this was laughing in disbelief. The internet has never been more outright hostile to end users than it is today, even when the underlying intent is morally good (Would you like some cookies?).
Devex and the web in general (back end, front end, user experience, etc) is very different than it was. It's better in many ways. It's worse in many ways too. To assert that we've "sacrificed" devex for the sake of the end user is laughable though.
[+] [-] tambourine_man|3 years ago|reply
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.
I really can’t understand the appeal of what, to my eyes, amount to endless layers of needless complexity.
I wish articles such as this one were more common:
https://alexcabal.com/posts/standard-ebooks-and-classic-web-...
This is the web I want and love.
[+] [-] siddontang|3 years ago|reply
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).
[+] [-] wmfiv|3 years ago|reply
[+] [-] 0x457|3 years ago|reply
It's a library to make components for web pages. Notably, Facebook's chat window. Later, one people decides that it's a good idea to have one giant component mounted at `body` or `div` directly underneath the body that would hold everything else and even the sun.
React didn't have much for state management and doesn't have anything for navigation support. It was released in 2013 and Create React App, which is actually a framework, was released only in 2016. Even that isn't a framework, but rather a template.
Now, Next.js and Gatsby are actually frameworks based on React. Backbone.js is an MVC framework.
[+] [-] colordrops|3 years ago|reply
[+] [-] leerob|3 years ago|reply
[1]: https://vercel.com/blog/build-output-api
[+] [-] throw_m239339|3 years ago|reply
[+] [-] valbaca|3 years ago|reply
For example, see Clojure's Luminus: https://luminusweb.com/
You have to dig down deep to find where React is.
[+] [-] shepherdjerred|3 years ago|reply
I think it’s similar to how Java web servers often use the library Netty under the hood. Why re-solve a problem?
[+] [-] skadamat|3 years ago|reply
I guess WASM maybe is one possible solution here
[+] [-] lotw_dot_site|3 years ago|reply
I am currently in the midst of supporting a good selection of game console emulators (GB, NES, and SNES are already working), and WASM is indeed a blessing for that!
https://lotw.site
[+] [-] blowski|3 years ago|reply
[+] [-] Cyberdog|3 years ago|reply
I once wrote an e-book on how to use the now mostly defunct Kitura web framework. It started with teaching you how to make a one-file script to output a "hello world" message. After that it talked about using templates and database connectivity and all that, very iteratively. Client-side scripting or "serverless functions" (whatever those are) were not a part of it at all.
[+] [-] jeshin|3 years ago|reply
I mean I'm sure it's possible somehow, but it sure isn't obvious. And I get that this is not at all the usual use case for it, but still
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] Vinnl|3 years ago|reply
Yes, and this is what Vercel has been doing with Next.js. Used to be that I'd had to manually maintain a bunch of different tools to get them to work together, and then if I wanted to add, say, automatic image compression, I'd have to figure out how to connect that to everything else.
Nowadays, I just let Next.js handle it. I don't even have to think about (and remember, for every new project) what optimisations would be good ideas, as they'll do it for me.
[+] [-] edgyquant|3 years ago|reply
[+] [-] Joel_Mckay|3 years ago|reply
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.
Many have found these useful:
https://www.phoenixframework.org
https://keystonejs.com
https://quasar.dev
https://angular.io
[+] [-] moojd|3 years ago|reply
[+] [-] tofuahdude|3 years ago|reply
Somehow I still don't feel that way about StackOverflow. Google and random results though... yikes.
[+] [-] DangitBobby|3 years ago|reply
Honestly, we are most of the way there but for three holdouts; 0 config auth, easily extensible admin, and migrations.
User stuff isn't so bad with bcrypt but I'd really like to be able to type `framework create superuser` and `framework create user` instead of fiddling with user access and re-imaging user groups and permissions for the hundredth time.
Admin stuff always seems to be something relegated to a separate tool. No, please, please, please include it in the framework.
Most frameworks have you choose your own ORM (which is fine if they consistently use the same one in documentation), but for some reason Node ORMS always treat migrations as an afterthought or second class citizen (if they even consider it). Changing table structures in development to add a new column? Half of them just say, sorry, we're going to have to blow that away. The rest have either manual migrations or partially automated migrations written in the SQL dialect you happen to be using during development. My favorite of the lot I've seen so far is Prisma and even they have recently indicated they don't want to support transactions in migrations because they don't want to give you a "false sense of security" (well yeah, how about a real sense of security?). To be fair, even in python land Django is really the only one to have ever gotten migrations 100% right.
[+] [-] DanHulton|3 years ago|reply
So I decided to just build it all once so I could re-use it, and then I found that others had the same problem and are happy to pay a reasonable amount to have it solved for them, and now it's doing pretty okay for itself.
It did end up taking a lot longer and involving a lot more work than I expected, but I figure that's alright, it just means a more-reliable base to start from each time.
[1] https://nodewood.com
[+] [-] Kerrick|3 years ago|reply
[0]: https://adonisjs.com/
[+] [-] rlyshw|3 years ago|reply
[0] https://feathersjs.com/
[+] [-] ksbrooksjr|3 years ago|reply
If you're looking for a traditional web framework (something similar to Flask or Sinatra) I would take a look at Hapi (which has no third party dependencies and is maintained by one of the original authors of the oAuth spec), or you could always try Express (the most popular Node framework), or Fastify (the fastest Node framework).
[1] https://nodejs.org/dist/latest-v18.x/docs/api/crypto.html#cr...
[2] https://nodejs.org/dist/latest-v18.x/docs/api/crypto.html#cr...
[+] [-] jacobsimon|3 years ago|reply
That said, I agree that in the Vercel/Next universe, everything on the backend seems to be an afterthought.
[+] [-] edgyquant|3 years ago|reply
[+] [-] dfee|3 years ago|reply
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.
I’m not sure we’re really achieving any higher level abstraction on our technologies.
[+] [-] rglover|3 years ago|reply
[+] [-] henning|3 years ago|reply
[+] [-] jjnoakes|3 years ago|reply
[+] [-] tr1ll10nb1ll|3 years ago|reply
If you dislike it so much, simply don’t use it. I don’t use it either but calling it stupid is not a stretch. It’s worse.
[+] [-] soylentgraham|3 years ago|reply
Can someone able to read the page tell me if this article is ironic or not?
[+] [-] rglover|3 years ago|reply
Good ol' fashioned HTML, CSS, and full-stack JavaScript (Node.js on the back-end).
[+] [-] koluna|3 years ago|reply
[+] [-] sebmellen|3 years ago|reply
[+] [-] tomnipotent|3 years ago|reply
[+] [-] ushakov|3 years ago|reply
the primary decision driver here is hype factor
it’s just more fashionable to use Vercel than AWS
much of web development today is like this
[+] [-] knoebber|3 years ago|reply
[+] [-] pyrossh|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] avl999|3 years ago|reply
[+] [-] upupandup|3 years ago|reply
[+] [-] steventey|3 years ago|reply