6 ms·

I just wish there was a way to fast forward 2 years into a 10k LOC project to find out what new problems this creates. After running after the new hotness in te

I just wish there was a way to fast forward 2 years into a 10k LOC project to find out what new problems this creates. After running after the new hotness in technology for the last 5 years, I've realised it's never about the problems it solves today. It's the shit that you have to maintain a couple of years down the line. (Not saying that this is bad -- just a random rant)

api 12y ago
I tried GWT years ago. It worked amazingly well, and let me write web apps in a real language. But it was significantly slower to develop a new site in GWT vs. plain vanilla HTML + CSS + JavaScript, and the speed to get up and running eventually seduced me away. Now I'm considering going back and giving it another try. It takes more time to get up and running with GWT, sure, but the stuff you do write with it is written in... well... a real language with types and good tooling and real design patterns. The result is an application you can maintain and build upon for a long period of time rather than a heap of web cruft that collapses quickly under its own weight. I know it's not sexy, but I've had the same experience you've had with "sexy." I'm becoming generally disillusioned with weakly typed and even dynamically typed languages -- they're fast to write but hard to maintain over long periods of time. http://www.gwtproject.org http://www.gwtproject.org
- spankalee 12y ago
  You should also look at Dart. It has a very fast iteration cycle and is a much nicer language that Java (in my very biased opinion - I worked on Dart).
- hderms 12y ago
  I echo your sentiments about disillusionment with weakly typed/dynamically typed languages and I still haven't really reached a situation where I was glad I didn't have a type system backing me.
- boobsbr 12y ago
  "real language"...
  - api 12y ago
    Not saying Java is the best language ever, just that it passes a certain minimum bar that JavaScript does not.
    - boobsbr 12y ago
      I'm a Java developer (and it might shock people, but I like it), where I work we're still stuck with good ol' Struts, it works, and a big international corporation uses this system. But comparing a functional scripting language with a object-oriented statically-typed pre-compiled language, arguing one is better than the other, does not make sense to me. You can easily revert the situation and say that static typing is a weakness of java, and it's poor fucntional (until before v8) capability is a drawback and a strong point for Javascript. I'm not into the JS world so I can't say anything about the tooling, but yes, Java's tooling and ecosystem is an extremely strong point. My complaint is about dismissing Javascript as not a "real language" while it's got A LOT going for it. EDIT: I also worked with GWT (GXT from ExtJs, actually) in 2011-2012, and it was really nice. I miss it.
- wtetzner 12y ago
  If you want a "real" language with types and whatnot, there's js_of_ocaml.
- porker 12y ago
  The other advantage with GWT I see is.. as the target changes, your app doesn't have to, only the transpiler. GWT can output to ExtJS, to <insert next HTML5/JS framework>, to <future platform>. And barring minor changes, your code stays the same. Now that is worth the investment.
- nogridbag 12y ago
  I used GWT for a few years on two projects, but I would not use it on any future projects. The first was using GXT, which you should probably avoid for public facing sites. We ran into some GWT compilation issues mainly due to code size a couple of times with some browsers, like Safari, that left us dead in the water until Google released an update. The second project used vanilla GWT and we were very happy with how performant it was. But we avoided lots of GWT features which seem over-engineered and complicated. We used JSON overlay types instead of RPC calls (which made our compilation / or dev mode much faster - I forget honestly). We avoided MVP, because I never met anyone who actually fully understood MVP with GWT. Instead, we had a very simple MVC structure that worked great for us (but lacked unit tests..). We avoided most of the CSS features because the complexity/value wasn't favorable for us. Moved on to a JS project afterwards and it was a breath of fresh air.
- deleted 12y ago
  [deleted]
