ok, and what do yoiu think your reposting it here proves?



nearly zero learning curve, and no framework lockin.

also, a design based on an incredibly simple mental model. It's the same as react's, and in my OP i specifically said that if you care about a large community and future support, you should look into that. Here's a good article that explains why I prefer the React/mithril approach:

http://jlongster.com/Removing-User-I...act-is-Awesome

I don't think we're going to have a meeting of the minds on this point, because you are quoting google search popularity and SO stats as if that proves superiority somehow. Populism is just not a valid argument for me. As a general rule, it rarely correlates with quality, though it does, as you say, correlate with feature agglomeration and good-enough quality.


I don't buy the "just ignore it if you aren't using it" argument. Why would you complain about carrying around a keychain with 50 keys on it? If you don't use the other 49 keys just ignore them....

It's got 2k github stars, so while it's a far cry from a "major" framework (react has ~11k and angular about 30k) I think "pet little framework" is inaccurate too. Support is in a google group with a decent number of posts, and the framework author himself typically answers questions within a day or two if they don't get responses.

1) I learned something new by learning mithril.
2) Sure, mithril is not as effective a resume padder as angular, i'll grant you that. So what? I don't care about that. I care about using tools I like that allow me develop products more effectively.
3) Very useful from a "business" standpoint if being productive matters to you. With angular, I feel I am fighting my tools.

Not fair. I spent well more than a weekend evaluating angular. I feel comfortable that my opinion is backed up by research and I stand behind it.

Also, your analogy suggests that I am somehow "afraid" of hard but useful concepts and want to take the easy way out. Not true it all. I love hard but useful concepts, am constantly learning new things, and I feel like Mithril allows me take advantage of all I've learned by not dictating how I should design my application. It's not that angular has profound things to teach me that I'm not ready to learn. I was down in the angular source code during the time I was into it. I've simply concluded that it's design is ultimately bad. I don't care how many SO posts it has or how popular it is.

Thanks for all the responses.

Just trying to read about React and jfc Facebook do a bad job of explaining it. Nothing new there, programmers tend to be absurdly susceptible to the curse of knowledge. I know I am. Anyway this is how they kick off:

In other words, "building applications". Explain to me why I want this.

And off we are into what it does, and not why I would want to use it. "What makes React different is that it uses a virtual DOM and blah blah....". Why am I having implementation explained to me?

Maybe it's just trying to solve a problem I don't have, but so far I'm not getting it.

"You can build reusable components that are encapsulated and can be used declaratively!". OK, so it's Angular directives except with the semantic niceness obliterated by a tangle of boilerplate Javascript?

"You'll never have to do DOM manipulation again!". Yeah, but as far as I can see that's because I have to write complex render methods instead.

"It renders faster than other frameworks!". I make applications for businesses, I'm not building the next Instagram. Performance improvements measured in milliseconds are way down the list of stuff I care about.

"It plays nice with SEO!". Ditto, I don't care about that at all.

I'm sure I just don't "get it", but so far I'm not even grasping what the "it" is that I'm supposed to get.

Read the article I linked to my in my last response to candybar. It explains the high level ideas very well.

EDIT: and here's another good intro, specific to react: http://facebook.github.io/react/blog...-in-react.html

Is it not strange for someone to complain about having to learn non-standard stuff in AngularJS, then offering JSX and Sweet.js as alternatives? At least non-standard stuff in AngularJS has better reasons for it. In practice, having HTML templates that don't allow for arbitrary code blocks inside them leads to easier maintenance burdens. This is a lesson we learned way back in the 90's from JSP, ASP and PHP and a lesson we keep relearning every time someone introduces a templating language that's arbitrarily programmable. Don't forget that at many companies, the guy who works on the HTML template isn't the same guy who writes Javascript.

Does not follow.

So code written to Mithril's API magically works without Mithril? Any time you offer features over standard Javascript that isn't implemented precisely the same way in another framework, you're offering a lock-in. In practice, an AngularJS code base is far more likely to be useful in 5 years than a Mithril code base.

It's about long-term sustainability and maturity. A tool no one is using almost by definition is not production-ready, because it takes a certain level of adoption before all the show-stopping bugs and design issues are found and the tool becomes stable enough for you to use without constantly changing the source code yourself. A framework no one is using whose API you're reliant is going to cause an actual framework lock-in issue, as opposed to hypothetical lock-in problems you're talking about with AngularJS. AngularJS API is also more likely to be stable than Mithril going forward.

