10 ms·

Angular 2 First App Post-Mortem

52 points by Halienja 11y ago

runin2k1 11y ago
I hate to be cynical, but reading an article like this makes me chuckle to myself thinking about how much vitriol is still spewed at Java for its over-engineering dark ages. I start to have flashbacks when an innocent sounding article like this has so much word soup that it has to be cross-referenced against half a dozen other technologies. For Javascript's sake, I propose we skip the phase where we implement Enterprise JS Beans, and go straight to Spring JS so we can all finally get some work done.
- leeoniya 11y ago
  "All problems in computer science can be solved by another level of abstraction...except for the problem of too many levels of abstraction." [1] BTW, if you want less framework-ness. Try a lightweight vdom lib. I worked with Mithril [2] for a while but after a few projects decided that MVC was poorly suited for front-end components. I'm writing what IMO is a great vdom view layer that's extremely fast, ~8k min, flexible (imperative/declarative), pure js and pleasant to use [3]. Feedback welcome :) [1] https://en.wikipedia.org/wiki/Indirection https://en.wikipedia.org/wiki/Indirection [2] http://mithril.js.org/ http://mithril.js.org/ [3] https://github.com/leeoniya/domvm https://github.com/leeoniya/domvm
  - faizshah 11y ago
    I like it! Can you add a comparison section to mithriljs and/or infernojs (the current leader in vdom performance)? Also an example for routing would be nice. Keep up the great work!
    - leeoniya 11y ago
      perf is 2x mithril and 1x inferno at high mutations and "only" 0.5x inferno at low mutations. "only" because domvm gets 70/s vs inferno's 135/s on my i5 cpu on dbmonster at 1% mutation. however, domvm views support isolated redraw and even granular node-level patching. so you can optimize much faster if needed see here: http://mathieuancelin.github.io/js-repaint-perfs/ http://mathieuancelin.github.io/js-repaint-perfs/ no routing yet, but some plans are brewing...wip :)
  - esaym 11y ago
    domvm looks like something I might use. I know javascript, but I never could wrap my head around the larger frameworks.
    - leeoniya 11y ago
      would be glad to answer any questions. feel free to open issues. the docs are sufficient but far from exhaustive.
- deleted 11y ago
  [deleted]
- alistproducer2 11y ago
  As a JS lover, it makes me sad how convoluted the tool chain has become in recent years. All the devs who use these tools keep telling themselves and anyone who will listen how simple and efficient their stack is - despite relying on 5-8 different libraries, frameworks, patterns, etc.
  - lectrick 11y ago
    I'm kinda glad I left frontend dev just as JQuery peaked lol
  - TheOtherHobbes 11y ago
    It's not Real Programming [tm] unless there's a scripted build system. And a big conference.
    - nilliams 11y ago
      To be fair, not everyone is suggesting you need a scripted build system, but you do need some sort of build step, because <script> tags just aren't sufficient for anything beyond a trivial app. (Also ultimately, you do need to minify your code for production). This build step can just be 'browserify main.js -o bundle.js'. This is where I suggest people start or go back to if they are intimidated by all the various options.
- rpeden 11y ago
  No kidding. I've done a ton of professional development in Angular, and a fair amount recently in React. I've enjoyed them both a lot. When I think deeply about it though, I'm not sure that any of it is better than what I experienced on a pretty big GWT project back in 2010. Yes, everyone was horrified that I was compiling Java to JavaScript. But everything just worked. I had a nice MVP architecture set up, and dependency injection using Guice. Maven was a minor pain at times, but mostly just worked to handle dependencies and get things built. Debugging in Eclipse while the app was running in the browser just worked. I really liked UiBinder templates. It definitely didn't feel like heavyweight Java. Just a bunch of lightweight components communicating asynchronously though an event bus. The JavaScript ecosystem has definitely made some huge strides over the past couple of years. Time will tell if we see enough ROI on the complexity explosion to make it worthwhile.
  - edwinnathaniel 11y ago
    > When I think deeply about it though, I'm not sure that any of it is better than what I experienced on a pretty big GWT project back in 2010. Yes, everyone was horrified that I was compiling Java to JavaScript. But everything just worked. I used GWT in 2008 - 2010 and I would 1000% agree with you. I'm currently working in a large team (100 ish Devs) for a large project written in 95% JS so I have something legit to compare with my previous experience. GWT goes like this: Maven + MVP + EventBus + minimum DI + JUnit trumps the fiasco I'm dealing with JavaScript ecosystems nowadays. It's sad that GWT didn't win mindshare due to a few reasons: - Bad Rap: Java in 2006-2010 was getting a lot of heat from Rais, Google Wave was a flop (it was the most-talked GWT project) - Back-end Dev rarely wants to touch Front-End development and Java developers are largely Back-end Dev - Front-end Dev hates "enterprisey" so they refused Java and its ecosystems - In general, front-end community didn't have a solid grasp of good software practices hence perhaps they don't quite understand the benefits of GWT (feels like I'm throwing blanketed statement but bear with me). GWT was ahead (and probably still!) of everything: - Dealing with Sprites and Resources a LOT easier than anything in front-end stuff we have to deal these days - i18n framework built-in (have you ever seen a JS solution for i18n? doubtful) - Pruning dead code! - Static Analysis via Java - Good Solid unit-testing framework again via Java (no QUnit vs Jasmine vs Mocha) - That debugger .... very sexy! - SASS? LESS? Nah... GWT has a good solution for that...(ClientBundle) - Sane and Stable Date and Number formatter Hm.... I'm re-thinking of using GWT again for my side project....
