7 ms·

Since a bunch of people are setting up a straw-man to criticize this post for "not just serving plain HTML" I'll share my opinions on this. Almost nobody is go

Since a bunch of people are setting up a straw-man to criticize this post for "not just serving plain HTML" I'll share my opinions on this. Almost nobody is going to use Deno to serve a basic HTML site with less than a dozen pages, they are going to use it to build a monolith application to get content from a database, or a service, then generate server-rendered pages, and also host an API from the same codebase, or something similar. Setting up a monolith application means using something like Ruby-on-Rails, Django, Spring, ASP.net, or rolling your own with a Node.js backend serving a SSR front-end, or hydrating React views. If you haven't experienced this already, you will come away with one of two conclusions. 1. Wow, this is so much fun, as long as I stay on the happy path of ... Rails ... Django ... ASP.net. 2. Wow, setting up all these moving parts really sucks' I'm mostly writing configuration files, and then Googling the error messages when I inevitably screw something up. What I think Deno is trying to do is make the process of getting a server side rendered application with modern tooling running with minimal ceremony, while still enabling the developer to customize the system and build things that are not covered by the documentation guides. In addition, their solution is one that can be more easily hosted on edge servers than most other options out there. I'm glad they are doing it, because it's a sorely lacking area of modern web development. They only other people who are taking this on in a meaningful way that I am aware of are Remix. I would be happy for there to be more entrants into this field. Best of luck to everyone out there.

rglover 5y ago
> Setting up a monolith application means using something like Ruby-on-Rails, Django, Spring, ASP.net, or rolling your own with a Node.js backend serving a SSR front-end, or hydrating React views. https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick
colordrops 5y ago
You can use a service worker proxy to cache and serve files to an application, which keeps things both fast and also with raw uncompiled html and JS file.
dodyg 5y ago
ASP.NET Core is pretty minimal in ceremony nowadays. You can easily do single file web development. https://github.com/dodyg/practical-aspnetcore/blob/net6.0/projects/sfa/wiki/Program.cs https://github.com/dodyg/practical-aspnetcore/blob/net6.0/pr...
masa331 5y ago
Your focus on things being "modern", which is no indicator of value except for hipsters and recruiters, made you forget about the third conclusion with which you might come away from setting up a monolith application: 3. Wow, this actually works. I am so productive and i can actually get my work done quickly, the same way as hundreds of thousands other normal developers out there. And then i can have a free time and mind free of stressing over what's cool or not It's about what you value. If it is your time and happinnes, if you mainly want to just build stuff to solve real world problems, then choosing good old monolith application will get you there safe and fast in 90% of situations. If you value to be hip and cool, then Deno, hydrating whatever, edge servers and sorely lacking areas of modern web development will 100% get you there.
- Dangeranger 5y ago
  My thoughts weren't really meant to be a condemnation of monolithic web app frameworks, just a summary of my conclusions after using them for years. The reasons I have for justifying use of React, JSX, GraphQL, etc. have nothing to do with being "hip and cool" and everything to do with happiness and productivity. Using modern tools is both more enjoyable and more productive in my experience, as someone who used Ruby-on-Rails with templated pages for four years.
- replygirl 5y ago
  > I am so productive and i can actually get my work done quickly, **the same way as hundreds of thousands other normal developers out there.** i seek out new technologies because i want to be _more_ productive than the average engineer. i don't believe there are hundreds of thousands of developers who are more productive than someone who makes an effort to learn stuff like deno, vite, unjs, fauna, etc. as soon as possible
- DecoPerson 5y ago
  “Modern” also means the solution may benefit from reflection on past solutions. The accounting software I use, written in 2004, evolved over the decades starting from 1980s software. It all works (hence, I’m using it now), but comparing the user experience and source code of various features developed at various times reveals a lot about what “modern” means. Here’s a few things: Standardisation: Modern software tends to use proven designs, such as SQL over a bespoke query language. Performance: The strictness of ABIs and APIs makes it difficult to restructure for the sake of optimisation without introducing undesirable breaking changes. Old codebases may be essentially “frozen” and stuck on old versions of libraries. Fresh software can use the latest versions of libraries, with their new APIs & ABIs and whatever optimisations come along. Fundamental coding improvements: Old languages don’t have ergonomic, performant closures (see lambda functions in Python). New languages do (see arrow functions in ES6). Replace “closures” with any core language feature, like null coalescing, match statements, object & array destructing (or even better: pattern matching assignment), or hygienic macros. (Let’s not discuss async/await as that doesn’t lie in the “unquestionably better” column.) Better error messages & debugging: Over time, we collectively as developers have figured out what helps and what hinders when trying to track down troubles. —— I also build stuff that solves real world problems. I once used Python and Django for everything. Now, I’ve moved to Node.js, TypeScript, React, and generally that ecosystem. It works far better than Python+Django. My development speed is blazingly fast in comparison, and the results stand up — they’re shippable. Once I was familiar with Python & Django, they got the job done. Now, I’m familiar with TypeScript & Node, they get the job done better. Familiarity is that invisible force that, in its absence, prevents us from distinguishing things that don’t work from things that do work but are just different from what we know.
