7 ms·

That leads to the MEAN stack (Mongo, Express, Angular, Node) and I am not so sure whether that's where the rosy future is.

by chx 10y ago

unclebucknasty 10y ago
Exactly. Intuitively, I don't think the problem can be solved with the same "let's glue together a bunch of stuff and call it a stack" approach that got us here.
- erlich 10y ago
  I'm hoping it is. We have ended up with really good tools compared to what we had before. Think about using commonjs requires, compared to the craziness of the Rails asset pipeline and sprockets, or manually specifying js files. We just need to standardize the glue...
  - unclebucknasty 10y ago
    Better bad is not the same as good. The approach itself yielded the issues such as that you reference, which have only been partially resolved by subsequent iterations of the same approach. I don't believe we should give credit for an approach that yields what is still a net-negative. It's a new thinking that we need, not reluctant acceptance of the best sub optimal execution the old thinking can deliver.
  - rpeden 10y ago
    The best part will be when we're all standardized on ES2015 modules instead of commonJS modules. I agree with you that CommonJS requires are nice to use, but since they're not statically analyzable the way ES2015 imports are, optimizing compilers like the Closure Compiler can't really analyze your entire application, including its dependencies. Once we've completely made the ES2015 transition (at least for front end modules), we might be in a position to see some really great front end tooling.
    - erlich 10y ago
      Yeh I initially hated that commonjs was not used for es2015 imports. Slowed down application startup and lack of node.js compatibility. But after reading the justification it will be better in the long run. We just need some way to lazy load modules.
gr3yh47 10y ago
it's not, because Mongo has huge issues [0] and angular is generally a giant mess and a pain in the ass [1] [0] http://blog.runnable.com/post/149000201856/think-before-you-mongo http://blog.runnable.com/post/149000201856/think-before-you-... [1] if you haven't used angular, ask someone who has
- jinfiesto 10y ago
  I work on a large (500000+ lines) of Angular daily. Maybe this represents some sort of Stockholm syndrome, but it's really not that bad?
  - clentaminator 10y ago
    Over half a million lines of Angular? May I ask what the application is and how that's broken down language-wise?
    - jinfiesto 10y ago
      Angular front-end, C# "middleware" to Java services layer. I was actually guessing when I tossed off 500k. I went and looked and it's actually closer to 250. Still pretty big though.
  - dcherman 10y ago
    Similar situation here, but it depends on your level of experience as well. Can you structure an AngularJS app so that it's (relatively) sane? Absolutely. It's also very easy to make a mess of things so that it's hard to reason about control flow; frameworks that are doing a better job of embracing unidirectional dataflow definitely help with this, but I don't blame Angular as it predates the wide adoption of that as a practice. It's also more difficult to follow practices like quickly rendering above the fold content; when you use the normal practice of writing re-usable directives, you end up needing to wait until at least Angular and any dependencies are loaded prior to being able to render any content at all. Server side rendering of initial content helps to alleviate that quite a bit since even though the content may not be interactive until your app bootstraps, the perceived load time is much better as the user has something to look at.
gr3yh47 10y ago
it's not, because Mongo has huge issues [0] and angular is generally a giant mess and a pain in the ass, with very poor separation of concerns.[1] [0] http://blog.runnable.com/post/149000201856/think-before-you-mongo http://blog.runnable.com/post/149000201856/think-before-you-... [1] if you haven't used angular, ask someone who has

That leads to the MEAN stack (Mongo, Express, Angular, Node) and I am not so sure whether that's where the rosy future is.

by chx 10y ago

That leads to the MEAN stack (Mongo, Express, Angular, Node) and I am not so sure whether that's where the rosy future is.

unclebucknasty 10y ago

Exactly. Intuitively, I don't think the problem can be solved with the same "let's glue together a bunch of stuff and call it a stack" approach that got us here.

erlich 10y ago
I'm hoping it is. We have ended up with really good tools compared to what we had before. Think about using commonjs requires, compared to the craziness of the Rails asset pipeline and sprockets, or manually specifying js files. We just need to standardize the glue...
- unclebucknasty 10y ago
  Better bad is not the same as good. The approach itself yielded the issues such as that you reference, which have only been partially resolved by subsequent iterations of the same approach. I don't believe we should give credit for an approach that yields what is still a net-negative. It's a new thinking that we need, not reluctant acceptance of the best sub optimal execution the old thinking can deliver.
- rpeden 10y ago
  The best part will be when we're all standardized on ES2015 modules instead of commonJS modules. I agree with you that CommonJS requires are nice to use, but since they're not statically analyzable the way ES2015 imports are, optimizing compilers like the Closure Compiler can't really analyze your entire application, including its dependencies. Once we've completely made the ES2015 transition (at least for front end modules), we might be in a position to see some really great front end tooling.
  - erlich 10y ago
    Yeh I initially hated that commonjs was not used for es2015 imports. Slowed down application startup and lack of node.js compatibility. But after reading the justification it will be better in the long run. We just need some way to lazy load modules.

gr3yh47 10y ago

it's not, because Mongo has huge issues [0] and angular is generally a giant mess and a pain in the ass [1] [0] http://blog.runnable.com/post/149000201856/think-before-you-mongo http://blog.runnable.com/post/149000201856/think-before-you-... [1] if you haven't used angular, ask someone who has

jinfiesto 10y ago
I work on a large (500000+ lines) of Angular daily. Maybe this represents some sort of Stockholm syndrome, but it's really not that bad?
- clentaminator 10y ago
  Over half a million lines of Angular? May I ask what the application is and how that's broken down language-wise?
  - jinfiesto 10y ago
    Angular front-end, C# "middleware" to Java services layer. I was actually guessing when I tossed off 500k. I went and looked and it's actually closer to 250. Still pretty big though.
- dcherman 10y ago
  Similar situation here, but it depends on your level of experience as well. Can you structure an AngularJS app so that it's (relatively) sane? Absolutely. It's also very easy to make a mess of things so that it's hard to reason about control flow; frameworks that are doing a better job of embracing unidirectional dataflow definitely help with this, but I don't blame Angular as it predates the wide adoption of that as a practice. It's also more difficult to follow practices like quickly rendering above the fold content; when you use the normal practice of writing re-usable directives, you end up needing to wait until at least Angular and any dependencies are loaded prior to being able to render any content at all. Server side rendering of initial content helps to alleviate that quite a bit since even though the content may not be interactive until your app bootstraps, the perceived load time is much better as the user has something to look at.

gr3yh47 10y ago

it's not, because Mongo has huge issues [0] and angular is generally a giant mess and a pain in the ass, with very poor separation of concerns.[1] [0] http://blog.runnable.com/post/149000201856/think-before-you-mongo http://blog.runnable.com/post/149000201856/think-before-you-... [1] if you haven't used angular, ask someone who has