9 ms·

The issue I have with the JS world is that the most used libraries and frameworks are just "good enough for a small project" and no more than that. * Javascrip

The issue I have with the JS world is that the most used libraries and frameworks are just "good enough for a small project" and no more than that. * Javascript has such a minimal standard library, you will need to get one or three third-party libraries to augment its core. * React is an excellent view library and nothing more. You will need to get one or three third-party system to turn it into a fully fledged web framework. * Frameworks like Next.js are good enough to create a static page, but as requirements grow more complex, its limited feature-set and lack of in-depth documentation will feel like a prison. * Dev tooling is non existent, so it's on you to get and _configure_ a linter, type checker, testing framework, bundler, etc. Without speaking of the DOM and CSS, which are just _now_ starting to feel feature complete for most use cases. Javascript proponents say the ability to mix and match is its strongest feature, but to me the analysis paralysis of having to stop and shop for a library that does X (and will only do X) is a total productivity killer.

dntrkv 5y ago
> Javascript has such a minimal standard library, you will need to get one or three third-party libraries to augment its core Maybe 5-10 years ago, there is no need anymore > React is an excellent view library and nothing more. You will need to get one or three third-party system to turn it into a fully fledged web framework. Depends on your needs. Small app? React on its own is enough. Larger app? Add a router. That’s basically it. If you want a centralized state store, you can pick one of those up. It’s really not that difficult. > Frameworks like Next.js are good enough to create a static page, but as requirements grow more complex, its limited feature-set and lack of in-depth documentation will feel like a prison I don’t find any of this to be true. > Dev tooling is non existent, so it's on you to get and _configure_ a linter, type checker, testing framework, bundler, etc You mean there is nothing built in to the language itself? Yeah, that’s a feature in this case. We wouldn’t have the amazing 3rd party tooling if it did. The JS tooling ecosystem is amazing and getting things setup nowadays just takes one command.
- franga2000 5y ago
  I'll pick just one point to address: > The JS tooling ecosystem is amazing and getting things setup nowadays just takes one command. Which command would that be? Sure it's one command if you use one of a billion template projects, but just picking one of those is a chore and I'd never call that situation "amazing".
  - thrower123 5y ago
    And god help you if you want to get anything to work just a little bit differently from how the "one command" chooses to set things up. Like, create-react-app is great, but if you have to eject, you've got no parachute
    - deleted 5y ago
      [deleted]
  - dntrkv 5y ago
    Nowadays the only choice you’re really making is which styling library to use and which state management. Everything else is a given. Anyways, if you know enough about FE to have an opinion on the tooling, great, choose what you want. If you don’t wanna choose, use Next.js or CRA with React/Styled-Components and then add React Router if you need routing and add state management if you need it. These aren’t difficult choices to make. I have a feeling that the problem is that people are trying to make decisions they don’t need to be making up front. Evaluate the choices when you reach a situation that requires it.
    - neves 5y ago
      > Everything else is a given. Would you please send a link that summarizes this "everything else"? Every time I take a look at JS ecosystem I get lost.
      - dntrkv 5y ago
        React, Webpack, Eslint, Jest, React Testing Library That’s the standard setup nowadays and it’s what most people should go with. If you want type checking, add TS to the mix. But seriously, just use Next.js you can build tiny static sites with it and you can build complex SPAs. It’s very lightweight and basically just strings together all these tools while adding some convention that you can follow if you wish.