- ken47 11y ago
  This is an artifact of the maximum complexity of front end apps having risen dramatically in recent years.
  - aikah 11y ago
    > This is an artifact of the maximum complexity of front end apps having risen dramatically in recent years. Front-end apps aren't more complex. Back in 2006-7 people were already writing complex front-end apps with frameworks like GWT or ext-js. What changed is front-end developers dropped the widget oriented frameworks for a lower level approach (stateless components). But the complexity of the apps have not risen. You don't need IoC containers with javascript, it's useful but not mandatory. Angular2 tries to be some kind of kitchen sink of web frameworks but is losing its pragmatism in the process. I can guarantee that it will be drag its adoption speed.
EvanPlaice 11y ago
As somebody who has been writing an Angular2 app in ES6, it kind of saddens me that Google has gone all-in on Typescript despite it's glaring departure from future web standards. Specifically, the parameter annotation syntax they use is much different from that proposed in the future ES7 spec. I really like Angular2 but it's hard not to feel like it was created as a promotional tool for Typescript adoption. Types in JS are mostly 'window dressing' to protect devs from themselves and allow for better autocomplete support. They come with a performance overhead so they'll be disabled in production anyway. Anyway, it's very interesting that Op went with Redux. Redux is pretty game changing in terms of reducing the feedback cycle between changes. Hopefully, better Redux support in NG2 is forthcoming.
- Matthias247 11y ago
  Types come with a performance overhead and will be disabled in production? Sorry, I don't understand that. Typescript transpiles to plain JS, so there are no types at runtime no matter whetzer you are developing or in production. And therefore there is also no performance overhead. The only overhead I can think of is if you are transpiling code at runtime instead of build time using some JSPM plugin - but then the overhead is not related to types but to transpiling (it would also be there for typeless coffeescript transpiling). And I also thought that typescript decorators are explicitily following the most recent ES7 decorator proposals and are even marked as experimental in TS to be able to react to changes if the ES7 syntax changes.
cheez 11y ago
Uh... I'm relatively new to JS but why the heck are you mixing Redux and angular?
- bgnm2000 11y ago
  Redux can be used in any javascript app. Its a pattern, not something stuck to react.
  - cheez 11y ago
    True, but with redux and angular, now you have two things where state could live.
    - nilliams 11y ago
      You have 2 possibilities yes, but afaict Angular 2 doesn't push you to use 'its way', unlike the early days of Angular 1 where 'the way' to do state was $scope. So I could see how you could comfortably use Angular 2 with Redux as long as your team was on-board to always do state the Redux way.
      - cheez 11y ago
        Give a developer an inch and they'll take the football field. Maybe that's an acceptable risk, but I wouldn't take that risk.
  - danmaz74 11y ago
    Nitpicking: Flux is a pattern, Redux is a library (which implements something similar, but not exactly the Flux pattern).
randlet 11y ago
I leveraged the Flux architecture powered by the immensely popular Redux library. For a cleaner integration with Angular 2’s injector and TypeScript’s type system, I wrote a class-based wrapper around Redux that exposes state changes using RxJS observables. Consumers can subscribe to these observables and use the Store class to dispatch state-changing actions. This reads like a Markov chain generated from a pool of top voted Hacker News Javascript submissions.
- Geee 11y ago
  Hah. Just the other day I was swearing about the Javascript trend that there is always an obscure thing X that solves obscure thing Y. And then there's huge hype about it.
- m_fayer 11y ago
  I know what you mean, and yet this buzzword heavy cosmetically obscure quote, when realized, results in an IMO simpler, clearer, and more elegant end product and developer experience. Funny, that.