Because it benefits you to have useless features, as long as they are useful for others - it creates a larger ecosystem. It's quite likely that in these ecosystems, things you may find useless are essential for building things that you find useful. Even if that wasn't the case, would it be better if we had 5000 different Java/.NET type ecosystems each of which has a different combination of features? And everyone has to relearn everything when they move from one project to another? It's much more likely that you don't know the complex requirements of your application 5 years down the road than Java/.NET projects have thrown away hundreds of developer-years creating and maintaining libraries no one needs. Again, if you're just developing throwaway applications, none of this matters, but if you're developing throwaway applications, why all this fuss about domain modeling and testability and framework lock-in and stuff?

Either your code has long-term value, in which case, popularity, long-term sustainability, feature completeness, ecosystem of the framework are important concerns; or not, in which case arguments about framework lock-in, domain modeling and testability seem really hollow.


GitHub stars have very little to do with project maturity. Lots of presently useless projects have a ton of GitHub stars. It doesn't cost anything to star a project, so all it takes is exposure via a popular blog or hacker news or something.


Ok.


It's not about personal productivity - it's about team productivity. Unless you're working on throwaway projects, the chance is that many people besides you will be working on them and all of these other concerns matter, regardless of what you personally feel about AngularJS. Things like can we hire someone who knows framework X are not phantom concerns - those are the exact things you worry about when you have a valuable code base.


High-level application design is a convention. Conventions are like languages and exist for social reasons. Frameworks like AngularJS are popular and useful precisely because they constrain design and impose conventions. Everyone speaking their own language is not very useful.

No. Mithril built in "templates" are basically just js arrays and the "m" function. They have a surface ugliness, especially when you are used to html. I use them anyway because I don't care about that. jsx is just optional syntactic sugar, making views look more like plain html. it's completely cosmetic, and your comparing it to the "non-standard stuff" in angular makes me think you are missing the kind of deep design problems i see in angular. but i don't want to have that conversation here, and it's been well over a years since i was using angular regularly. you should read the article i linked to be before if you're interested.




cmon, really? this is such a logic nitpick. i would expect that instead of trying to win an argument on a technicality, you could try to understand how what i wrote could be true. mithril is very easy to learn. yet the elegance of its overall design is one i hadn't fully appreciated before until seeing it explained in that context.


correct. this is the standard distinction between a framework and a library, mithril being more or less the latter. you are encouraged to write all your application model objects as POJOs. mithril just provides the glue to do efficient, automatic view updates. it's much harder to decouple from angular in this way. of course you can't re-use the mithril specific parts, but you will be able to re-use, and independently test outside of mithril, all the important parts of application's business logic.

so no, i disagree with this. well designed business objects built as POJOs should be the most long-lived of all.

this seems like a pov suited to a large enterprise organization. it's far less relevant for startups. also, you are making such a fuss about hiring new programmers and getting them up to speed on a codebase written in mithril or some other lesser known framework. yet one of its selling points is it's tiny learning curve. i could certainly take an expert angular developer and have him be productive within a day on a mithril project. so you're setting up a false dichotomy.

my *main point* is that weighing against all these pros you mention for a large ecosystem framework like angular is the productivity lost due to its needless complexity. i think we disagree on this point, and it's essential to my argument



a thousand times no. good design is constrained by universal principles that shape the way humans think and the types of mistakes they are likely to make. i've seen this famous dijkstra quote come up in discussions about react:

"My second remark is that our intellectual powers are rather geared to master static relations and that our powers to visualize processes evolving in time are relatively poorly developed. For that reason we should do (as wise programmers aware of our limitations) our utmost to shorten the conceptual gap between the static program and the dynamic process, to make the correspondence between the program (spread out in text space) and the process (spread out in time) as trivial as possible.

so you can't just decide on a convention that isn't in harmony with good design. it doesn't matter how many people adopt it, all of them will still be fighting against themselves, and whatever you gain from the small communication overhead will be outweighed by the productivity lost in this fight.

as i said above, i think you don't see angular as having the problems that i do, and my argument has no teeth without that assumption.

I agree with this and some of the other stuff mentioned on this page has the smell of Lisp about it (Mithril and ClojureScript especially).

I definitely don't understand how React or Mithril are supposed to have less framework lockin because "it's all just Javascript" or whatever. Suppose I write a front-end in React and halfway through I'm like "I hate this, I'm just going to switch to pure HTML and Javascript". I'm thinking that is not going to go well.