- simion314 5y ago
  >Maybe 5-10 years ago, there is no need anymore Is still either create your own or install a random package that brings other 20 as dependencies. Example, you want to show an Alert or Yes/No popup, This are built-in everywhere but n Web world you need to review and install a third party thing, or create your own buggy or incomplete implementation. Maybe you want modal dialogs, this is a standard in GUI tookits but you need to create your own or install a package/module/plugin specific for your project shitty framework Maybe your designer demands a (context) menu one with keyboard shortucts and native looking like , or a scrollbar that matches the website/app theme colors or that works horizontally without holding Shift like in native apps, you have again to find 1 solution from a giant pile of shitty packages. The dropdows,scrollbars, number spinner, color picker inputs CSS customization is pathetic, the designers demand customization and the only solution is installing third party stuff. There is no DataGrid or ListView component with a smart implementation that can hold many items so all websites implement a crappy inefficient thing, or show you only 20 items and you need to hit NExt Page like a money or again you find a third party solution. As a language JS progressed a lot, so much I am not sure if switching to TS is a good idea or I just need to wait until JS will catch up with TS. But as a platform the Web /DOM is still garbage, CSS got some nice feature with flexbox but that is all. People that did not wrote complex desktop apps with a GUI framework will not understand this, and think that the shitty component they create by nesting 12 divs and catching 2 events is the exact same thing. It is not, this GUI frameworks components are efficient and handle all events/cases properly. Even Google devs were incapable to make the Youtube search suggestion dropdown work correctly, many times it gets stuck open and you can't close it without a reload.
  - Gare 5y ago
    > As a language JS progressed a lot, so much I am not sure if switching to TS is a good idea or I just need to wait until JS will catch up with TS. Can you elaborate on this? TS is just adding type checking to JS, the only runtime addition are enums. I doubt that JS will incorporate type checking anytime soon. I mostly agree with your other points.
    - simion314 5y ago
HarmonicTons 5y ago
Agree with everything, but saying Next.js is just enough to create a static page is quite the strech.
Glench 5y ago
Agreed with everything you say here. Really want there to be a go-to Rails-like framework for JS, but nothing has reached that point yet. I'm very bullish on SvelteKit — hits all the points you mention above and outputs a minimal, performant full-stack app. https://kit.svelte.dev/ https://kit.svelte.dev/ Still in beta and changing a lot but really really lovely to use. Heck, to scratch my own itch I'm even making a Rails-like SaaS boilerplate to go on top of SvelteKit to give me all models, user auth, admin dashboards, payments, etc that you need in almost every app these days: https://sveltesaas.com https://sveltesaas.com
- granshaw 5y ago
  Last I looked the rails like JS framework was https://adonisjs.com/ https://adonisjs.com/
  - Glench 5y ago
    When I last looked at Adonis I was really turned off, but I don't remember why. Looking again, it seems like the templating is a real weakness, but lots of the other things are nice.
    - granshaw 5y ago
      I think it’s the closest to rails in philosophy where they aim for sane defaults and one way to do things and also prioritize the dev experience Oh, and also they provide a repl to your app code and data… that is huge and super hard to find in the js world
  - jrumbut 5y ago
    And there was Sails and any number of other attempts at this. A key strength for Rails is Ruby and a key weakness for any aspiring JS equivalent is JS and the JS ecosystem. If the Rails team had had to spend time adapting to 6 different alternatives to bundler, rack, and every other library they use it wouldn't be what it is today.
- com2kid 5y ago
NumberCruncher 5y ago
My issue with the JS world is that it is leaking from frontend webdev into other domains. 0.1% of your users having a bad user experience because of using a "just good enough" JS library is pretty fine for me, even if I am - as a user - in that 0.1%. But taking down your whole k8s cluster thanks to switching to a "just good enough" JS library from a battle tested python library is the exact opposite of "fine".
addandsubtract 5y ago
> Frameworks like Next.js are good enough to create a static page, but as requirements grow more complex, its limited feature-set and lack of in-depth documentation will feel like a prison. How so? I found NextJS to be one of the most pleasant and well documented frameworks to work with. Sure, you'll have to read most of the docs to find out how to do something the NextJS way, but so far, I've come to agree with every design choice they've made. The only gripes I have with it are debugging serverless functions that work in development, but then break in the vercel/aws blackbox.
- bengale 5y ago
  Yeah it feels like this NextJS opinion is very out of date.
  - 1_player 5y ago
    I've spoken about my dislike of next.js a few times, and it's mostly centered around its documentation. It is decent, but it is no way as complete as an established framework like Django. Have you ever compared the depth of the two? I'm on mobile, just read and compare, I don't know, the routing API docs for both. Also the APIs are very simplistic, I haven't used it in the past few months when I quit my job, but I vividly recall how anything outside of the simple examples it provides were an exercise in frustration and digging into Github Issues and its source code. The whole data fetching system is so incredibly convoluted if you're doing a little more than static pages or build-time rendering. getInitialProps, getServerSideProps, getStaticProps, hooks, etc., all with their own caveats and performance considerations. Next might be one of the better JS frameworks but it's laughably bad compared to Django, Rails, Phoenix.
    - Oddskar 5y ago
      I think in general it's a very tall order to compete with the documentation of Django. It's pretty much world class. I wish more projects had such good documentation.
