14 ms·

Build your own web framework

195 points by jeremylevy 4y ago

wmfiv 4y ago
I'm struggling with the idea that React is a primitive used to build a Web Framework.
- colordrops 4y ago
  I'm not a fan of React myself, but it's just a view layer. Or at least that's all it was when I last looked into it a few years back.
- valbaca 4y ago
  React is "just" a library, it doesn't give you everything you need to build out a full-stack or framework. For example, see Clojure's Luminus: https://luminusweb.com/ https://luminusweb.com/ You have to dig down deep to find where React is.
- leerob 4y ago
  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. [1]: https://vercel.com/blog/build-output-api https://vercel.com/blog/build-output-api
- shepherdjerred 4y ago
  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?
- throw_m239339 4y ago
  React can be used as a templating library server-side in a node environment (like handlebars). It's a bit heavy for the task but it works.
  - crooked-v 4y ago
    A huge benefit React (and anything else that uses JSX) has over text-based templating is that you can strictly lint/typecheck JSX because ultimately it's just syntactic sugar over plain JS.
    - likeclockwork 4y ago
      You can typecheck anything there exists a typechecker for. Vue templates are typechecked for example.
- 0x457 4y ago
  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.
  - jokethrowaway 4y ago
    I think the problem is that react is larger than several frameworks but provide 1/10 of the functionality. If react were preact it would feel smaller and people who care about performance would embed it without thinking too much
    - afiori 4y ago
      I have seen it said as "React is neither a library nor a web framework, but a view framework"
upupandup 4y ago
not sure how this differs with AWS, you can do more at less cost than Vercel
- valbaca 4y ago
  I'd say give it a shot. Vercel has a much more reasonable Free Tier, was insanely easy to use and incredibly fast. I had my changes pushed to prod from github in <10 secs I haven't built anything big on Vercel, but from my test drive, I'd be happy to use them in the future, and this is coming from someone who works AT the A in AWS. AWS does NOT make the easy things easy; though you are right, it does make the "more" possible, but it all depends on what you're optimizing.
  - eins1234 4y ago
    Reasonable Free Tier, yes, but "call us" Enterprise pricing starts at a team of 11 people, a fact that is hidden deep in their pricing grid behind a tooltip, which I find distasteful. In what world does a 11 person team qualify as an Enterprise? Though pedanticism aside, my problem is more with the opaque pricing than the naming.