giantrobot 5y ago
> Almost nobody is going to use Deno to serve a basic HTML site with less than a dozen pages, Assumes facts not in evidence. People are already building JavaScript monstrosities to serve entirely static blog content.
- ramesh31 5y ago
  >People are already building JavaScript monstrosities to serve entirely static blog content. I think we just have to accept that that's how websites are built now. It drove me nuts for a while, too. But modern JS engines are blindingly fast, and 2-3mb of JS download (that will be cached aggressively) is a non-issue for the vast majority of users. I started talking to a junior developer the other day about server side rendering in the days of Rails/PHP/etc. and he looked at me like I was crazy. Couldn't even grasp the concept. I think for better or worse this is where we are headed.
  - wwweston 5y ago
    Since forcing the industry to realize the possibility of server-side rendering at gunpoint is oppressive and impractical I suppose that there is some sense in which we need "accept that's how websites are built now," but there's certainly no problem with speaking about the benefits of server-side rendering and drawbacks of JS-ification. > 2-3mb of JS download (that will be cached aggressively) It's a giant problem on mobile. Connection quality varies and the larger the payload the greater the probability that it just doesn't all load. Caching? Mobile Safari will just reload the entire damn page periodically if you swap apps -- I don't think it caches in the same way that desktop browsers do.
    - thestepafter 5y ago
      A couple versions ago mobile browsers started clearing cache when you leave the application to help save battery life if I remember correctly. Very annoying because now I am unable to open a bunch of tabs in Safari for HN threads before I go off grid.
      - 5y ago
chrisco255 5y ago
There is no need to manually set up your own Node.js SSR framework for React. Next.js exists, and is quite mature at this point. Next.js is quite fun. Highly recommend it. The novel thing, for this, in my mind, is the edge hosting.
- ehnto 5y ago
  But just like all other frameworks, the cost isn't just getting it started, it's learning the framework, learning the ecosystem, and slowly building up your knowledge of the edge cases when you start moving past it's limits. Next.js puts you squarely back in monolith server-side territory in that regard, it's just a different flavor. Of course it has it's upsides if you're doing a purely React application. But you've now got all the complexity of a server-side monolith and a frontend framework, with the added bonus complexity of components that have to switch between client and server-side contexts, then state management and hydration across that boundary as well. Now people are going to say "Ha, idiot, you just simply..." but that's just part of the learning, so you're in no better place with Next.js/SSR in general unless you want to build an interactive application. This isn't against Next.js by the way, I did enjoy it when I needed it, it's just that there's no avoiding some of the inherent domain problems regardless of which framework you pick.
  - DangitBobby 5y ago
    Definitely my biggest concern working with nextjs so far is that the line between when something is will execute server side and when it will execute client side is a bit blurry until you test them. It's manageable but requires some trial and error IME.
    - 52-6F-62 5y ago
      That was problematic for me when I was testing it out. Can’t access the window object without excessive workarounds that I couldn’t make work with my project. I ended up reusing existing react components and move it to all browser rendered react and even that experience has me leaning toward moving it to Vue or dropping the framework altogether and grinding everything out in css again. That said, I did enjoy using styled components. I found that pattern pleasant to reason around.

rglover 5y ago

> Setting up a monolith application means using something like Ruby-on-Rails, Django, Spring, ASP.net, or rolling your own with a Node.js backend serving a SSR front-end, or hydrating React views. https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick

colordrops 5y ago

You can use a service worker proxy to cache and serve files to an application, which keeps things both fast and also with raw uncompiled html and JS file.

dodyg 5y ago

ASP.NET Core is pretty minimal in ceremony nowadays. You can easily do single file web development. https://github.com/dodyg/practical-aspnetcore/blob/net6.0/projects/sfa/wiki/Program.cs https://github.com/dodyg/practical-aspnetcore/blob/net6.0/pr...

masa331 5y ago

Your focus on things being "modern", which is no indicator of value except for hipsters and recruiters, made you forget about the third conclusion with which you might come away from setting up a monolith application: 3. Wow, this actually works. I am so productive and i can actually get my work done quickly, the same way as hundreds of thousands other normal developers out there. And then i can have a free time and mind free of stressing over what's cool or not It's about what you value. If it is your time and happinnes, if you mainly want to just build stuff to solve real world problems, then choosing good old monolith application will get you there safe and fast in 90% of situations. If you value to be hip and cool, then Deno, hydrating whatever, edge servers and sorely lacking areas of modern web development will 100% get you there.