ajmurmann 5y ago
I think Ember was a lot closer to a complete framework. I do believe that that's also why it didn't gain as much popularity. The learning curve was a lot steeper than for React or Angular. You won't run into the problems with the slimmer libraries till later and at that point you understand them and "just" learn the new thing, Redux or wherever you are including now. All along the way it feels smooth, but you end up with some more complicated, glued together whole. With a larger framework you might end up with something less complex and cleaner in the end. I think on the backend we historically have had more complex problems sooner. You gotta connect to some database, serve multiple pages, track some context along, render views or API responses. It's much easier to anticipate the need for a framework or solutions to these problems sooner.
- ClayShentrup 5y ago
  This, 100% this this this this this.
- eloisius 5y ago
  I built a product and we bet on Ember back when it, angular and react all looked like top choices. I’d say one of the biggest failures was that it didn’t provide clean upgrades We got stuck with 3.something and no clear path forward. Second, it wanted everything to be Emberized. I forget what exactly it was, but we struggled to wrap other tools in service containers so that they could be injected into our code. I think it was probably Google JS APIs like Maps, which at the time wanted you to load the toolkit their way. Ember-data probably was the biggest mistake to adopt. The amount of time I spent trying to fool some outdated JSON serializer in Rails into embedding something the way ember data wanted was a huge waste. The only other JS I’ve used seriously is Backbone, and once I was waste deep in ember I had major regrets that I didn’t choose it instead.
  - holler 5y ago
    I agree ember had issues in the past, but it's come a long way and the latest version Octane/4.0 is pretty solid. For anyone curious linkedin.com is a massive ember.js app and they're big contributors to the project.
brabel 5y ago
Agree, and to go further (from the point-of-view of an outsider who is forced to do JS occasionally): * should I use npm or yarn? Why do I see most package authors recommending yarn when npm is the default as far as I know? * should I introduce Typescript to be able to handle complexity better? * which module system? I see lots of "require" VS "import", if it needs to work on browser/node.js/deno, which one?!?! * which test framework? Mocha? Karma? Jest? Cypress? * should I use a bundler like webpack or just move on to esbuild? Vite? Deno?!?! It's a nightmare every time I am forced to use JS (usually because of cloud services normally offering JS lambdas and nothing else)...
- neves 5y ago
  Great questions. 3 years from now you will have completely different answers.
- realusername 5y ago
  > * which test framework? Mocha? Karma? Jest? Cypress? Most of the dependencies you will install will have no tests at all anyways. This is another issue of its own, you are building on very weak foundations.
  - dimgl 5y ago
    This is a pretty huge assumption.
    - realusername 5y ago
      Anybody who had to maintain & keep up to date a large node codebase knows what I'm talking about. Testing is an afterthought at best and non-existent in a lot of packages. I'm not talking about the top packages of course, just the N+4 small packages you depend on.
- spicybright 5y ago
  I often find my choices will rub up against each other a lot. I never know whether to build glue code because that's the right way, or I should have picked a different library. It's too fine grained.