- akmittal 4y ago
  AWS is overwhelming for most of Developers. Also vercel is focusing on ease of deployment for front end, it is also zero config, you can just deploy nextjs, react, svelte, remix apps in matter of minutes. Which is impossible with AWS
  - BenoitEssiambre 4y ago
    I've started playing with AWS App Runner (https://aws.amazon.com/apprunner/ https://aws.amazon.com/apprunner/) which makes things fairly simple. You just point to a github repo, tell it the build command and the run command and it will deploy your project in containers and even load balance and scale up automatically. Now it's not fully baked yet. DNS configuration is broken if you want to use your own domain (see https://github.com/aws/apprunner-roadmap/issues/37 https://github.com/aws/apprunner-roadmap/issues/37 and https://github.com/aws/apprunner-roadmap/issues/65 https://github.com/aws/apprunner-roadmap/issues/65 ) but you can get around that by putting cloudFront in front with just a few more clicks (and you get the benefit of having some of your files cached if you want).
moojd 4y ago
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.
- tofuahdude 4y ago
  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.
  - your_username 4y ago
  - aliqot 4y ago
    Until now I had not found an eloquent way to express that emotion, but you come close. Somewhere around the time node got very popular, I started to notice a lot of impeccably branded (is that the right word? trendy maybe?) websites with tutorials that used all the right buzzwords to get me interested. Once I'd step through the content, it'd be very low quality. Despite the smooth lines and round edges, a lot of them were riddled with inaccuracies, assumptions, unabashed spelling and grammar issues, stolen content and lots of candid offtopic observations.. Not to mention they all loaded very slowly. I used to joke about it mockingly during the early node days that you could judge the trajectory of a project based on the ratio of bytes dedicated to persona and branding vs actual content. Anything passing the 1:2 ratio generally didn't last long.
koluna 4y ago
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?
- ushakov 4y ago
  Vercel is easy to use and comes with batteries 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
  - kylegill 4y ago
    > Vercel is easy to use and comes with batteries On our team, we deploy our web app through Vercel primarily because of this (maybe there is some hype factor bias in there too?..). Everything else we rely on runs on AWS. We don't necessarily need Vercel for any of the edge computing or serverless environments, but the experience of building, previewing, and deploying our app is FAR superior to AWS's Amplify offering because it just works. Trialing Amplify for a few weeks led to a world of hurt, leftover build artifacts in our accounts, failed builds left and right, unreliable preview environments, etc.
- sebmellen 4y ago
  The edge network of a Vercel/Netlify is very hard to replicate in cloud as a small startup.
  - ushakov 4y ago
    you could use Fastly or AWS Cloudfront
    - tomnipotent 4y ago
      Vercel makes app deployment a first-class citizen that's baked into the CDN. Fastly doesn't offer a Vercel/Netlify deploy feature, and AWS requires considerably more work to setup but can easily replicate.
henning 4y ago
This is one of the stupidest, most circuitous ways to get a simple application up and running since the days of the J2EE Pet Shop example.
- jjnoakes 4y ago
  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.
- tr1ll10nb1ll 4y ago
  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.
deleted 4y ago
[deleted]
knoebber 4y ago
Thanks, but I'll stick with phoenix + fly.io
siddontang 4y ago
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).
dfee 4y ago
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.
- rglover 4y ago
  You might dig Joystick: https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick.
  - geoffeg 4y ago
    Is there something explaining what differentiates joystick from other frameworks? The Readme explains what joystick is but not what's unique about it.
    - rglover 4y ago
      Not yet, I'd like to organize something for the 1.0 release. Honestly, I view Joystick as a rival to, not a competitor of the other frameworks. What's unique about it is it's philosophy and approach. The other frameworks take a flawed approach of trying to do as much as possible on the client and ignore the server (unless they can't which leads to wishy-washy approaches like tossing basic stuff to a third-party service or hacks which add complexity). On the code side, there's an obsession with injecting unnecessary abstractions and terminology which only serve to confuse people and ultimately, create a class of developer who doesn't understand how the web works (terms like "serverless" are clever marketing, but mislead developers into thinking they "got it" when they most certainly do not). I view this as a colossal mistake that threatens the long-term stability of the industry. In contrast, Joystick is all about simplicity and developer experience and takes a page from the Rails/Django world. You start up a server (via Express), that server has some routes, when a URL matches a route, that route fetches some data, passes it to a component, and renders some HTML back to the browser. That's it. A component is written using plain HTML, CSS, and JavaScript with an API that a beginner can understand immediately after learning the fundamentals of those languages. To make it more valuable, I take a "batteries-included" approach, adding in all of the basic functionality you need to build an app: wiring of databases to the app, user accounts, uploads, i18n, etc. with more on the way (e.g., I'm adding in support for queues atm). Joystick is for you if you want an unexciting stack to build on that just works and continues to work in perpetuity (after 1.0, the core APIs will be frozen with the only changes being under-the-hood performance/security and additional, optional functionality). This means: the app you build in Joystick today will require the exact same knowledge to maintain 10 years from now. No deprecated APIs or rug pulls in terms of opinions about how to build stuff. My running joke is that "Joystick is the Honda Civic of JavaScript frameworks." Edit: some tutorials if you want to get the gist of how Joystick thinks about stuff... Building and Rendering Your First Joystick Component - https://cheatcode.co/tutorials/building-and-rendering-your-first-joystick-component https://cheatcode.co/tutorials/building-and-rendering-your-f... How to Implement an API Using Getters and Setters in Joystick - https://cheatcode.co/tutorials/how-to-implement-an-api-using-getters-and-setters-in-joystick https://cheatcode.co/tutorials/how-to-implement-an-api-using... How to Fetch and Render Data in Joystick Components - https://cheatcode.co/tutorials/how-to-fetch-and-render-data-in-joystick-components https://cheatcode.co/tutorials/how-to-fetch-and-render-data-...
