Live data from Hacker News

Build your own web framework

vercel.com

141–150 of 155 posts

Re: Build your own web framework

#141

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 so…

> 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 experienc…

Both can be true at once. Huge corporations can be exploiting people for their data even while they develop new techniques to make their web applications more appealing and useful. Cookie banners can plague every website and those same websites can be more intuitive to use than ever before.

I would say that the shift has been not just toward prioritizing end users but also towards prioritizing profits. The point is that developer experience is much lower down on the priorities list than it was, because we're now paid enough money that we'll suck it up and do what the business needs rather than doing the thing that's easiest for us.

Re: Build your own web framework

#142
post #81

Earlier quoted context omitted.

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.

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.

You're completely ignoring the fact that most applications will never see 15,000 requests per second. Most applications are internal apps used by a few hundred employees during working hours, or small niche SaaS products used for specific tasks by a limited group of dedicated users.

If I'm working on one of those products, prioritizing requests per second over any other factor is bad engineering, period. That's not to say that I wouldn't end up choosing a mature compiled language in the end, but there are plenty of reasons why I might not, and you have no right to judge without knowing my constraints.

Re: Build your own web framework

#143

Earlier quoted context omitted.

Make other database requests, or return the responses derived from prior requests. Or just anything else waiting in the event loop queue, including queueing more work. You can think of the concurrency model like green threads with only one thread available, or actors in a single system process. Edit to elaborate: yield/suspend is key here. The way it works is yielding/suspended calls have their outstanding work put b…

I'm trying to envision a situation where you'd want to make more than one database request at the same time. Like I guess on a blog or something, you could load the user record of the current user and then load the blog post details at the same time, but then there's a chance that the user doesn't have permission to view that blog post and then the request for the post has gone to waste, right? It goes against my ins…

It is about multi request concurrency/parallelism.

If 20 users log in at the same time node and php would behave very differently.

Php would start 20 processes/threads and execute each in independently.

Node would dispatch 20 Request events to the event loop in the same process.

I will not argue the advantage of server-side async, but here it is clear that node needs it, as those 20 database queries will be executed from the same thread. Without async the 20th user would have 20 times as much latency as the first.

Re: Build your own web framework

#144

Earlier quoted context omitted.

You might dig Joystick: https://github.com/cheatcode/joystick .

Is there something explaining what differentiates joystick from other frameworks? The Readme explains what joystick is but not what's unique about it.

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

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

Re: Build your own web framework

#145

Earlier quoted context omitted.

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 permission…

This is exactly why I used RoR for a recent freelance project which required a fairly simple (but full featured, user accounts etc) backend despite being a JS developer for the last 15 years and not really having any Ruby experience. None of the Node options seemed to cover all the bases and/or inspire trust, and I didn’t feel much like piecing together a bunch of random modules for a small project. Overall I guess i…

I'd kind of like to try Ruby on Rails but python was my first language and I was very, very green when I first tried to make a website so Django was a natural choice. It's served me well. I think remix.run is a pretty great framework, all things considered. You could always use Django or RoR to manage the database and use Prisma to inspect the schema. There are some downsides to that (you have to mess with bcrypt to get passwords to work the same on the node and python side), but might be a good compromise.

Re: Build your own web framework

#146

Earlier quoted context omitted.

> I'm trying to envision a situation where you'd want to make more than one database request at the same time. Because I have two requests active at the same time and the second one which arrived shouldn’t wait for me to stand around doing nothing while I wait for the database to serve the first. > Like I guess on a blog or something, you could load the user record of the current user and then load the blog post deta…

> Here one user represents 2+ events, both of which should fail. This wasn’t part of my original explanation but yielding does give you the opportunity to fail both simultaneously. Albeit in this case it’s just concurrency broadly. Why is that against your instincts, if you know that one request’s failure implies the other will also fail? Why should that user wait in line to get the same error after another cycle of…

A typical Node service would probably be designed very similarly to your description of the PHP equivalent. The difference in a typical scenario is that, should another request come in while the first query for user data is in flight, the same process would initiate its first query for user data concurrently. Both requests are still pending but suspended until the IO they depend on is available (and until whatever other synchronous work on the event loop yields or completed).

The scenario you describe, performing multiple queries for the same request in tandem, certainly isn’t incorrect. It’s a less common design, but one which might make sense depending on the workload. An example where I’d choose that design: both queries are slow individually, but not significantly slower queried concurrently. Even if the query for blog post data turns out to be wasted work for one request, it might halve the time to serve another request.

When I say which is more common, it’s probably more a matter of the mental model of the human who implemented it. Fulfilling a request as a series of steps versus a set of concurrent steps only becomes a matter of correctness when one of those steps is dependent on another (and even then only if there’s no other reasonable way to address their dependency afterwards).

I’ll add that designing for concurrency this way often leads to better design overall. It helps guide towards minimizing dependencies (or at least minimizing shared state) between functions. Which in turn isn’t just easier to reason about, but also easier to scale should you want (say) to move some expensive function out to its own service or worker.

Re: Build your own web framework

#147

Earlier quoted context omitted.

Interesting. Based on this series of responses, you moved from "async is useless" to "actually, I don't actually know what async processes can do, and what happens between each process." It implies to me that your initial comment was written with little understanding of what you purported to denigrate.

This isn’t helpful. They very clearly and frankly asked. Don’t shame people for not knowing something you already know, they’ll very probably be turned off from learning it.

It is a different story if they asked in good faith, but they clearly started their initial comment as a derisive declaration of something being useless, so it sounded to me that they had no real intention of actually learning.

Re: Build your own web framework

#148
post #124

Earlier quoted context omitted.

If it's only one file, you could just go to the Babel website where they have a playground and paste it in, voilà, converted for older browsers. Now place the output file wherever you want.

Not sure if they edited their comment (although it seems unlikely given that your comment was four hours later), but that sounds exactly like what they said they did. Maybe I'm old-fashioned, but the idea that I need to upload a plaintext file to have it converted to another plaintext file so I can download it instead of just having a command to run locally seems almost surreal.

There is a command to run locally, `babel`. It works in the command line as well as part of a build tool. It seemed me that the parent however didn't want to spend more time learning all that if they needed to convert just one file.

Re: Build your own web framework

#149
post #114

Earlier quoted context omitted.

A framework is a boxed architecture. That appeals to some people more than others. Architecture is just a matter of organization. Ease with basic organization is what separates experts from laymen in any field.

>Architecture is just a matter of organization. Have to say, I think that's somewhat oversimplifying. Architecture is a lot more than organization. It's also a broad and deep understanding of external and internal resources, the creative design process, corporate vision, industry insight, risk analysis, project management, stakeholder politics, marketing, and technology. It's very possible to be super organized but s…

Right, if we want to paint it with a broad brush, it’s system design.

A software architect seems to be a dirty word in some parts, but it’s really just someone who has deep knowledge of various tools, services, etc, and are able to aptly design a system to serve the businesses needs without under/over-architecting.

Re: Build your own web framework

#150

Earlier quoted context omitted.

> 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 experienc…

Both can be true at once. Huge corporations can be exploiting people for their data even while they develop new techniques to make their web applications more appealing and useful. Cookie banners can plague every website and those same websites can be more intuitive to use than ever before. I would say that the shift has been not just toward prioritizing end users but also towards prioritizing profits. The point is t…

> Both can be true at once.

Which is why I asserted both statements to be true side by side. It was in fact the entire point of my comment. Things are worse overall for the end user as a result of both divergent experiences being simultaneously true.

Post reply on HN