52 points by Halienja 11y ago

I hate to be cynical, but reading an article like this makes me chuckle to myself thinking about how much vitriol is still spewed at Java for its over-engineering dark ages. I start to have flashbacks when an innocent sounding article like this has so much word soup that it has to be cross-referenced against half a dozen other technologies. For Javascript's sake, I propose we skip the phase where we implement Enterprise JS Beans, and go straight to Spring JS so we can all finally get some work done.

leeoniya 11y ago
"All problems in computer science can be solved by another level of abstraction...except for the problem of too many levels of abstraction." [1] BTW, if you want less framework-ness. Try a lightweight vdom lib. I worked with Mithril [2] for a while but after a few projects decided that MVC was poorly suited for front-end components. I'm writing what IMO is a great vdom view layer that's extremely fast, ~8k min, flexible (imperative/declarative), pure js and pleasant to use [3]. Feedback welcome :) [1] https://en.wikipedia.org/wiki/Indirection https://en.wikipedia.org/wiki/Indirection [2] http://mithril.js.org/ http://mithril.js.org/ [3] https://github.com/leeoniya/domvm https://github.com/leeoniya/domvm
- faizshah 11y ago
  I like it! Can you add a comparison section to mithriljs and/or infernojs (the current leader in vdom performance)? Also an example for routing would be nice. Keep up the great work!
  - leeoniya 11y ago
    perf is 2x mithril and 1x inferno at high mutations and "only" 0.5x inferno at low mutations. "only" because domvm gets 70/s vs inferno's 135/s on my i5 cpu on dbmonster at 1% mutation. however, domvm views support isolated redraw and even granular node-level patching. so you can optimize much faster if needed see here: http://mathieuancelin.github.io/js-repaint-perfs/ http://mathieuancelin.github.io/js-repaint-perfs/ no routing yet, but some plans are brewing...wip :)
- esaym 11y ago
  domvm looks like something I might use. I know javascript, but I never could wrap my head around the larger frameworks.
  - leeoniya 11y ago
    would be glad to answer any questions. feel free to open issues. the docs are sufficient but far from exhaustive.
deleted 11y ago
[deleted]
alistproducer2 11y ago
As a JS lover, it makes me sad how convoluted the tool chain has become in recent years. All the devs who use these tools keep telling themselves and anyone who will listen how simple and efficient their stack is - despite relying on 5-8 different libraries, frameworks, patterns, etc.
- lectrick 11y ago
  I'm kinda glad I left frontend dev just as JQuery peaked lol
- TheOtherHobbes 11y ago
  It's not Real Programming [tm] unless there's a scripted build system. And a big conference.
  - nilliams 11y ago
    To be fair, not everyone is suggesting you need a scripted build system, but you do need some sort of build step, because <script> tags just aren't sufficient for anything beyond a trivial app. (Also ultimately, you do need to minify your code for production). This build step can just be 'browserify main.js -o bundle.js'. This is where I suggest people start or go back to if they are intimidated by all the various options.
rpeden 11y ago
No kidding. I've done a ton of professional development in Angular, and a fair amount recently in React. I've enjoyed them both a lot. When I think deeply about it though, I'm not sure that any of it is better than what I experienced on a pretty big GWT project back in 2010. Yes, everyone was horrified that I was compiling Java to JavaScript. But everything just worked. I had a nice MVP architecture set up, and dependency injection using Guice. Maven was a minor pain at times, but mostly just worked to handle dependencies and get things built. Debugging in Eclipse while the app was running in the browser just worked. I really liked UiBinder templates. It definitely didn't feel like heavyweight Java. Just a bunch of lightweight components communicating asynchronously though an event bus. The JavaScript ecosystem has definitely made some huge strides over the past couple of years. Time will tell if we see enough ROI on the complexity explosion to make it worthwhile.
- edwinnathaniel 11y ago
  > When I think deeply about it though, I'm not sure that any of it is better than what I experienced on a pretty big GWT project back in 2010. Yes, everyone was horrified that I was compiling Java to JavaScript. But everything just worked. I used GWT in 2008 - 2010 and I would 1000% agree with you. I'm currently working in a large team (100 ish Devs) for a large project written in 95% JS so I have something legit to compare with my previous experience. GWT goes like this: Maven + MVP + EventBus + minimum DI + JUnit trumps the fiasco I'm dealing with JavaScript ecosystems nowadays. It's sad that GWT didn't win mindshare due to a few reasons: - Bad Rap: Java in 2006-2010 was getting a lot of heat from Rais, Google Wave was a flop (it was the most-talked GWT project) - Back-end Dev rarely wants to touch Front-End development and Java developers are largely Back-end Dev - Front-end Dev hates "enterprisey" so they refused Java and its ecosystems - In general, front-end community didn't have a solid grasp of good software practices hence perhaps they don't quite understand the benefits of GWT (feels like I'm throwing blanketed statement but bear with me). GWT was ahead (and probably still!) of everything: - Dealing with Sprites and Resources a LOT easier than anything in front-end stuff we have to deal these days - i18n framework built-in (have you ever seen a JS solution for i18n? doubtful) - Pruning dead code! - Static Analysis via Java - Good Solid unit-testing framework again via Java (no QUnit vs Jasmine vs Mocha) - That debugger .... very sexy! - SASS? LESS? Nah... GWT has a good solution for that...(ClientBundle) - Sane and Stable Date and Number formatter Hm.... I'm re-thinking of using GWT again for my side project....