skadamat 4y ago
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) I guess WASM maybe is one possible solution here
- blowski 4y ago
  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.
- Cyberdog 4y ago
  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.
- deleted 4y ago
  [deleted]
- lotw_dot_site 4y ago
  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! https://lotw.site https://lotw.site
  - mikercampbell 4y ago
    I love this so freaking much!!!! Definitely going to be playing with this over the weekend!
deleted 4y ago
[deleted]
steventey 4y ago
this is pretty incredible
edgyquant 4y ago
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.
- hermanradtke 4y ago
  I would even take Fastify.
  - deleted 4y ago
    [deleted]
marmada 4y ago
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. 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.
- iratewizard 4y ago
  That's HN. 8 years ago it would have been how Ethereum will make this all redundant
  - jerojero 4y ago
    So you probably ought to listen to some degree? 8 years ago investing in ethereum was a very good idea and it definitely shook up the world to some extent. Of course people exaggerate but it's important to see the trends and get an understanding of what people are feeling as a whole. In this case, for all their complaining, people are kind of right. The web is becoming unnecessarily complex for the kinds of applications most of us interact with and there are solutions coming out there that address these pains: see HTMLx or phoenix liveview.
  - aaaaaaaaata 4y ago
    Filecoin-esque networks may.
- tr1ll10nb1ll 4y ago
  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.
tambourine_man 4y ago
What a sad state “modern” web dev is in. 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-tech https://alexcabal.com/posts/standard-ebooks-and-classic-web-... This is the web I want and love.
- hsn915 4y ago
  With modern hardware it is very easy to serve millions of daily users from a single machine with simple software. No one bothers because everyone loves their fast-as-a-snail framework in their favorite slow scripting language and they need massive infrastructure to scale it to serve less than 1k concurrent users. Programmers have no one to blame but themselves.
  - cercatrova 4y ago
    Speak for yourself. Tools these days are much more ergonomic, not to mention faster than ever before. I host a website on DigitalOcean with 0.5 GB RAM and 1 vCPU that can support millions of requests and runs with just a git push. Try doing that in the 90s.
    - joosters 4y ago
      In the 90s, it was all different. Back then, we had to type ‘make install’.
    - tambourine_man 4y ago
      We did and do. Also, git push works with PHP as well. So does rsync. Just put some files on a server with whichever protocol you choose. Easy peasy.
  - intelVISA 4y ago
    I always feel bad when I see novice programmers herded toward frameworks like Flask and Express for uncomplicated API cases, you can take your pick of mature C#, Rust, Java and C++ API frameworks that serve ~7,000,000 responses per second compared to Express' and Flask's ~123,000 and ~15,000 respectively.
pyrossh 4y ago
I prefer the traditional approach. Golang + fly.io is what I use way easier to deploy anywhere you want and closer to your users.
soylentgraham 4y ago
Having this page open for ~10 seconds on my iphone SE (I believe recently hailed as the greatest of phones) crashes safari every time. Can someone able to read the page tell me if this article is ironic or not?
- kaichanvong 4y ago
  Graham, it has the phrase about how you can, "hydrate dynamic components". Likened most to the phrase; Simpsons like, "Der".
rglover 4y ago
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 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).
Joel_Mckay 4y ago
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. Many have found these useful: https://www.phoenixframework.org https://www.phoenixframework.org https://keystonejs.com https://keystonejs.com https://quasar.dev https://quasar.dev https://angular.io https://angular.io
glenngillen 4y ago
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.
- Zandikar 4y ago
  > 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.