state 12y ago
This is so true. On the one hand I wish that the docs for these projects could speak to those concerns, but on the other hand I'm not even sure how they would do that successfully. When something is this young it just takes time to figure out how it's going to survive and be maintained. I remember the days of using prototype.js over jquery. If only someone could have saved me the time.
- tomphoolery 12y ago
  > I remember the days of using prototype.js over jquery. If only someone could have saved me the time. There was plenty of criticism from the JS world when Prototype came out, and the main issue everyone had was how Prototype attempted to shoehorn classical OOP into JavaScript (hence, the abuse of prototypes and fake class inheritance), which is a mistake amateur JS developers make to this day. jQuery has at least made it so using the most popular DOM abstraction framework didn't also mean you were running less-than-ideal code inherently, but developers still manage to mess this one up. I think it's because when you learn how to program, you only learn the classical style, so you're not ready for the pitfalls of prototypal inheritance. So a lot of developers go through the "phase" of attempting to retro-fit their own ideas of how programming should work into a language that is designed in a totally different way, inevitably lead to problems, and have "the revelation" of understanding the prototypal inheritance idea. It's kind-of like a growing pain, which is why I'm really happy JS is being taught more heavily in schools and especially to entry-level programmers. Unlike Java, JavaScript is more accessible (just pop open the REPL in any browser) and its results are easier to observe. While it's not a great tool to teach people the concepts of OOP, I think it's very useful to teach kids at a young age that there isn't just one way to do things. They're different enough to screw developers up on a day-to-day basis, but not different enough that spending a few weeks with the language isn't enough to grasp its power. As others have said, you really didn't waste your time there. If anything, it was simply a matter of JS developers collectively and simultaneously going through the same growing pains and eventual realizations about how the language works.
  - marrs 12y ago
    While it's not a great tool to teach people the concepts of OOP... I actually think it's a very good tool for teaching OOP. It doesn't have types to confuse the issue, it favours composition over inheritance by design, and it fully encapsulates state. You could do much worse than JS as a teaching language. In fact, I'd say that it was only through practical application in JS that I fully appreciated the concepts extolled by Smalltalk, Self, and Lisp. Had I worked in a Java environment I may not have had those insights until much later.
v13inc 12y ago
Those problems are best solved with Engineering best practices and culture, in my opinion. Each tough / innovative problem is probably somewhat unique for your startup, and picking a solution (a front-end framework) before you even know the problem limits your ability to solve it creativily. Most programmers are good enough that with a good refactoring culture, they can evolve the equivalent of an in-house framework. Although, for some reason, I gather that programmers are scared of in-house "frameworks". I think that attitude is short-sighted since the app you build on top of the framework will end up being more complex than the framework itself.
- RussianCow 12y ago
  It goes both ways. By rolling your own framework, you inevitably end up reinventing the wheel and solving problems that have already been solved. For each feature you need, you either have to create your own solution, or manually integrate a bunch of smaller libraries. On the other hand, committing to an established framework means you have to work around issues that the framework was not designed to solve. I wouldn't dismiss using an established framework as "short-sighted". It's a tradeoff: the more complex and unique your problems are, the more it makes sense to roll your own.
  - deleted 12y ago
    [deleted]
  - v13inc 12y ago
    I agree there. Deciding on tooling for a long term project is a very tough balancing act. Although I am a bit afraid that people overestimate the costs of rolling your own code, or "re-inventing the wheel". In most cases you aren't reinventing the wheel, because there are well documented bodies of reference for the design of almost any wheel you could need. Building (writing) a wheel (code) from scratch against a spec is much, much less complicated than inventing it. Likewise: assembling your own set of design patterns and writing code from scratch is not "re-inventing", and is a lot easier than we give it credit for.
    - 12y ago
