5 ms·
Why a focus on frontend only? I am using Typescript, Babel, Jest and a bundler for any app/library on the frontend/backend. If you got to do it, do it all the w
by iRomain 6y ago
Why a focus on frontend only?
I am using Typescript, Babel, Jest and a bundler for any app/library on the frontend/backend.
If you got to do it, do it all the way!
I can already see the GH issues, “sorry, this is a backend use case”.
So now my tooling would end up being more complex with the addition of another tool since it will never support all my use cases.
Seemed promising but this alone makes me question its utility.
- novaleaf 6y agoI just last week found out about https://rushstack.io/ https://rushstack.io/ you might like it.
- no_wizard 6y agoI think this has a brighter future than lerna if you are managing a monorepo They’re betting big on PNPM being a strong long term bet. They also just recently released Heft which is the rushstack repo build/lint/dev-server stack. It’s a promising project
- novaleaf 6y agototally agree, on all counts. I'm getting back into typescript dev and tried lerna... I couldnt get it working after a week of trying. It probably does work, just lack of tutorials makes it a really steep learning curve. Then I found an out-of-passing mention to Rush and !!! Heft is great. PNPM is great (hadn't known about that either)
- sebastianmck 6y agoTypeScript is a frontend language. "Frontend" is the category of languages we plan on supporting. It doesn't say anything about your usage of those languages. Where you run the code does not matter.
- capableweb 6y agoCould you expand on why you think TypeScript is a "front-end" language? I was under the impression that it just compiles to Javascript and while Javascript used to be a front-end language, it's nowadays bravely used for backend projects as well, for some reason.
- davidy123 6y agoI want to somehow make the point, which seems to be somewhat out of fashion this season (it was a focus a few years ago), that one of the features of Javascript is that it's universal/isomorphic. And that the average computer (and even smartphone) is very powerful, so if storage is abstracted, the distinction blurs. To me, this means features like browser based tools, which are gradually becoming more user friendly, don't really need a "server," except perhaps as a way to coordinate and for long term storage. Eventually, I think a non technical user should be able to create content that contains open-ended dynamic formatting and distributed data based views, without a round trip to a server. If they want to dip into arbitrary Javascript, maybe just re-using a module, fine. Ultimately, the same code might be used in the browser as that in a development process. Current markdown tools and notebooks are headed in this direction. However, trying to use something like mdx-js shows we are far from reasonable bundle sizes when taking this approach. One-tool-per-application might yield the small bundle sizes and dynamism for this goal. Wondering if Rome has this goal in mind. Thanks!