avl999 4y ago
Why do front-end developers have such masochistic tendencies to put themselves through this kinda crap?

195 points by jeremylevy 4y ago

wmfiv 4y ago

I'm struggling with the idea that React is a primitive used to build a Web Framework.

colordrops 4y ago
I'm not a fan of React myself, but it's just a view layer. Or at least that's all it was when I last looked into it a few years back.
valbaca 4y ago
React is "just" a library, it doesn't give you everything you need to build out a full-stack or framework. For example, see Clojure's Luminus: https://luminusweb.com/ https://luminusweb.com/ You have to dig down deep to find where React is.
leerob 4y ago
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. [1]: https://vercel.com/blog/build-output-api https://vercel.com/blog/build-output-api
shepherdjerred 4y ago
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?
throw_m239339 4y ago
React can be used as a templating library server-side in a node environment (like handlebars). It's a bit heavy for the task but it works.
- crooked-v 4y ago
  A huge benefit React (and anything else that uses JSX) has over text-based templating is that you can strictly lint/typecheck JSX because ultimately it's just syntactic sugar over plain JS.
  - likeclockwork 4y ago
    You can typecheck anything there exists a typechecker for. Vue templates are typechecked for example.
0x457 4y ago
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.
- jokethrowaway 4y ago
  I think the problem is that react is larger than several frameworks but provide 1/10 of the functionality. If react were preact it would feel smaller and people who care about performance would embed it without thinking too much
  - afiori 4y ago
    I have seen it said as "React is neither a library nor a web framework, but a view framework"

upupandup 4y ago

not sure how this differs with AWS, you can do more at less cost than Vercel

valbaca 4y ago
I'd say give it a shot. Vercel has a much more reasonable Free Tier, was insanely easy to use and incredibly fast. I had my changes pushed to prod from github in <10 secs I haven't built anything big on Vercel, but from my test drive, I'd be happy to use them in the future, and this is coming from someone who works AT the A in AWS. AWS does NOT make the easy things easy; though you are right, it does make the "more" possible, but it all depends on what you're optimizing.
- eins1234 4y ago
  Reasonable Free Tier, yes, but "call us" Enterprise pricing starts at a team of 11 people, a fact that is hidden deep in their pricing grid behind a tooltip, which I find distasteful. In what world does a 11 person team qualify as an Enterprise? Though pedanticism aside, my problem is more with the opaque pricing than the naming.
