Yes JIT building on route request sounds super non-wasteful and better. /s
AFAIK there's some caching going on.
You don't need a build step
131–140 of 224 posts
Re: You don't need a build step
#132> What exactly needs to happen to make server-side JavaScript run in the browser? That sounds like an oxymoron to me. I have honestly no idea what they mean by that. To me, a browser is client-side software, so saying you want to run server-side JS on it doesn't make any sense. They mention it several times in the article but I simply can't follow. Could someone with a deeper understanding ELI5 this to me?
Code reuse. If I need to render on the server (for SEO purposes, as most people do not rely on Google's dubious and unknown JavaScript processing ability) then it makes sense to want to share as much code as possible between the server and the client. If you're doing a single-page-application (SPA) you can also share routing code, as your client will need a way to route to pages client-side.
With that said, I've seen people argue against node APIs and this desire to only use web APIs on the server. I don't get that. Node's API is generally pretty good and using JS as a replacement for Python/Ruby/etc. locally is rather excellent today. You don't need neutered APIs to also write code that works in both client and server. Unless you're selling cloud native bullshit (ahem, Nextjs)
Re: You don't need a build step
#133Earlier quoted context omitted.
HTTP/2, which is getting pretty widespread now, mitigates most of the concerns about making a bazillion requests.
Here is what Vite has to say about it. [0] Take a look at a few optimization it's able to do that the Deno guys will never even be able to dream of (otherwise they will reinvent Node.JS lol) [1]. The worst part is that the guy who created Deno is the same person that made Node.JS, if you don't like NodeJS I'm not sure why someone would be betting all in another of his projects, specially considering second-system syn…
[deleted]
Re: You don't need a build step
#134Earlier quoted context omitted.
yeah, exactly. So I wonder if ultimately they want to have the browser handle transpiling things like typescript? And I definitely think there are other concerns (such as linting) that you want to happen as part of your development pipeline.
There is an ES39 proposal to allow type annotations in Javascript, that would allow the browser to handle TS/Flow files without needing a compile step: https://github.com/tc39/proposal-type-annotations (That's only to allow the type annotations to be there, not to have static checking in the browser) IMO: I would love to see this implemented. Linting and typechecking should be ran before committing code or deploying,…
that sounds needlessly wasteful. You can trivially strip TS out of JS before sending off to the client. You're still going to need to check TS in the build/CI step (i.e. the time consuming part) before doing anything so you've gained exactly nothing.
Re: You don't need a build step
#135I worked on JS infra for Google. One thing we found in this space is that when your apps get very large in terms of number of source files, there is a developer-impacting load time cost to the unbundled approach. That is, your browser loads the entry point file, then parses it for imports and loads the files referenced from there, then parses those for imports and so on. This process is not free. In particular, even…
Google apps always seem to stand out with an especially large amount of requests. Does Google use a proprietary module system for these runtime imports? I've only seen this from afar when using the Maps JS API.
This is the "don't download code you don't run" and "don't ask for data you don't need yet" with smart prefetching and caching. Mostly facilitated using an internal 3 letter framework in Google.
If you want a de-googled approach for "only code you need" check out qwik by Misko Hevery who worked on a bunch f JS related things and a few others. The concept is "resumability".
(not sure if that's what you entirely meant since your example was the maps api)
Re: You don't need a build step
#136Earlier quoted context omitted.
Man the things that pass for innovation in the node-adjacent space continues to blow my mind. It feels like hte horrors of /r/programmerhumor meets generic internet hype-beast cycles.
A poor craftsman blames their tools.
Because a good craftsman picked his tools and knows it’s his fault if they’re garbage.
This pattern of “thinking” pisses me right off. It’s an axiom about quality and avoiding deflection and it’s always used in a low-quality reply as a form of deflection.
I can’t recall the last time I heard someone use that phrase the way it’s meant to be used.
Re: You don't need a build step
#137I am perplexed by the focus on this. Clearly there are excellent devs working on Deno — but what setups are you running that the actual build is holding your productivity back? Developing in node/ts or rails I don't think it would move the needle in the slightest for me. It's simply not an issue outside of my brain finding beauty in any kind of optimization. Is that all this is?
Deno has a hard time innovating and the reason adoption has been low in my opinion is that Node is good enough and has a lot of these features anyway (esm, easy ts support, https imports, web apis like fetch etc).
They are trying to innovate and coming up with differentiators and reasons to use the platform. If you had to ask me when I met Ryan 5 years ago in JSConf EU before he introduced deno - I would have assumed they'd have 30% market share by now (of server JS) but Node has been able to "catch up" to complaints quickly enough (I think) and Deno's selling points like edge computing and fast startup aren't super important for msot devs in most use cases in practice and there are other runtimes for different clouds (like cloudflare workers).
That said - it is still really good they are trying to innovate and while I find the marketing speak shitty and somewhat in bad faith - I still think it's really good they're innovating and I'm very much in favor of that and hope they find something important enough to solve to get big.
Re: You don't need a build step
#138In other languages, devs build better tools for solving existing problems faster or easier. In no other language, build tools are so broken that the best tool changes every few years.
In the JavaScript world, a significant chunk of energy is directed inwards, solving problems created by using JavaScript!
Re: You don't need a build step
#139In other languages, devs build better tools for solving existing problems faster or easier. In no other language, build tools are so broken that the best tool changes every few years. In the JavaScript world, a significant chunk of energy is directed inwards, solving problems created by using JavaScript!
It’s been [2] days since I had to fix our npm install.
One package (not ours) suddenly fails to build about 40% of the time. Looks like a parallel access problem, node-gyp poops with ”Unable to access foobar.tlog” because some other step is using the same file
Fixed elegantly by adding a while(failed){npm install}
Because trying to debug the build for a package you didn’t create just isn’t worth it
Re: You don't need a build step
#140Earlier quoted context omitted.
> I hate hate hate that modern web development requires a build system Why? For any sufficiently complex software system, a build system serves as a reducer whose input is something that is more convenient for developers, ie huge codebase with tons of utilities and annotations, and whose output is something more optimized to run on the end users' devices. It's good to do such optimization because there will be, at le…
> Why? One more thing to know, to update, to break, to configure, to consider when debugging. The existence of source maps proves just one aspect of the pain this indirection and complexity introduces. I’m not necessarily arguing the trade offs don’t make it worth it, merely that there is a cost and there are good reasons we’d want to avoid it if, all else being equal, we can.
Then you can just use ESM straight in the browser... The payload will be bigger, but it's all JS turtles the way down.
I think for me the only small down side (beyond request count/size) is you couldn't use JSX and a lighter interface (preact or similar). One option would be a service worker to transpile JSX on demand... which I guess wouldn't be too hard to do.