[HN Gopher] Build your own web framework
___________________________________________________________________
Build your own web framework
Author : jeremylevy
Score : 122 points
Date : 2022-07-29 15:35 UTC (7 hours ago)
(HTM) web link (vercel.com)
(TXT) w3m dump (vercel.com)
| edgyquant wrote:
| 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 wrote:
| I would even take Fastify.
| [deleted]
| marmada wrote:
| 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 wrote:
| That's HN. 8 years ago it would have been how Ethereum will
| make this all redundant
| [deleted]
| steventey wrote:
| this is pretty incredible
| wmfiv wrote:
| I'm struggling with the idea that React is a primitive used to
| build a Web Framework.
| shepherdjerred wrote:
| 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?
| valbaca wrote:
| 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/
|
| You have to dig down deep to find where React is.
| leerob wrote:
| 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
| colordrops wrote:
| 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.
| throw_m239339 wrote:
| 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 wrote:
| 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 wrote:
| You can typecheck anything there exists a typechecker for.
|
| Vue templates are typechecked for example.
| 0x457 wrote:
| 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.
| siddontang wrote:
| 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 wrote:
| 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.
| henning wrote:
| 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 wrote:
| 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.
| koluna wrote:
| 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?
| sebmellen wrote:
| The edge network of a Vercel/Netlify is very hard to replicate
| in cloud as a small startup.
| ushakov wrote:
| you could use Fastly or AWS Cloudfront
| tomnipotent wrote:
| 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.
| bilater wrote:
| And if you are spending your time and resources trying to
| replicate it instead of building your core product you're an
| idiot/forever software engineer clueless about product.
| koluna wrote:
| I wasn't referring to the edge network for _startups_ to
| replicate. I was more wondering how AWS and others can
| replicate Vercel/Netlify and eat their lunch. They have no
| defensible moat as a company.
| quickthrower2 wrote:
| The same reason IBM can't. They are incumbent and have an
| enterprise world view. They are necessarily going to be
| more bloaty. IAM yay!
|
| I use Vercel (and Netlify) and once you spend the 2 minutes
| setting it up you never think much of it again as it just
| does its job.
| ushakov wrote:
| 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 wrote:
| > 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.
| tomnipotent wrote:
| 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.
| skadamat wrote:
| 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
| Cyberdog wrote:
| 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]
| jeshin wrote:
| 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
| lotw_dot_site wrote:
| 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
| mikercampbell wrote:
| I love this so freaking much!!!! Definitely going to be
| playing with this over the weekend!
| edgyquant wrote:
| 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.
| blowski wrote:
| 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.
| [deleted]
| tambourine_man wrote:
| 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-...
|
| This is the web I want and love.
| upupandup wrote:
| not sure how this differs with AWS, you can do more at less cost
| than Vercel
| valbaca wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| I've started playing with AWS App Runner
| (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 and
| 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).
| leerob wrote:
| AWS offers a set of primitives, not frameworks. These low-level
| primitives can be combined to build anything you want. Vercel's
| Build Output API[1] is a level of abstraction higher.
|
| Consider Image Optimization. In this post, there's a
| `/_vercel/image` URL made available to send an image and return
| it compressed with a format like `.webp`, if possible based on
| the browser.
|
| With AWS, this would be a combination of S3 (store images),
| Lambda (compute the image transformations), Cloudfront (CDN),
| and Route53 (DNS). With the Build Output API, the entire
| infrastructure is defined by a JSON object (similar to
| Terraform). I do think the AWS CDK and Copilot[2] are making
| infra-as-code easier, but infra-as-filesystem[3] is an
| interesting twist.
|
| [1]: https://vercel.com/blog/build-output-api
|
| [2]: https://aws.github.io/copilot-cli/
|
| [3]: https://news.ycombinator.com/item?id=32192498
| syastrov wrote:
| Or use imgix for that part
| CSSer wrote:
| Or you could use AWS Amplify.
| upupandup wrote:
| didn't you just describe AWS Amplify? It also integrates with
| Cognito not sure if Vercel offers Auth out of the box.
|
| also I'm not sure if I'm alone in this but I set up
| everything through the web console and then generate CDK or
| Terraform.
| knoebber wrote:
| Thanks, but I'll stick with phoenix + fly.io
| moojd wrote:
| 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.
| DanHulton wrote:
| 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.
|
| [1] https://nodewood.com
| numinoid wrote:
| Just an FYI, your styling doesn't seem to be responsive on an
| iPhone X
| DanHulton wrote:
| Oh thanks for pointing that out! I originally owned a 12
| Pro when I built out that front page, but have since moved
| to a 13 Mini and I'm seeing some responsiveness bugs now,
| too.
| tofuahdude wrote:
| 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.
| aliqot wrote:
| 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.
| iratewizard wrote:
| There aren't many good reasons to make good web content
| like that today. Money? It's way oversaturated with people
| who can live off $400/y. Recognition? Your content will be
| stolen by the previous group a thousand times over. To make
| a difference? There are more rewarding ways to do that if
| you've got the deep industry knowledge.
| moojd wrote:
| I am optimistic though. We are still in the early days of
| server-side javascript. It took 20 years for the greater
| php community to coalesce around a handful of quality
| libraries, frameworks, and solutions to things like user
| management instead of everyone rolling their own or using
| things like '$_GET["pass"] == "foo"' they they grabbed from
| a google search. Node is barely over a decade old. We are
| already seeing patterns mature in the node ecosystem and I
| hope things keep progressing that way.
| tannhaeuser wrote:
| > _early days of server-side javascript_
|
| Err ... Netscape's LiveWire introduced server-side
| Javascript in 1996 even before Java became widely used on
| the server side. The module convention, the (synchronous)
| core modules of Node.js, and its canonical http
| middleware API and express.js/Connect/JSGI is from the
| CommonJS initiative, a co-op of 2000's SSJS framework
| developers [1].
|
| [1]: https://www.commonjs.org/
| Cyberdog wrote:
| This is an "um ackshually" reply. Nobody used LiveWire
| and it died a swift death.
|
| And don't "um ackshually" me about saying "nobody." You
| know what I mean.
| rileymat2 wrote:
| Classic asp also supports JavaScript, it is old and wide
| spread in the bowels of legacy sites.
|
| I thought of node as a victory for async more than
| anything else.
| Cyberdog wrote:
| > I thought of node as a victory for async more than
| anything else.
|
| In terms of server-side development? Async is rather
| useless on the server side. Can't generate a web page or
| JSON blob with the results of a database query until you
| actually get those results from the database. I can see
| the application for something like websockets but I
| presume most Node sites aren't using those.
|
| I figured its success was due to V8 being reasonably
| fast, plus a generation of front-end-centric developers
| coming along who had learned to use JS quite heavily on
| the front end and didn't realize or didn't care that
| better options already existed on the back end.
| lowercased wrote:
| > It took 20 years ... Node is barely over a decade old.
| We are already seeing patterns mature in the node
| ecosystem and I hope things keep progressing that way.
|
| But... much of the earliest web work (PHP, etc) occurred
| in the early days of search. Example of quality code,
| best security practices, etc all were fairly ..
| rudimentary and hard to find.
|
| Just because it took 20 years starting 20 years ago
| doesn't justify 20 years starting from 10 years ago.
| There are infinitely more and better resources for just
| about everything these days.
| bdcravens wrote:
| Many frameworks or languages were fairly well developed
| by a decade's time. Node is 13 years old; compare it to
| Rails circa 2018.
|
| I don't think PHP makes for a great comparison, because
| the web ecosystem was still growing. Node was birthed in
| the age of Github, social media, Stack Overflow, and
| Google. PHP was released in 1995, when search engines
| were still stuck in their infancy and only a small
| percentage of the world was even using the WWW. 20 years
| in PHP's time is like maybe 5 years from 2009.
| bdcravens wrote:
| Another point about PHP: Wordpress, the largest deployed
| PHP app, was released in 2003, PHP's 8 year mark.
| JustSomeNobody wrote:
| It's almost always been like that. When NoSql was the new
| hotness, there was blogspam and fistfights everywhere. When
| DI frameworks were the new hotness, there was blogspam and
| fistfights everywhere. I could go on. Devs see something new,
| learn enough to be annoyingly dangerous and blog like crazy.
| Other devs will glazed-eyed follow along because it makes
| their resume shiny.
| your_username wrote:
| brentm wrote:
| Very accurate. There was a time that I enjoyed this stuff but
| now it just takes too much effort to filter.
| ushakov wrote:
| this 100%
|
| sometimes i Google stuff i already know just to verify i
| remembered it correctly
|
| lately i've been refreshing my memory on Vue JS and this
| website comes up a lot: https://thewebdev.info
|
| the solutions i read there were often incorrect and
| misleading
|
| i can't imagine becoming a developer today, when most of the
| stuff you read on the internet bullsh*t
|
| of course you can browse the docs, but some docs are tedious
| to comprehend when all you're looking for is a simple one-
| line answer
| begueradj wrote:
| Maybe that's the fault of those "who know" but don't write
| and contribute online ?
| LtWorf wrote:
| Those who know are fewer, they get outnumbered by the low
| quality content.
| jjnoakes wrote:
| I don't think so. If you know where to look then good
| content is available, but it doesn't get as widely shared
| because it isn't as interesting to as many people.
| jacobsimon wrote:
| 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.
| Kerrick wrote:
| 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.
|
| [0]: https://adonisjs.com/
| granshaw wrote:
| It's also the most rails like node framework (is it still?),
| which emphasizes DX, expressiveness, convention over
| configuration, etc
|
| which in my book is a plus
| ilrwbwrkhv wrote:
| Unfortunately they just directly copy laravel line by line
| when I had last seen it. It doesn't use the strengths of
| JavaScript as much.
| jstummbillig wrote:
| Any specific criticism?
| rlyshw wrote:
| 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.
|
| [0] https://feathersjs.com/
| ksbrooksjr wrote:
| 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).
|
| [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...
___________________________________________________________________
(page generated 2022-07-29 23:00 UTC)