akmittal 4y ago
AWS is overwhelming for most of Developers. Also vercel is focusing on ease of deployment for front end, it is also zero config, you can just deploy nextjs, react, svelte, remix apps in matter of minutes. Which is impossible with AWS
- BenoitEssiambre 4y ago
  I've started playing with AWS App Runner (https://aws.amazon.com/apprunner/ https://aws.amazon.com/apprunner/) which makes things fairly simple. You just point to a github repo, tell it the build command and the run command and it will deploy your project in containers and even load balance and scale up automatically. Now it's not fully baked yet. DNS configuration is broken if you want to use your own domain (see https://github.com/aws/apprunner-roadmap/issues/37 https://github.com/aws/apprunner-roadmap/issues/37 and https://github.com/aws/apprunner-roadmap/issues/65 https://github.com/aws/apprunner-roadmap/issues/65 ) but you can get around that by putting cloudFront in front with just a few more clicks (and you get the benefit of having some of your files cached if you want).

moojd 4y ago

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.

tofuahdude 4y ago
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.
- your_username 4y ago
- aliqot 4y ago
  Until now I had not found an eloquent way to express that emotion, but you come close. Somewhere around the time node got very popular, I started to notice a lot of impeccably branded (is that the right word? trendy maybe?) websites with tutorials that used all the right buzzwords to get me interested. Once I'd step through the content, it'd be very low quality. Despite the smooth lines and round edges, a lot of them were riddled with inaccuracies, assumptions, unabashed spelling and grammar issues, stolen content and lots of candid offtopic observations.. Not to mention they all loaded very slowly. I used to joke about it mockingly during the early node days that you could judge the trajectory of a project based on the ratio of bytes dedicated to persona and branding vs actual content. Anything passing the 1:2 ratio generally didn't last long.

koluna 4y ago

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?

ushakov 4y ago
Vercel is easy to use and comes with batteries 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
- kylegill 4y ago
  > Vercel is easy to use and comes with batteries On our team, we deploy our web app through Vercel primarily because of this (maybe there is some hype factor bias in there too?..). Everything else we rely on runs on AWS. We don't necessarily need Vercel for any of the edge computing or serverless environments, but the experience of building, previewing, and deploying our app is FAR superior to AWS's Amplify offering because it just works. Trialing Amplify for a few weeks led to a world of hurt, leftover build artifacts in our accounts, failed builds left and right, unreliable preview environments, etc.
sebmellen 4y ago
The edge network of a Vercel/Netlify is very hard to replicate in cloud as a small startup.
- ushakov 4y ago
  you could use Fastly or AWS Cloudfront
  - tomnipotent 4y ago
    Vercel makes app deployment a first-class citizen that's baked into the CDN. Fastly doesn't offer a Vercel/Netlify deploy feature, and AWS requires considerably more work to setup but can easily replicate.

henning 4y ago

This is one of the stupidest, most circuitous ways to get a simple application up and running since the days of the J2EE Pet Shop example.

jjnoakes 4y ago
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.
tr1ll10nb1ll 4y ago
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.

deleted 4y ago

[deleted]

knoebber 4y ago

Thanks, but I'll stick with phoenix + fly.io

siddontang 4y ago

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).

dfee 4y ago

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.

rglover 4y ago
You might dig Joystick: https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick.
- geoffeg 4y ago
  Is there something explaining what differentiates joystick from other frameworks? The Readme explains what joystick is but not what's unique about it.
  - rglover 4y ago
    Not yet, I'd like to organize something for the 1.0 release. Honestly, I view Joystick as a rival to, not a competitor of the other frameworks. What's unique about it is it's philosophy and approach. The other frameworks take a flawed approach of trying to do as much as possible on the client and ignore the server (unless they can't which leads to wishy-washy approaches like tossing basic stuff to a third-party service or hacks which add complexity). On the code side, there's an obsession with injecting unnecessary abstractions and terminology which only serve to confuse people and ultimately, create a class of developer who doesn't understand how the web works (terms like "serverless" are clever marketing, but mislead developers into thinking they "got it" when they most certainly do not). I view this as a colossal mistake that threatens the long-term stability of the industry. In contrast, Joystick is all about simplicity and developer experience and takes a page from the Rails/Django world. You start up a server (via Express), that server has some routes, when a URL matches a route, that route fetches some data, passes it to a component, and renders some HTML back to the browser. That's it. A component is written using plain HTML, CSS, and JavaScript with an API that a beginner can understand immediately after learning the fundamentals of those languages. To make it more valuable, I take a "batteries-included" approach, adding in all of the basic functionality you need to build an app: wiring of databases to the app, user accounts, uploads, i18n, etc. with more on the way (e.g., I'm adding in support for queues atm). Joystick is for you if you want an unexciting stack to build on that just works and continues to work in perpetuity (after 1.0, the core APIs will be frozen with the only changes being under-the-hood performance/security and additional, optional functionality). This means: the app you build in Joystick today will require the exact same knowledge to maintain 10 years from now. No deprecated APIs or rug pulls in terms of opinions about how to build stuff. My running joke is that "Joystick is the Honda Civic of JavaScript frameworks." Edit: some tutorials if you want to get the gist of how Joystick thinks about stuff... Building and Rendering Your First Joystick Component - https://cheatcode.co/tutorials/building-and-rendering-your-first-joystick-component https://cheatcode.co/tutorials/building-and-rendering-your-f... How to Implement an API Using Getters and Setters in Joystick - https://cheatcode.co/tutorials/how-to-implement-an-api-using-getters-and-setters-in-joystick https://cheatcode.co/tutorials/how-to-implement-an-api-using... How to Fetch and Render Data in Joystick Components - https://cheatcode.co/tutorials/how-to-fetch-and-render-data-in-joystick-components https://cheatcode.co/tutorials/how-to-fetch-and-render-data-...