aantix 5y ago
As you start going down the path of developing a SAAS, I've even reached the point where Rails isn't enough. I don't care to implement a forgot password form or api token generation for the Nth time. Give me an 80% solution and then on with the show. I couldn't even imagine starting with all of these disparate pieces of JS tooling - 10 steps back. Strong defaults and integration give so much. I genuinely think templates like JumpStartPro are the future of Rails. https://jumpstartrails.com/ https://jumpstartrails.com/ Very high level template functionality already baked in so that you can immediately get to solving the core business issues.
trimbo 5y ago
> The issue I have with the JS world is that the most used libraries and frameworks are just "good enough for a small project" and no more than that. Do people believe this about Angular? Not primarily a front end dev, but in my limited experience with React and Angular, it seems like Angular's strength is that it provides more structure for scaling to larger projects.
- paulirwin 5y ago
  Came here to say this. Angular ticks just about every box from the original article. It is opinionated (IMO in a good way, but YMMV), well structured, and batteries are included. You still have the flexibility to do data access, state management, and such however you like but there are well-established patterns and libraries if you want to lean on them. Modules help you scale to larger projects, with fairly painless code splitting / lazy loading. You don't have to set up any complicated build scripts, and the cognitive complexity is low (as long as you don't overuse rxjs) so junior devs can easily jump in. And, Angular is very mature now in 2022, with few-to-no breaking changes between versions. I highly recommend it as the state-of-the-art SPA platform today.
- Alex3917 5y ago
  Honestly Angular is great even for startups. With the current state of the the framework and the way the Angular CLI bundles code, it's pretty hard to break 90 on PageSpeed Insights (at least without pre-rendering). But it's also not that difficult to get in the high 80s, which is pretty good for a SPA. And it should only be getting more performant as they put more working into optimizing it. It's easy to learn, the code is super clean, TypeScript is great, and imo it generally just makes for a good work environment.
  - Oddskar 5y ago
    > And it should only be getting more performant as they put more working into optimizing it. You say this like it's not an 8 year old framework. I wouldn't have such high hopes for it rising significantly.
com2kid 5y ago
If you are creating a rich web app, you still have to deal with all of this when generating HTML+JS in another language. Rails doesn't save you from any of this, none of the back end frameworks do. I prefer writing SPAs because if I prefer to be directly authoring my HTML+JS instead of authoring it indirectly through a framework in a different language.
avidphantasm 5y ago
"Javascript has such a minimal standard library" My hope is that this has been/will continue to change over time, is this a fare statement? Does anyone know if the various working groups (e.g., WHATWG, W3C, etc.) have the goal of making the JavaScript more robust? My vision is that the standard, built-in APIs would serve as a minimum viable platform that you can build simple to moderately complex applications in with only "minimal" external dependencies.
- dmitriid 5y ago
  You hope and you hope... and then they ship a Set without any useful built-in methods: https://exploringjs.com/impatient-js/ch_sets.html#missing-set-operations https://exploringjs.com/impatient-js/ch_sets.html#missing-se... Because ... variety of reasons, see tis comment thread: https://twitter.com/bakkoting/status/1488363368268251138 https://twitter.com/bakkoting/status/1488363368268251138
- WorldMaker 5y ago
  The working group most in charge of JS is ECMA's TC-39 (TC => Technical Committee) [0]. They've been taking a very deliberate, slow path to expanding the "standard" library because they take a very serious view of backwards compatibility on the web. Some proposals were shifted because of conflicts with ancient versions of things like MooTools still out in the wild, for instance. (This was the so-called "Smooshgate" incident [1].) This may speed up a bit if the Built-In Modules proposal [2] passes, which would add a deliberate `import` URL for standard modules which would give a cleaner expansion point for new standard libraries over adding more global variables or further expanding the base prototypes (Object.prototype, Array.prototype, etc) in ways that increasingly likely have backwards compatibility issues. TC-39 works all of their proposals in the open on Github [3] and it can be a fascinating process to watch if you are interested in the language's future direction. [0] https://tc39.es/ https://tc39.es/ [1] https://developers.google.com/web/updates/2018/03/smooshgate https://developers.google.com/web/updates/2018/03/smooshgate [2] https://github.com/tc39/proposal-built-in-modules https://github.com/tc39/proposal-built-in-modules [3] https://github.com/tc39/proposals https://github.com/tc39/proposals