it sounds like you don't understand the difference between views and business logic. you'd have to rewrite your views, not your business logic. the latter should be 80-90% of your work. the jlongster article might give you a better idea about the distinction. but truly understanding it isn't easy. and you won't really see the benefit until you do. but if you think that lisp smells it's probably not for you anyway.

Business objects and logic in angular are going to be in POJOs. Angular services are where the business logic is supposed to be (and service instances are POJOs) and aside from dependency injection, which is generally a good idea anyway and easily replaced, there's nothing about business logic in AngularJS that needs to be tied to the framework at all. You don't even really have to use AngularJS services at all if you like - it's not like Angular components can't talk to the outside world. The criticism of AngularJS relative to Mithril and React have to do with how the view logic is constructed - the way AngularJS helps you organize business logic is entirely optional and something React and Mithril don't even attempt to address. Again, not having features isn't some kind of magical productivity boost. Learning AngularJS doesn't magically make you forget how to create objects in Javascript.


The economics don't change for startups, unless you're okay with your code base outliving the framework and having to rewrite the whole thing. I guess either that or your startup never surviving to the point where any of this matters is more likely, but in the even it all works out, the economics aren't really different because you're no longer a startup at that point.


But why would expert Angular developers sign up for this in the first place? Continuity within a tech stack is a valuable career proposition and while new hot technologies are good for one's career, obscure ones aren't.


I'm really not seeing this at all, aside from myself, our junior developer who had never done Javascript or any kind of web programming, HTML, CSS or anything picked up AngularJS and delivered a fairly complex product prototype completely in spare time. I've talked to a bunch of CTOs and architects and heard similar things happen elsewhere. I went to a hackathon and saw people who have never used AngularJS learn and become reasonably productive in hours. The ecosystem edge is such that you don't have to be as good at AngularJS as you have to be in some fringe framework to be more productive.


How does this contradict what I said? Also, your personal preferences aren't universal principles. If universal principles that shape the way humans think are reflected in a technology, wouldn't that technology become popular? The underlying argument you're making here is that people choose technologies completely independent of their quality, usefulness and intuitiveness.

Your argument is that AngularJS is unintuitive like Lisp, reduces productivity like C, performs slowly like Ruby and introduces unnecessarily difficult concepts like Haskell. Yet it isn't merely popular - it has virtually no peers in terms of popularity.

I mean I can sort of buy the argument that an unpopular language like Haskell or Clojure is great for long-term productivity despite being unpopular because the learning curve is steep, it doesn't match people's mental model of programming and forces you to see things in a different way, which means people don't see the benefits until much further down the road. But you're not making that argument - you're saying your little pet framework has exactly the qualities that tend to make a framework more popular than its actual long-term value proposition warrants. Likewise, you're saying AngularJS has exactly the qualities that make it less popular than its long-term value proposition warrants and it's a massive, absolute runaway success. And somehow you think this means AngularJS offers bad long-term value proposition, when everything in your argument screams the other way around.

****

The phone interview went pretty well, I think. The guy on the phone was really nice. The tech part was pretty basic questions about git and the Linux command line. Oddly, very little about SQL. Now wait to see if I make it to phase 4.

One of my friends decided to start programming. Got this text:
"Downloaded a text editor, Vim. I don't know if this works."

i'm sure it's possible to use angular in a way i'd be happy about, and i bet the experts do. maybe you are one. but angular, like rails, encourages putting business logic in its controllers, coupling it to the framework.

also, the difference between libraries and frameworks and not having to couple to a framework through forced base class extensions is the central point of the architecture section here: http://lhorie.github.io/mithril/comparison.html

in pete hunt's talks (and other talks and blog posts like the ones i linked to above), it's the high level architectural differences that are being touted as the true benefits of react. the specific performance benefits of the shadow dom and the way data binding is achieved is secondary. imo that difference is hardly important at all, but i'm sure it matters in some performance critical applications.

this just isn't true. but i don't want to have this particular argument.


again, just not true. even if it were, i'm not making suboptimal tech stack choices to appease candidates who are thinking about how their resume will look when they move on. i feel like you have lots of theoretical reasons that are so divorced from the things i care about and the way i approach these decisions that we just aren't going to agree and the conversation about these particular points isn't productive.


i believe this. but i don't think i'd like the code.