Dangeranger 5y ago
My thoughts weren't really meant to be a condemnation of monolithic web app frameworks, just a summary of my conclusions after using them for years. The reasons I have for justifying use of React, JSX, GraphQL, etc. have nothing to do with being "hip and cool" and everything to do with happiness and productivity. Using modern tools is both more enjoyable and more productive in my experience, as someone who used Ruby-on-Rails with templated pages for four years.
replygirl 5y ago
> I am so productive and i can actually get my work done quickly, **the same way as hundreds of thousands other normal developers out there.** i seek out new technologies because i want to be _more_ productive than the average engineer. i don't believe there are hundreds of thousands of developers who are more productive than someone who makes an effort to learn stuff like deno, vite, unjs, fauna, etc. as soon as possible
DecoPerson 5y ago
“Modern” also means the solution may benefit from reflection on past solutions. The accounting software I use, written in 2004, evolved over the decades starting from 1980s software. It all works (hence, I’m using it now), but comparing the user experience and source code of various features developed at various times reveals a lot about what “modern” means. Here’s a few things: Standardisation: Modern software tends to use proven designs, such as SQL over a bespoke query language. Performance: The strictness of ABIs and APIs makes it difficult to restructure for the sake of optimisation without introducing undesirable breaking changes. Old codebases may be essentially “frozen” and stuck on old versions of libraries. Fresh software can use the latest versions of libraries, with their new APIs & ABIs and whatever optimisations come along. Fundamental coding improvements: Old languages don’t have ergonomic, performant closures (see lambda functions in Python). New languages do (see arrow functions in ES6). Replace “closures” with any core language feature, like null coalescing, match statements, object & array destructing (or even better: pattern matching assignment), or hygienic macros. (Let’s not discuss async/await as that doesn’t lie in the “unquestionably better” column.) Better error messages & debugging: Over time, we collectively as developers have figured out what helps and what hinders when trying to track down troubles. —— I also build stuff that solves real world problems. I once used Python and Django for everything. Now, I’ve moved to Node.js, TypeScript, React, and generally that ecosystem. It works far better than Python+Django. My development speed is blazingly fast in comparison, and the results stand up — they’re shippable. Once I was familiar with Python & Django, they got the job done. Now, I’m familiar with TypeScript & Node, they get the job done better. Familiarity is that invisible force that, in its absence, prevents us from distinguishing things that don’t work from things that do work but are just different from what we know.

giantrobot 5y ago

> Almost nobody is going to use Deno to serve a basic HTML site with less than a dozen pages, Assumes facts not in evidence. People are already building JavaScript monstrosities to serve entirely static blog content.

ramesh31 5y ago
>People are already building JavaScript monstrosities to serve entirely static blog content. I think we just have to accept that that's how websites are built now. It drove me nuts for a while, too. But modern JS engines are blindingly fast, and 2-3mb of JS download (that will be cached aggressively) is a non-issue for the vast majority of users. I started talking to a junior developer the other day about server side rendering in the days of Rails/PHP/etc. and he looked at me like I was crazy. Couldn't even grasp the concept. I think for better or worse this is where we are headed.
- wwweston 5y ago
  Since forcing the industry to realize the possibility of server-side rendering at gunpoint is oppressive and impractical I suppose that there is some sense in which we need "accept that's how websites are built now," but there's certainly no problem with speaking about the benefits of server-side rendering and drawbacks of JS-ification. > 2-3mb of JS download (that will be cached aggressively) It's a giant problem on mobile. Connection quality varies and the larger the payload the greater the probability that it just doesn't all load. Caching? Mobile Safari will just reload the entire damn page periodically if you swap apps -- I don't think it caches in the same way that desktop browsers do.
  - thestepafter 5y ago
    A couple versions ago mobile browsers started clearing cache when you leave the application to help save battery life if I remember correctly. Very annoying because now I am unable to open a bunch of tabs in Safari for HN threads before I go off grid.
    - 5y ago

chrisco255 5y ago

There is no need to manually set up your own Node.js SSR framework for React. Next.js exists, and is quite mature at this point. Next.js is quite fun. Highly recommend it. The novel thing, for this, in my mind, is the edge hosting.

ehnto 5y ago
But just like all other frameworks, the cost isn't just getting it started, it's learning the framework, learning the ecosystem, and slowly building up your knowledge of the edge cases when you start moving past it's limits. Next.js puts you squarely back in monolith server-side territory in that regard, it's just a different flavor. Of course it has it's upsides if you're doing a purely React application. But you've now got all the complexity of a server-side monolith and a frontend framework, with the added bonus complexity of components that have to switch between client and server-side contexts, then state management and hydration across that boundary as well. Now people are going to say "Ha, idiot, you just simply..." but that's just part of the learning, so you're in no better place with Next.js/SSR in general unless you want to build an interactive application. This isn't against Next.js by the way, I did enjoy it when I needed it, it's just that there's no avoiding some of the inherent domain problems regardless of which framework you pick.
- DangitBobby 5y ago
  Definitely my biggest concern working with nextjs so far is that the line between when something is will execute server side and when it will execute client side is a bit blurry until you test them. It's manageable but requires some trial and error IME.
  - 52-6F-62 5y ago
    That was problematic for me when I was testing it out. Can’t access the window object without excessive workarounds that I couldn’t make work with my project. I ended up reusing existing react components and move it to all browser rendered react and even that experience has me leaning toward moving it to Vue or dropping the framework altogether and grinding everything out in css again. That said, I did enjoy using styled components. I found that pattern pleasant to reason around.