lhorie 12y ago
FWIW, the framework I wrote (Mithril) is a direct product of working on a multiple-man-year Angular codebase and the pains that arise from such a beast. I wrote about that here ( http://lhorie.github.io/mithril-blog/lessons-learned-from-angular.html http://lhorie.github.io/mithril-blog/lessons-learned-from-an... ) On a related topic, I talk about complexity walls (the idea of code that outgrows a framework's zone of comfort) here ( http://lhorie.github.io/mithril-blog/decreasing-cognitive-load.html http://lhorie.github.io/mithril-blog/decreasing-cognitive-lo... ) and there are slides for a presentation I gave a while back that talks about the design decisions that went into Mithril to reduce learning curves. (here: http://lhorie.github.io/mithril-presentation-oct-js-tech-night/ http://lhorie.github.io/mithril-presentation-oct-js-tech-nig... )
- easymovet 12y ago
  Where does Mithril fit in this stack: RequireJs, Knockout (with components), SammyJS (for routing/browser history and events)? --After doing some reading it looks like it replaces some of knockout and sammy but I'd lose data binding and dependency tracking of knockout.
  - lhorie 12y ago
    Mithril is roughly equal in scope to Knockout+Sammy. The small gap between what most frameworks call "bidirectional data binding" and what it actually is in terms of vanilla js can be bridged with simple functions (I talk about that in a slightly more advanced context here: http://lhorie.github.io/mithril-blog/asymmetrical-data-bindings.html http://lhorie.github.io/mithril-blog/asymmetrical-data-bindi... ). Dependency tracking can refer to two things: tracking changes for the purpose of updating the DOM (which Mithril does handle, albeit in a different way), or computed properties (which I personally think are not a good idea, but that you could do w/ an observable library from microjs)
- sanityinc 12y ago
  Mithril is a tremendous little framework, and Leo has done an exemplary job of writing it, documenting it and blogging about usage patterns and tricks. While declining frequent requests that he cram more functionality into its core, he takes the time to explain the trade-offs, showing a deep understanding of the problem space which gives me confidence to build upon his work. So thanks Leo! Hopefully, in time, more people will realise the "zen" of mithril's minimal approach. In the meantime, interested readers can check out lichess.org, which recently rewrote its impressive UI using mithril.
desireco42 12y ago
Ha ha ha, this is awesome. Thank you for writing this. You have to admit, benefits that are provided sound amazing, hard to look over. It is interesting times for sure.
xmonkee 12y ago
Nanda? Haha funny to run into you here. Kaisa chal raha hai?
- saurabhnanda 12y ago
  I couldn't find out more about you from your HN username. Care to ping me on twitter @saurabhnanda ?

api 12y ago

I tried GWT years ago. It worked amazingly well, and let me write web apps in a real language. But it was significantly slower to develop a new site in GWT vs. plain vanilla HTML + CSS + JavaScript, and the speed to get up and running eventually seduced me away. Now I'm considering going back and giving it another try. It takes more time to get up and running with GWT, sure, but the stuff you do write with it is written in... well... a real language with types and good tooling and real design patterns. The result is an application you can maintain and build upon for a long period of time rather than a heap of web cruft that collapses quickly under its own weight. I know it's not sexy, but I've had the same experience you've had with "sexy." I'm becoming generally disillusioned with weakly typed and even dynamically typed languages -- they're fast to write but hard to maintain over long periods of time. http://www.gwtproject.org http://www.gwtproject.org

spankalee 12y ago
You should also look at Dart. It has a very fast iteration cycle and is a much nicer language that Java (in my very biased opinion - I worked on Dart).
hderms 12y ago
I echo your sentiments about disillusionment with weakly typed/dynamically typed languages and I still haven't really reached a situation where I was glad I didn't have a type system backing me.
boobsbr 12y ago
"real language"...
- api 12y ago
  Not saying Java is the best language ever, just that it passes a certain minimum bar that JavaScript does not.
  - boobsbr 12y ago
    I'm a Java developer (and it might shock people, but I like it), where I work we're still stuck with good ol' Struts, it works, and a big international corporation uses this system. But comparing a functional scripting language with a object-oriented statically-typed pre-compiled language, arguing one is better than the other, does not make sense to me. You can easily revert the situation and say that static typing is a weakness of java, and it's poor fucntional (until before v8) capability is a drawback and a strong point for Javascript. I'm not into the JS world so I can't say anything about the tooling, but yes, Java's tooling and ecosystem is an extremely strong point. My complaint is about dismissing Javascript as not a "real language" while it's got A LOT going for it. EDIT: I also worked with GWT (GXT from ExtJs, actually) in 2011-2012, and it was really nice. I miss it.
wtetzner 12y ago
If you want a "real" language with types and whatnot, there's js_of_ocaml.
porker 12y ago
The other advantage with GWT I see is.. as the target changes, your app doesn't have to, only the transpiler. GWT can output to ExtJS, to <insert next HTML5/JS framework>, to <future platform>. And barring minor changes, your code stays the same. Now that is worth the investment.
nogridbag 12y ago
I used GWT for a few years on two projects, but I would not use it on any future projects. The first was using GXT, which you should probably avoid for public facing sites. We ran into some GWT compilation issues mainly due to code size a couple of times with some browsers, like Safari, that left us dead in the water until Google released an update. The second project used vanilla GWT and we were very happy with how performant it was. But we avoided lots of GWT features which seem over-engineered and complicated. We used JSON overlay types instead of RPC calls (which made our compilation / or dev mode much faster - I forget honestly). We avoided MVP, because I never met anyone who actually fully understood MVP with GWT. Instead, we had a very simple MVC structure that worked great for us (but lacked unit tests..). We avoided most of the CSS features because the complexity/value wasn't favorable for us. Moved on to a JS project afterwards and it was a breath of fresh air.
deleted 12y ago
[deleted]

state 12y ago

This is so true. On the one hand I wish that the docs for these projects could speak to those concerns, but on the other hand I'm not even sure how they would do that successfully. When something is this young it just takes time to figure out how it's going to survive and be maintained. I remember the days of using prototype.js over jquery. If only someone could have saved me the time.

tomphoolery 12y ago
> I remember the days of using prototype.js over jquery. If only someone could have saved me the time. There was plenty of criticism from the JS world when Prototype came out, and the main issue everyone had was how Prototype attempted to shoehorn classical OOP into JavaScript (hence, the abuse of prototypes and fake class inheritance), which is a mistake amateur JS developers make to this day. jQuery has at least made it so using the most popular DOM abstraction framework didn't also mean you were running less-than-ideal code inherently, but developers still manage to mess this one up. I think it's because when you learn how to program, you only learn the classical style, so you're not ready for the pitfalls of prototypal inheritance. So a lot of developers go through the "phase" of attempting to retro-fit their own ideas of how programming should work into a language that is designed in a totally different way, inevitably lead to problems, and have "the revelation" of understanding the prototypal inheritance idea. It's kind-of like a growing pain, which is why I'm really happy JS is being taught more heavily in schools and especially to entry-level programmers. Unlike Java, JavaScript is more accessible (just pop open the REPL in any browser) and its results are easier to observe. While it's not a great tool to teach people the concepts of OOP, I think it's very useful to teach kids at a young age that there isn't just one way to do things. They're different enough to screw developers up on a day-to-day basis, but not different enough that spending a few weeks with the language isn't enough to grasp its power. As others have said, you really didn't waste your time there. If anything, it was simply a matter of JS developers collectively and simultaneously going through the same growing pains and eventual realizations about how the language works.
- marrs 12y ago
  While it's not a great tool to teach people the concepts of OOP... I actually think it's a very good tool for teaching OOP. It doesn't have types to confuse the issue, it favours composition over inheritance by design, and it fully encapsulates state. You could do much worse than JS as a teaching language. In fact, I'd say that it was only through practical application in JS that I fully appreciated the concepts extolled by Smalltalk, Self, and Lisp. Had I worked in a Java environment I may not have had those insights until much later.

v13inc 12y ago

Those problems are best solved with Engineering best practices and culture, in my opinion. Each tough / innovative problem is probably somewhat unique for your startup, and picking a solution (a front-end framework) before you even know the problem limits your ability to solve it creativily. Most programmers are good enough that with a good refactoring culture, they can evolve the equivalent of an in-house framework. Although, for some reason, I gather that programmers are scared of in-house "frameworks". I think that attitude is short-sighted since the app you build on top of the framework will end up being more complex than the framework itself.

RussianCow 12y ago
It goes both ways. By rolling your own framework, you inevitably end up reinventing the wheel and solving problems that have already been solved. For each feature you need, you either have to create your own solution, or manually integrate a bunch of smaller libraries. On the other hand, committing to an established framework means you have to work around issues that the framework was not designed to solve. I wouldn't dismiss using an established framework as "short-sighted". It's a tradeoff: the more complex and unique your problems are, the more it makes sense to roll your own.
- deleted 12y ago
  [deleted]
- v13inc 12y ago
  I agree there. Deciding on tooling for a long term project is a very tough balancing act. Although I am a bit afraid that people overestimate the costs of rolling your own code, or "re-inventing the wheel". In most cases you aren't reinventing the wheel, because there are well documented bodies of reference for the design of almost any wheel you could need. Building (writing) a wheel (code) from scratch against a spec is much, much less complicated than inventing it. Likewise: assembling your own set of design patterns and writing code from scratch is not "re-inventing", and is a lot easier than we give it credit for.
  - 12y ago

lhorie 12y ago

FWIW, the framework I wrote (Mithril) is a direct product of working on a multiple-man-year Angular codebase and the pains that arise from such a beast. I wrote about that here ( http://lhorie.github.io/mithril-blog/lessons-learned-from-angular.html http://lhorie.github.io/mithril-blog/lessons-learned-from-an... ) On a related topic, I talk about complexity walls (the idea of code that outgrows a framework's zone of comfort) here ( http://lhorie.github.io/mithril-blog/decreasing-cognitive-load.html http://lhorie.github.io/mithril-blog/decreasing-cognitive-lo... ) and there are slides for a presentation I gave a while back that talks about the design decisions that went into Mithril to reduce learning curves. (here: http://lhorie.github.io/mithril-presentation-oct-js-tech-night/ http://lhorie.github.io/mithril-presentation-oct-js-tech-nig... )

easymovet 12y ago
Where does Mithril fit in this stack: RequireJs, Knockout (with components), SammyJS (for routing/browser history and events)? --After doing some reading it looks like it replaces some of knockout and sammy but I'd lose data binding and dependency tracking of knockout.
- lhorie 12y ago
  Mithril is roughly equal in scope to Knockout+Sammy. The small gap between what most frameworks call "bidirectional data binding" and what it actually is in terms of vanilla js can be bridged with simple functions (I talk about that in a slightly more advanced context here: http://lhorie.github.io/mithril-blog/asymmetrical-data-bindings.html http://lhorie.github.io/mithril-blog/asymmetrical-data-bindi... ). Dependency tracking can refer to two things: tracking changes for the purpose of updating the DOM (which Mithril does handle, albeit in a different way), or computed properties (which I personally think are not a good idea, but that you could do w/ an observable library from microjs)
sanityinc 12y ago
Mithril is a tremendous little framework, and Leo has done an exemplary job of writing it, documenting it and blogging about usage patterns and tricks. While declining frequent requests that he cram more functionality into its core, he takes the time to explain the trade-offs, showing a deep understanding of the problem space which gives me confidence to build upon his work. So thanks Leo! Hopefully, in time, more people will realise the "zen" of mithril's minimal approach. In the meantime, interested readers can check out lichess.org, which recently rewrote its impressive UI using mithril.

desireco42 12y ago

Ha ha ha, this is awesome. Thank you for writing this. You have to admit, benefits that are provided sound amazing, hard to look over. It is interesting times for sure.

xmonkee 12y ago

Nanda? Haha funny to run into you here. Kaisa chal raha hai?

saurabhnanda 12y ago
I couldn't find out more about you from your HN username. Care to ping me on twitter @saurabhnanda ?