this is a philosophical can of worms, but i don't consider these things my personal preferences, although they are that as well. there's a deeper problem with this argument. things become popular for many reasons that have nothing to do with quality -- i think we do agree on that. and what seems intuitive to a beginner when creating does not necessarily correspond with how our natural mental models about the world work when viewing. there's two things: there's the simplicity of the technology itself (where things like lisp's ugly parentheses turn people off, and makes them think it's harder than "x = 10" or a for loop or whatever), and then the conceptual simplicity of the deeper design behind the technology. the former is a major confounding factor when evaluating the latter, an evaluation that usually requires experience to make.

it's like the old chestnut "if object-oriented programming is so natural, why does it take 10 years to master?" but this isn't a good argument. if good prose is writing that's natural and easy for people to read, why does it take so long to master the craft? what's natural and easy to consume is not necessarily natural to produce. it usually isn't. clean, well-designed code is a consumable product. it's makes perfect sense that it's difficult to produce. the code that you write as a beginner comes pretty naturally; it's easy. but that doesn't mean it's good or easy for others to read.


actually i sort of am, but i see it didn't come across that clearly. i think it's possible a beginner using mithril might make a mess of things. what it offers me is the ability to do design my application exactly how i want, and leverage all the work i've done learning about good design. for me, not just with angular but with most big frameworks (as opposed to libraries) i find i am constantly fighting the framework to decouple from it so i can simplify my application design. but separately from that, react/mithril all the up front overhead of learning about directives, services, transclusions, etc, etc.


i would never degrade lisp like that.

C doesn't impose high-level, bad architectural decisions

true, i guess, but angular's bad performance was never a practical issue when i used it so i don't care about that and don't think it's relevant for most cases.

haskell's concepts have a beautiful simplicity, and don't seem difficult to me. when they are difficult, there is payoff: that is, once you "get" them, they appear simple in retrospect. the type of difficulty in angular is not of this kind: it's beuracractic difficulty.

this to me is evidence of its inferiority, if anything. by this argument, we should all be building websites in wordpress, drupal and joomla. but i'm not basing my dislike of angular on this -- i really wanted to like angular, i tried hard to like it, and in theory it would be great if the most popular things were best, for many of the reasons you state. but they usually aren't.

Wow this reminds me of a quote I pasted.

candybar,

i looked up some videos i'd watched before, and this one:

http://facebook.github.io/flux/docs/overview.html

describes how the whole reason for being of react was to support facebook's flux architecture, essentially their simplified version of MVC that makes thinking about your application so much easier.

at the end someone asks pete hunt specifically about react vs angular, and here's what he says:

the question was comparing react + flux and angular. they do solve some of the same problems but they go at in very different ways. so react is focused a lot on treating your code as a black box. so there's no sort of observable abstraction inside of react. you simply say "hey, rerender the UI" and you present a consisten view of what you want your UI to look like. with angular you are basically passing data throughout these things called scopes, which observe your data model, and i think that's a very leaky abstraction. it forces you to compose your application not in terms of functions and objects but in terms of directives and model view controller and their flavor of model view controller. so while it does work for a certain class of applications, as you scale up you start to miss the past 40 or 50 years of research into how to abstract a program, and so, if you can push that data binding concern out to the edges of your system like react does, i think it leads to faster iteration time.

Allen C, yes we've learned about strings and lists, as well as dictionaries. We're just now working on classes. I generally have no problems understanding the concepts, but trying to implement them in writing the assigned programs is just straight buggery.

Cheers mate, appreciate it very much.

Yeah I'm gonna go ahead and say I don't know what you mean. I mean I understand what you mean by business logic but a huge amount of React code is going to be render methods. That all gets scrapped if you switch frameworks. It doesn't matter how abstracted you make it, what you're doing in the end with front-end frameworks is creating and manipulating HTML documents. If you stop doing that one way you have to do it another way. I think you're nuts if you think that creating and manipulating HTML documents, by whatever means you do it, is ever 10-20% of what you do.

I've never written in Lisp. I have no idea what it's like. I assume it's a fine language. When I said Lisp smell, I meant you and SkyHighStacksYo were talking about your preferred framework in the way Lisp cultists talk about Lisp. You know, that the dawn of functional programming is upon us, that they could reproduce my favourite language in 10 minutes flat in Lisp, shouting incoherently about Greenspun's tenth rule, that sort of thing. Then always mystified when it turns out people don't want infinitely flexible programming languages, but rather frameworks that make it easier to program collaboratively and that express things with clear semantics.