skadamat 4y ago

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) I guess WASM maybe is one possible solution here

blowski 4y ago
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.
Cyberdog 4y ago
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.
deleted 4y ago
[deleted]
lotw_dot_site 4y ago
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! https://lotw.site https://lotw.site
- mikercampbell 4y ago
  I love this so freaking much!!!! Definitely going to be playing with this over the weekend!

deleted 4y ago

[deleted]

steventey 4y ago

this is pretty incredible

edgyquant 4y ago

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.

hermanradtke 4y ago
I would even take Fastify.
- deleted 4y ago
  [deleted]

marmada 4y ago

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. 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.

iratewizard 4y ago
That's HN. 8 years ago it would have been how Ethereum will make this all redundant
- jerojero 4y ago
  So you probably ought to listen to some degree? 8 years ago investing in ethereum was a very good idea and it definitely shook up the world to some extent. Of course people exaggerate but it's important to see the trends and get an understanding of what people are feeling as a whole. In this case, for all their complaining, people are kind of right. The web is becoming unnecessarily complex for the kinds of applications most of us interact with and there are solutions coming out there that address these pains: see HTMLx or phoenix liveview.
- aaaaaaaaata 4y ago
  Filecoin-esque networks may.
tr1ll10nb1ll 4y ago
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.

tambourine_man 4y ago

What a sad state “modern” web dev is in. 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-tech https://alexcabal.com/posts/standard-ebooks-and-classic-web-... This is the web I want and love.

hsn915 4y ago
With modern hardware it is very easy to serve millions of daily users from a single machine with simple software. No one bothers because everyone loves their fast-as-a-snail framework in their favorite slow scripting language and they need massive infrastructure to scale it to serve less than 1k concurrent users. Programmers have no one to blame but themselves.
- cercatrova 4y ago
  Speak for yourself. Tools these days are much more ergonomic, not to mention faster than ever before. I host a website on DigitalOcean with 0.5 GB RAM and 1 vCPU that can support millions of requests and runs with just a git push. Try doing that in the 90s.
  - joosters 4y ago
    In the 90s, it was all different. Back then, we had to type ‘make install’.
  - tambourine_man 4y ago
    We did and do. Also, git push works with PHP as well. So does rsync. Just put some files on a server with whichever protocol you choose. Easy peasy.
- intelVISA 4y ago
  I always feel bad when I see novice programmers herded toward frameworks like Flask and Express for uncomplicated API cases, you can take your pick of mature C#, Rust, Java and C++ API frameworks that serve ~7,000,000 responses per second compared to Express' and Flask's ~123,000 and ~15,000 respectively.

pyrossh 4y ago

I prefer the traditional approach. Golang + fly.io is what I use way easier to deploy anywhere you want and closer to your users.

soylentgraham 4y ago

Having this page open for ~10 seconds on my iphone SE (I believe recently hailed as the greatest of phones) crashes safari every time. Can someone able to read the page tell me if this article is ironic or not?

kaichanvong 4y ago
Graham, it has the phrase about how you can, "hydrate dynamic components". Likened most to the phrase; Simpsons like, "Der".

rglover 4y ago

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 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).

Joel_Mckay 4y ago

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. Many have found these useful: https://www.phoenixframework.org https://www.phoenixframework.org https://keystonejs.com https://keystonejs.com https://quasar.dev https://quasar.dev https://angular.io https://angular.io

glenngillen 4y ago

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.

Zandikar 4y ago
> 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.

avl999 4y ago

Why do front-end developers have such masochistic tendencies to put themselves through this kinda crap?