4 ms·

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-engineeri

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.

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.