3 ms·

I am old and I cringe when I see most of the 'modern stuff'. It is just simply a minefield and dangerous to use. I work in banking and have to sign off on every

I am old and I cringe when I see most of the 'modern stuff'. It is just simply a minefield and dangerous to use. I work in banking and have to sign off on everything used for decades in the future potentially: not much of what is in these frameworks on frameworks on bugs on frameworks qualifies even basic scrutiny but devs do want to use them because they read on hn/reddit it is the new thing. Painful struggle Edit: I do not mean to say people should stop making new things or trying to improve upon older ideas; just saying most this stuff needs huge ALPHA/experimental stamps on it.

lstamour 5y ago
It's partly a reflection of the web and web browsers. Yes, the goal is "don't break the web," but with each new release the odds that a website from "decades in the past" will continue to work today are slim. I don't mean that a simple HTML page won't work, but rather that HTML and other web standards are living - and compatibility often breaks when it's noticed that public web pages don't use features (low adoption) or when features are removed for security or privacy reasons. When you get used to re-learning everything on a monthly basis, it's easy to adopt new approaches. In fact, the Web Components movement, including lit-element, is basically built on the idea that you should write code for the browser, and thus your codebase must evolve as the browser does. If you look at it from the perspective of "this code must work forever," well, I'm not sure the browser is the right place to be. Have you considered shipping an old and outdated copy of a browser, such as Electron? ;-) Edit: That said, I do agree there's a lot of reinvent-the-wheel in NPM-land, but I don't think the best possible wheel has been invented yet, so I appreciate having options. TypeScript is a great example: they're continuing to rapidly evolve the language with each point release yet they also centrally maintain DefinitelyTyped to be backwards compatible to previous releases. This means maintainers don't have to manually update their types for each point-release of TypeScript. If you look for that, you'll see a lot of "automatic backwards compatibility" in places. JS Codemods for example, can automatically update minor and sometimes major versions of React. Not everything is pre-1.0 and experimental, but the new stuff is definitely shinier.
- mekkkkkk 5y ago
  In general, I think the web has decent backwards compatibility. With a few exceptions, websites from ten years ago still works fine. The major things that won't work are extensions (NSAPI, Flash, etc) or features that were experimental or obscure at the time. To me this is actually the big problem. I would love to have a reduced feature set (could be opt-in) in the browser environment. As it stands it's just an ever growing ball of mud that ironically inhibits innovation and makes browsers impossible to develop without a huge amount of effort. It feels like 95% of the APIs are not used on 95% of usage sessions.

lstamour 5y ago

It's partly a reflection of the web and web browsers. Yes, the goal is "don't break the web," but with each new release the odds that a website from "decades in the past" will continue to work today are slim. I don't mean that a simple HTML page won't work, but rather that HTML and other web standards are living - and compatibility often breaks when it's noticed that public web pages don't use features (low adoption) or when features are removed for security or privacy reasons. When you get used to re-learning everything on a monthly basis, it's easy to adopt new approaches. In fact, the Web Components movement, including lit-element, is basically built on the idea that you should write code for the browser, and thus your codebase must evolve as the browser does. If you look at it from the perspective of "this code must work forever," well, I'm not sure the browser is the right place to be. Have you considered shipping an old and outdated copy of a browser, such as Electron? ;-) Edit: That said, I do agree there's a lot of reinvent-the-wheel in NPM-land, but I don't think the best possible wheel has been invented yet, so I appreciate having options. TypeScript is a great example: they're continuing to rapidly evolve the language with each point release yet they also centrally maintain DefinitelyTyped to be backwards compatible to previous releases. This means maintainers don't have to manually update their types for each point-release of TypeScript. If you look for that, you'll see a lot of "automatic backwards compatibility" in places. JS Codemods for example, can automatically update minor and sometimes major versions of React. Not everything is pre-1.0 and experimental, but the new stuff is definitely shinier.

mekkkkkk 5y ago
In general, I think the web has decent backwards compatibility. With a few exceptions, websites from ten years ago still works fine. The major things that won't work are extensions (NSAPI, Flash, etc) or features that were experimental or obscure at the time. To me this is actually the big problem. I would love to have a reduced feature set (could be opt-in) in the browser environment. As it stands it's just an ever growing ball of mud that ironically inhibits innovation and makes browsers impossible to develop without a huge amount of effort. It feels like 95% of the APIs are not used on 95% of usage sessions.