ken47 11y ago
This is an artifact of the maximum complexity of front end apps having risen dramatically in recent years.
- aikah 11y ago
  > This is an artifact of the maximum complexity of front end apps having risen dramatically in recent years. Front-end apps aren't more complex. Back in 2006-7 people were already writing complex front-end apps with frameworks like GWT or ext-js. What changed is front-end developers dropped the widget oriented frameworks for a lower level approach (stateless components). But the complexity of the apps have not risen. You don't need IoC containers with javascript, it's useful but not mandatory. Angular2 tries to be some kind of kitchen sink of web frameworks but is losing its pragmatism in the process. I can guarantee that it will be drag its adoption speed.

EvanPlaice 11y ago

As somebody who has been writing an Angular2 app in ES6, it kind of saddens me that Google has gone all-in on Typescript despite it's glaring departure from future web standards. Specifically, the parameter annotation syntax they use is much different from that proposed in the future ES7 spec. I really like Angular2 but it's hard not to feel like it was created as a promotional tool for Typescript adoption. Types in JS are mostly 'window dressing' to protect devs from themselves and allow for better autocomplete support. They come with a performance overhead so they'll be disabled in production anyway. Anyway, it's very interesting that Op went with Redux. Redux is pretty game changing in terms of reducing the feedback cycle between changes. Hopefully, better Redux support in NG2 is forthcoming.

Matthias247 11y ago
Types come with a performance overhead and will be disabled in production? Sorry, I don't understand that. Typescript transpiles to plain JS, so there are no types at runtime no matter whetzer you are developing or in production. And therefore there is also no performance overhead. The only overhead I can think of is if you are transpiling code at runtime instead of build time using some JSPM plugin - but then the overhead is not related to types but to transpiling (it would also be there for typeless coffeescript transpiling). And I also thought that typescript decorators are explicitily following the most recent ES7 decorator proposals and are even marked as experimental in TS to be able to react to changes if the ES7 syntax changes.

cheez 11y ago

Uh... I'm relatively new to JS but why the heck are you mixing Redux and angular?

bgnm2000 11y ago
Redux can be used in any javascript app. Its a pattern, not something stuck to react.
- cheez 11y ago
  True, but with redux and angular, now you have two things where state could live.
  - nilliams 11y ago
    You have 2 possibilities yes, but afaict Angular 2 doesn't push you to use 'its way', unlike the early days of Angular 1 where 'the way' to do state was $scope. So I could see how you could comfortably use Angular 2 with Redux as long as your team was on-board to always do state the Redux way.
    - cheez 11y ago
      Give a developer an inch and they'll take the football field. Maybe that's an acceptable risk, but I wouldn't take that risk.
- danmaz74 11y ago
  Nitpicking: Flux is a pattern, Redux is a library (which implements something similar, but not exactly the Flux pattern).

randlet 11y ago

I leveraged the Flux architecture powered by the immensely popular Redux library. For a cleaner integration with Angular 2’s injector and TypeScript’s type system, I wrote a class-based wrapper around Redux that exposes state changes using RxJS observables. Consumers can subscribe to these observables and use the Store class to dispatch state-changing actions. This reads like a Markov chain generated from a pool of top voted Hacker News Javascript submissions.

Geee 11y ago
Hah. Just the other day I was swearing about the Javascript trend that there is always an obscure thing X that solves obscure thing Y. And then there's huge hype about it.
m_fayer 11y ago
I know what you mean, and yet this buzzword heavy cosmetically obscure quote, when realized, results in an IMO simpler, clearer, and more elegant end product and developer experience. Funny, that.