I know I'm coming over like a dick here, but I was SMH at this:

I mean code quality is important and I hate horrific code as much as the next guy who's ever had to fix the work of an outsourced team. I'd completely agree that bad code continues to be a much bigger issue than overengineered code. But programming to me in the end is a practical discipline that is supposed to help achieve actual stuff, not a competition to see whose abstractions are the least leaky. Angular might not be perfect, but given the uptake it's clearly good enough for most purposes. If your response to hitting something in Angular that you don't think is good practice is to fight the framework or start hacking the source, then you're not being efficient at your job.

Other professions don't seem to have this problem. When IKEA designers are asked to produce the company's next desk, they don't insist on producing the most elegant and well-engineered desk ever wrought by the hand of man. But when asked to produce a Hello World application, far too many programmers respond by breaking out 4-layer designs, DI containers, and full internationalization capability. The reason this annoys me is that when I have to convince management that stuff is hopelessly broken and needs rewriting, they regard me with suspicion because they remember that last nerd that came in and told them it was essential all the company's systems be rewritten in Scheme.

Off the top of my head I can't think of another profession that's comparable. Well-engineered software is often about making it easy to react to change, building on and modifying the existing software.

An Ikea desk gets designed to meet specific requirements, then built, and then sold. Software gets designed, built, released in continuous cycles where the requirements are always changing.


I'd regard you with suspicion too.

You serious ?

if this is true in your experience, you're probably not writing complex business applications. in which case angular, or any other js framework you pick, will be just fine. but in that case, angular is probably way more power than you need. a little bit of jquery is sufficient.

to be clear, designing and getting a pixel perfect UI right will be more than 10-20% of your time. but that's a different activity. we're talking about implementing a visual design in html. and ofc, CSS and cross-browser testing can eat up a lot of time, but again that's a separate issue and you'll have to deal with that no matter what framework you use.

I mean, can you give me an example of the sort of application you're talking about?

Like, you appear to work in a field where AngularJS is insufficient to meet your needs, but simultaneously you appear to work alone, since you don't appear to have any experience collaborating with anyone and just pick and choose frameworks at whim. Which would imply one-man-job apps, you'd think. What exactly is your job?

Not all of it does though. Some of it gets built, does a job, then gets destroyed. People aren't equipped to remember those projects, because things that occupy their time tend to be the projects that were poorly designed and require re-engineering. There's an illusion that all software should be built for extensibility.

Saving time by not doing things that are not required is just as real a time saving as not having to later fix poorly engineered software. I want to emphasise that I'm on your side here - code in general is poorly engineered and the vast majority of projects are under-designed. But in the upper echelon of programmers, there's the opposite phenomenon - guys who know how to engineer software beautifully but have no idea when they should curb their tendencies to over-engineer. Given the proliferation of software and its increasing complexity, that is an increasingly important skill imo.

Agile ftw. Seriuosly Agile addresses this issue. I was a bit skeptical when I started getting involved with Agile project work but it actually functions pretty well.

I'm the CTO of a startup with a small tech team. Some projects I work alone, some I collobarate with others on. I have the freedom to choose the tools I use. I also have side projects, although not a lot of time for those.

To be clear, angular is not "insufficient" to meet my needs. Anything I do could be done in angular. It would be fine. But given the choice, I'd rather use react or mithril. If you want to use angular, more to power to you. In your original post, you expressed frustration with the learning curve. I was giving you my opinion that your frustration was justified and offering you alternatives. If the alternatives seem even more frustrating to you, or you don't see what benefits they might have, you should ignore my advice and power through with angular. The benefit I personally get depends on my own understanding of how to do design. Your background is different, so you may not get the same benefits. Another example of the curse of knowledge, I guess.

Anyway I think this argument has run its course. I can't add much more than I already have.

To clarify, I love lisp, or really Scheme specifically, but zero Lisp dialect became popular, while languages that have lispy semantics, but not the lispy syntax became massively popular. Ruby seemed both inspired by CLOS and its cousin Dylan and Javascript was certainly inspired by Scheme. Isn't it fairly clear that people find Lisp syntax unintuitive?

for sure. but to me this shows how beginners are distracted easily by the purely cosmetic. which is an important fact. at the same time, anyone willing to look back past the thickets of parentheses can learn scheme and its basic concepts in 20-30 minutes. there's a reason it was used as a teaching language and a reason SICP is still considered a classic.

so a surface complexity masks an essential simplicity. in many popular languages, the reverse is true.