7 ms·

Is it considered a stable version? The amount of unnecessary breaking changes is really frightening. I mean, why would one ever need to change standard module

by can3p 3y ago

Is it considered a stable version? The amount of unnecessary breaking changes is really frightening. I mean, why would one ever need to change standard module names or demo.json structure? Maybe it looks a bit better, but I’m sure it invokes a lot more pain for all developers, who need to watch out carefully with every release. I consider this a JavaScript curse to be honest. Every webpack version breaks apis in random ways, react native is notoriously hard to upgrade because of this etc Why isn’t it considered a problem in the community?

iddan 3y ago
The json structure is not a breaking change. You can use the old and the new structure
- nikanj 3y ago
  Why would you ever add the complexity of having to support two different formats then?
  - Aerbil313 3y ago
    Old one will be deprecated in a major version change afaik.
  - PoignardAzur 3y ago
    The two formats aren't that different, and the old version is now deprecated. I doubt it adds that much complexity.
  - ithkuil 3y ago
    Because the new format is easier for their (new) users but removing the old one would be a pita for their (existing) users. You can't get things 100% right all the times so you have to decide what to do when you realize there is a better way. You have a few choices: a. You don't improve the interface and instead you offset the issue by adding more documentation, helper scripts, templates/examples etc. b. You improve the interface, possibly in a backwards compatible way. So, (b) presents some maintenance costs, but (a) too has some costs! Some organizations tend to prefer (a) because it's easier to just make it somebody else's problem (e.g. some other team will do documentation, some other team will do the developer advocacy). So it's a locally optimal solution and hence it's often chosen despite (b) being a globally optimal solution, since the product will be easier to use.
brundolf 3y ago
Deno has a very cool architecture where almost all of the standard library is imported from outside of the runtime. Which means you can pin specific versions of unstable APIs, and never get caught by surprise even as they're being iterated on rapidly. They also say in the post that eg., the deno.json file changes are backward-compatible As far as I know, Deno 1.x runtime upgrades are always backwards-compatible
frou_dh 3y ago
The standard library is separate from the Deno runtime and is currently pre-1.0 (0.185.0). As the blog post touches on, upgrading Deno itself does not force you onto the latest version of the stdlib. You will need to change the import URLs to get it.
threatofrain 3y ago
I think Deno feels a fire under their ass. The JS ecosystem has not really embraced Deno in terms of tooling, libraries or frameworks and the serverless ecosystem has not embraced Deno as a runtime (aws/gcp/azure functions), so they're iterating rapidly to see if they can get something to really stick. And then there's Bun. I love Deno for system scripting but the friction with the rest of the JS ecosystem has prevented me from adopting it further.
- sph 3y ago
  [flagged]
  - osener 3y ago
    Disgraceful?! I'd much rather OSS authors have an additional SaaS offering to support their work and work on it full-time rather than get them to work nights and weekends for free while AWS collects the checks for deploying their work.
  - xupybd 3y ago
    I like to get paid for my work. Most people do. There is nothing disgraceful about that. I don't see any difference between deno as a company and your SAAS bernard.app.
    - sph 3y ago
      My SaaS is not an open source project nor a language runtime. How would you feel if Go, Elixir or Rust (just to name a few) were run by a company that depends on their success, so try to push aggressively new features and mindshare, often with disastrous result? Are Go, Elixir or Rust developers working for free? There is a difference between getting paid to work on open source, and structuring an open source company as a VC-backed startup that needs to grow fast or die. I guess everyone has already forgotten about Docker, Inc.
      - Sytten 3y ago
        This is a bad analogy, it is more like if the Tokio runtime was built by a VC backed business which is really not that bad. Honestly the anti business sentiment on HN is just becoming annoying. Get shamed when not building OSS, get shamed if you take VC money, etc. People are supposed to be saints that work for free so you can then take that and build your own proprietary stuff? Seriously...

by can3p 3y ago

iddan 3y ago

The json structure is not a breaking change. You can use the old and the new structure

nikanj 3y ago
Why would you ever add the complexity of having to support two different formats then?
- Aerbil313 3y ago
  Old one will be deprecated in a major version change afaik.
- PoignardAzur 3y ago
  The two formats aren't that different, and the old version is now deprecated. I doubt it adds that much complexity.
- ithkuil 3y ago
  Because the new format is easier for their (new) users but removing the old one would be a pita for their (existing) users. You can't get things 100% right all the times so you have to decide what to do when you realize there is a better way. You have a few choices: a. You don't improve the interface and instead you offset the issue by adding more documentation, helper scripts, templates/examples etc. b. You improve the interface, possibly in a backwards compatible way. So, (b) presents some maintenance costs, but (a) too has some costs! Some organizations tend to prefer (a) because it's easier to just make it somebody else's problem (e.g. some other team will do documentation, some other team will do the developer advocacy). So it's a locally optimal solution and hence it's often chosen despite (b) being a globally optimal solution, since the product will be easier to use.

brundolf 3y ago

Deno has a very cool architecture where almost all of the standard library is imported from outside of the runtime. Which means you can pin specific versions of unstable APIs, and never get caught by surprise even as they're being iterated on rapidly. They also say in the post that eg., the deno.json file changes are backward-compatible As far as I know, Deno 1.x runtime upgrades are always backwards-compatible

frou_dh 3y ago

The standard library is separate from the Deno runtime and is currently pre-1.0 (0.185.0). As the blog post touches on, upgrading Deno itself does not force you onto the latest version of the stdlib. You will need to change the import URLs to get it.

threatofrain 3y ago

I think Deno feels a fire under their ass. The JS ecosystem has not really embraced Deno in terms of tooling, libraries or frameworks and the serverless ecosystem has not embraced Deno as a runtime (aws/gcp/azure functions), so they're iterating rapidly to see if they can get something to really stick. And then there's Bun. I love Deno for system scripting but the friction with the rest of the JS ecosystem has prevented me from adopting it further.

sph 3y ago
[flagged]
- osener 3y ago
  Disgraceful?! I'd much rather OSS authors have an additional SaaS offering to support their work and work on it full-time rather than get them to work nights and weekends for free while AWS collects the checks for deploying their work.
- xupybd 3y ago
  I like to get paid for my work. Most people do. There is nothing disgraceful about that. I don't see any difference between deno as a company and your SAAS bernard.app.
  - sph 3y ago
    My SaaS is not an open source project nor a language runtime. How would you feel if Go, Elixir or Rust (just to name a few) were run by a company that depends on their success, so try to push aggressively new features and mindshare, often with disastrous result? Are Go, Elixir or Rust developers working for free? There is a difference between getting paid to work on open source, and structuring an open source company as a VC-backed startup that needs to grow fast or die. I guess everyone has already forgotten about Docker, Inc.
    - Sytten 3y ago
      This is a bad analogy, it is more like if the Tokio runtime was built by a VC backed business which is really not that bad. Honestly the anti business sentiment on HN is just becoming annoying. Get shamed when not building OSS, get shamed if you take VC money, etc. People are supposed to be saints that work for free so you can then take that and build your own proprietary stuff? Seriously...