dragonwriter 5y ago
> Javascript proponents say the ability to mix and match is its strongest feature, but to me the analysis paralysis of having to stop and shop for a library that does X (and will only do X) is a total productivity killer. If you can settle on a good enough batteries-included framework without analysis paralysis, you can make the individual as-needed decisions about libraries without it. It's not a problem of a higher order. If anything, it's lower-pressure, because the cost of a wrong choice is much smaller.

dntrkv 5y ago

> Javascript has such a minimal standard library, you will need to get one or three third-party libraries to augment its core Maybe 5-10 years ago, there is no need anymore > React is an excellent view library and nothing more. You will need to get one or three third-party system to turn it into a fully fledged web framework. Depends on your needs. Small app? React on its own is enough. Larger app? Add a router. That’s basically it. If you want a centralized state store, you can pick one of those up. It’s really not that difficult. > Frameworks like Next.js are good enough to create a static page, but as requirements grow more complex, its limited feature-set and lack of in-depth documentation will feel like a prison I don’t find any of this to be true. > Dev tooling is non existent, so it's on you to get and _configure_ a linter, type checker, testing framework, bundler, etc You mean there is nothing built in to the language itself? Yeah, that’s a feature in this case. We wouldn’t have the amazing 3rd party tooling if it did. The JS tooling ecosystem is amazing and getting things setup nowadays just takes one command.

franga2000 5y ago
I'll pick just one point to address: > The JS tooling ecosystem is amazing and getting things setup nowadays just takes one command. Which command would that be? Sure it's one command if you use one of a billion template projects, but just picking one of those is a chore and I'd never call that situation "amazing".
- thrower123 5y ago
  And god help you if you want to get anything to work just a little bit differently from how the "one command" chooses to set things up. Like, create-react-app is great, but if you have to eject, you've got no parachute
  - deleted 5y ago
    [deleted]
- dntrkv 5y ago
  Nowadays the only choice you’re really making is which styling library to use and which state management. Everything else is a given. Anyways, if you know enough about FE to have an opinion on the tooling, great, choose what you want. If you don’t wanna choose, use Next.js or CRA with React/Styled-Components and then add React Router if you need routing and add state management if you need it. These aren’t difficult choices to make. I have a feeling that the problem is that people are trying to make decisions they don’t need to be making up front. Evaluate the choices when you reach a situation that requires it.
  - neves 5y ago
    > Everything else is a given. Would you please send a link that summarizes this "everything else"? Every time I take a look at JS ecosystem I get lost.
    - dntrkv 5y ago
      React, Webpack, Eslint, Jest, React Testing Library That’s the standard setup nowadays and it’s what most people should go with. If you want type checking, add TS to the mix. But seriously, just use Next.js you can build tiny static sites with it and you can build complex SPAs. It’s very lightweight and basically just strings together all these tools while adding some convention that you can follow if you wish.
simion314 5y ago
>Maybe 5-10 years ago, there is no need anymore Is still either create your own or install a random package that brings other 20 as dependencies. Example, you want to show an Alert or Yes/No popup, This are built-in everywhere but n Web world you need to review and install a third party thing, or create your own buggy or incomplete implementation. Maybe you want modal dialogs, this is a standard in GUI tookits but you need to create your own or install a package/module/plugin specific for your project shitty framework Maybe your designer demands a (context) menu one with keyboard shortucts and native looking like , or a scrollbar that matches the website/app theme colors or that works horizontally without holding Shift like in native apps, you have again to find 1 solution from a giant pile of shitty packages. The dropdows,scrollbars, number spinner, color picker inputs CSS customization is pathetic, the designers demand customization and the only solution is installing third party stuff. There is no DataGrid or ListView component with a smart implementation that can hold many items so all websites implement a crappy inefficient thing, or show you only 20 items and you need to hit NExt Page like a money or again you find a third party solution. As a language JS progressed a lot, so much I am not sure if switching to TS is a good idea or I just need to wait until JS will catch up with TS. But as a platform the Web /DOM is still garbage, CSS got some nice feature with flexbox but that is all. People that did not wrote complex desktop apps with a GUI framework will not understand this, and think that the shitty component they create by nesting 12 divs and catching 2 events is the exact same thing. It is not, this GUI frameworks components are efficient and handle all events/cases properly. Even Google devs were incapable to make the Youtube search suggestion dropdown work correctly, many times it gets stuck open and you can't close it without a reload.
- Gare 5y ago
  > As a language JS progressed a lot, so much I am not sure if switching to TS is a good idea or I just need to wait until JS will catch up with TS. Can you elaborate on this? TS is just adding type checking to JS, the only runtime addition are enums. I doubt that JS will incorporate type checking anytime soon. I mostly agree with your other points.
  - simion314 5y ago

HarmonicTons 5y ago

Agree with everything, but saying Next.js is just enough to create a static page is quite the strech.

Glench 5y ago

Agreed with everything you say here. Really want there to be a go-to Rails-like framework for JS, but nothing has reached that point yet. I'm very bullish on SvelteKit — hits all the points you mention above and outputs a minimal, performant full-stack app. https://kit.svelte.dev/ https://kit.svelte.dev/ Still in beta and changing a lot but really really lovely to use. Heck, to scratch my own itch I'm even making a Rails-like SaaS boilerplate to go on top of SvelteKit to give me all models, user auth, admin dashboards, payments, etc that you need in almost every app these days: https://sveltesaas.com https://sveltesaas.com

granshaw 5y ago
Last I looked the rails like JS framework was https://adonisjs.com/ https://adonisjs.com/
- Glench 5y ago
  When I last looked at Adonis I was really turned off, but I don't remember why. Looking again, it seems like the templating is a real weakness, but lots of the other things are nice.
  - granshaw 5y ago
    I think it’s the closest to rails in philosophy where they aim for sane defaults and one way to do things and also prioritize the dev experience Oh, and also they provide a repl to your app code and data… that is huge and super hard to find in the js world
- jrumbut 5y ago
  And there was Sails and any number of other attempts at this. A key strength for Rails is Ruby and a key weakness for any aspiring JS equivalent is JS and the JS ecosystem. If the Rails team had had to spend time adapting to 6 different alternatives to bundler, rack, and every other library they use it wouldn't be what it is today.
com2kid 5y ago

NumberCruncher 5y ago

My issue with the JS world is that it is leaking from frontend webdev into other domains. 0.1% of your users having a bad user experience because of using a "just good enough" JS library is pretty fine for me, even if I am - as a user - in that 0.1%. But taking down your whole k8s cluster thanks to switching to a "just good enough" JS library from a battle tested python library is the exact opposite of "fine".

addandsubtract 5y ago

> Frameworks like Next.js are good enough to create a static page, but as requirements grow more complex, its limited feature-set and lack of in-depth documentation will feel like a prison. How so? I found NextJS to be one of the most pleasant and well documented frameworks to work with. Sure, you'll have to read most of the docs to find out how to do something the NextJS way, but so far, I've come to agree with every design choice they've made. The only gripes I have with it are debugging serverless functions that work in development, but then break in the vercel/aws blackbox.

bengale 5y ago
Yeah it feels like this NextJS opinion is very out of date.
- 1_player 5y ago
  I've spoken about my dislike of next.js a few times, and it's mostly centered around its documentation. It is decent, but it is no way as complete as an established framework like Django. Have you ever compared the depth of the two? I'm on mobile, just read and compare, I don't know, the routing API docs for both. Also the APIs are very simplistic, I haven't used it in the past few months when I quit my job, but I vividly recall how anything outside of the simple examples it provides were an exercise in frustration and digging into Github Issues and its source code. The whole data fetching system is so incredibly convoluted if you're doing a little more than static pages or build-time rendering. getInitialProps, getServerSideProps, getStaticProps, hooks, etc., all with their own caveats and performance considerations. Next might be one of the better JS frameworks but it's laughably bad compared to Django, Rails, Phoenix.
  - Oddskar 5y ago
    I think in general it's a very tall order to compete with the documentation of Django. It's pretty much world class. I wish more projects had such good documentation.

ajmurmann 5y ago

I think Ember was a lot closer to a complete framework. I do believe that that's also why it didn't gain as much popularity. The learning curve was a lot steeper than for React or Angular. You won't run into the problems with the slimmer libraries till later and at that point you understand them and "just" learn the new thing, Redux or wherever you are including now. All along the way it feels smooth, but you end up with some more complicated, glued together whole. With a larger framework you might end up with something less complex and cleaner in the end. I think on the backend we historically have had more complex problems sooner. You gotta connect to some database, serve multiple pages, track some context along, render views or API responses. It's much easier to anticipate the need for a framework or solutions to these problems sooner.

ClayShentrup 5y ago
This, 100% this this this this this.
eloisius 5y ago
I built a product and we bet on Ember back when it, angular and react all looked like top choices. I’d say one of the biggest failures was that it didn’t provide clean upgrades We got stuck with 3.something and no clear path forward. Second, it wanted everything to be Emberized. I forget what exactly it was, but we struggled to wrap other tools in service containers so that they could be injected into our code. I think it was probably Google JS APIs like Maps, which at the time wanted you to load the toolkit their way. Ember-data probably was the biggest mistake to adopt. The amount of time I spent trying to fool some outdated JSON serializer in Rails into embedding something the way ember data wanted was a huge waste. The only other JS I’ve used seriously is Backbone, and once I was waste deep in ember I had major regrets that I didn’t choose it instead.
- holler 5y ago
  I agree ember had issues in the past, but it's come a long way and the latest version Octane/4.0 is pretty solid. For anyone curious linkedin.com is a massive ember.js app and they're big contributors to the project.

brabel 5y ago

Agree, and to go further (from the point-of-view of an outsider who is forced to do JS occasionally): * should I use npm or yarn? Why do I see most package authors recommending yarn when npm is the default as far as I know? * should I introduce Typescript to be able to handle complexity better? * which module system? I see lots of "require" VS "import", if it needs to work on browser/node.js/deno, which one?!?! * which test framework? Mocha? Karma? Jest? Cypress? * should I use a bundler like webpack or just move on to esbuild? Vite? Deno?!?! It's a nightmare every time I am forced to use JS (usually because of cloud services normally offering JS lambdas and nothing else)...

neves 5y ago
Great questions. 3 years from now you will have completely different answers.
realusername 5y ago
> * which test framework? Mocha? Karma? Jest? Cypress? Most of the dependencies you will install will have no tests at all anyways. This is another issue of its own, you are building on very weak foundations.
- dimgl 5y ago
  This is a pretty huge assumption.
  - realusername 5y ago
    Anybody who had to maintain & keep up to date a large node codebase knows what I'm talking about. Testing is an afterthought at best and non-existent in a lot of packages. I'm not talking about the top packages of course, just the N+4 small packages you depend on.
spicybright 5y ago
I often find my choices will rub up against each other a lot. I never know whether to build glue code because that's the right way, or I should have picked a different library. It's too fine grained.

aantix 5y ago

As you start going down the path of developing a SAAS, I've even reached the point where Rails isn't enough. I don't care to implement a forgot password form or api token generation for the Nth time. Give me an 80% solution and then on with the show. I couldn't even imagine starting with all of these disparate pieces of JS tooling - 10 steps back. Strong defaults and integration give so much. I genuinely think templates like JumpStartPro are the future of Rails. https://jumpstartrails.com/ https://jumpstartrails.com/ Very high level template functionality already baked in so that you can immediately get to solving the core business issues.

trimbo 5y ago

> The issue I have with the JS world is that the most used libraries and frameworks are just "good enough for a small project" and no more than that. Do people believe this about Angular? Not primarily a front end dev, but in my limited experience with React and Angular, it seems like Angular's strength is that it provides more structure for scaling to larger projects.

paulirwin 5y ago
Came here to say this. Angular ticks just about every box from the original article. It is opinionated (IMO in a good way, but YMMV), well structured, and batteries are included. You still have the flexibility to do data access, state management, and such however you like but there are well-established patterns and libraries if you want to lean on them. Modules help you scale to larger projects, with fairly painless code splitting / lazy loading. You don't have to set up any complicated build scripts, and the cognitive complexity is low (as long as you don't overuse rxjs) so junior devs can easily jump in. And, Angular is very mature now in 2022, with few-to-no breaking changes between versions. I highly recommend it as the state-of-the-art SPA platform today.
Alex3917 5y ago
Honestly Angular is great even for startups. With the current state of the the framework and the way the Angular CLI bundles code, it's pretty hard to break 90 on PageSpeed Insights (at least without pre-rendering). But it's also not that difficult to get in the high 80s, which is pretty good for a SPA. And it should only be getting more performant as they put more working into optimizing it. It's easy to learn, the code is super clean, TypeScript is great, and imo it generally just makes for a good work environment.
- Oddskar 5y ago
  > And it should only be getting more performant as they put more working into optimizing it. You say this like it's not an 8 year old framework. I wouldn't have such high hopes for it rising significantly.

com2kid 5y ago

If you are creating a rich web app, you still have to deal with all of this when generating HTML+JS in another language. Rails doesn't save you from any of this, none of the back end frameworks do. I prefer writing SPAs because if I prefer to be directly authoring my HTML+JS instead of authoring it indirectly through a framework in a different language.

avidphantasm 5y ago

"Javascript has such a minimal standard library" My hope is that this has been/will continue to change over time, is this a fare statement? Does anyone know if the various working groups (e.g., WHATWG, W3C, etc.) have the goal of making the JavaScript more robust? My vision is that the standard, built-in APIs would serve as a minimum viable platform that you can build simple to moderately complex applications in with only "minimal" external dependencies.

dmitriid 5y ago
You hope and you hope... and then they ship a Set without any useful built-in methods: https://exploringjs.com/impatient-js/ch_sets.html#missing-set-operations https://exploringjs.com/impatient-js/ch_sets.html#missing-se... Because ... variety of reasons, see tis comment thread: https://twitter.com/bakkoting/status/1488363368268251138 https://twitter.com/bakkoting/status/1488363368268251138
WorldMaker 5y ago
The working group most in charge of JS is ECMA's TC-39 (TC => Technical Committee) [0]. They've been taking a very deliberate, slow path to expanding the "standard" library because they take a very serious view of backwards compatibility on the web. Some proposals were shifted because of conflicts with ancient versions of things like MooTools still out in the wild, for instance. (This was the so-called "Smooshgate" incident [1].) This may speed up a bit if the Built-In Modules proposal [2] passes, which would add a deliberate `import` URL for standard modules which would give a cleaner expansion point for new standard libraries over adding more global variables or further expanding the base prototypes (Object.prototype, Array.prototype, etc) in ways that increasingly likely have backwards compatibility issues. TC-39 works all of their proposals in the open on Github [3] and it can be a fascinating process to watch if you are interested in the language's future direction. [0] https://tc39.es/ https://tc39.es/ [1] https://developers.google.com/web/updates/2018/03/smooshgate https://developers.google.com/web/updates/2018/03/smooshgate [2] https://github.com/tc39/proposal-built-in-modules https://github.com/tc39/proposal-built-in-modules [3] https://github.com/tc39/proposals https://github.com/tc39/proposals

dragonwriter 5y ago

> Javascript proponents say the ability to mix and match is its strongest feature, but to me the analysis paralysis of having to stop and shop for a library that does X (and will only do X) is a total productivity killer. If you can settle on a good enough batteries-included framework without analysis paralysis, you can make the individual as-needed decisions about libraries without it. It's not a problem of a higher order. If anything, it's lower-pressure, because the cost of a wrong choice is much smaller.