10 ms·

I still remember doing a PoC for an end-to-end secure messaging app with web support, around 3 years back. It was written in plain JS with jquery and one or two

• lazaroclapp 10y ago
  Also, your TCB now includes Angular, a bunch of fairly unstable libraries and the servers that provide all the NPM package managing infrastructure. I mean, your TCB already included the OS, the OS update manager and the browser, but still...
• mwfunk 10y ago
  I didn't downvote you (and I thought it was a thoughtful post), but I could totally see somebody interpreting "web-boy" as some sort of weird emasculating epithet a la "fanboi". On the Internet it's super easy to take offense at things that weren't intended to offend, in fact some people seem to thrive on it.
  • mrlatinos 10y ago
    I think he's referring to all of hipsters who don't really understand what they're using but they're using it because it's hip. Might offend some, but people shouldn't be so quick to hop on a bandwagon and go wrecking working code.
    • cname 10y ago
      And then there are the "retro hipsters" who stick with "vanilla JS" and jQuery (not a framework?), smugly denigrating the new wave of modern "hipsters". Repeat ad nauseum.
      • exodust 10y ago
        Might they be denigrating the new wave hipsters on the basis that so many new wave websites are bloated whales on the inside, with pretentious 'mobile-first' machine-pressed skins on the outside? Or perhaps I've just helped you rest your case!
    • ewjordan 10y ago
      It was prototype code, OP said that it was unmaintainable, and complained about, among other things, the "web-boys" adding unit tests - I'm not a 100% coverage zealot or anything, but adding some tests is not exactly hipster shit, it's a perfectly justifiable step when taking a prototype messaging app into production, especially if you have time in the schedule. This does not sound to me like they hopped on a bandwagon and wrecked working code, it sounds like they were trying to bring some fast and dirty code that they didn't like the structure of closer to a style that they were familiar with, which is reasonable. Of course we don't know any real details, maybe the web boys really were a bunch of copypasta idiots that messed it all up - I've seen this scenario play out both ways, and the one thing that's for sure is that prototype engineers are always skeptical of work that other people do on their babies, whether they do it well or not.
• zxcvcxz 10y ago
  >they buried a relatively simple and elegant messaging system in tons and tons of incoherent, unmaintained, inextensible and incompatible (with websockets at the time) stuff. If all it was was a chat app then angular was over kill. Leveraging frameworks on projects for which they're unnecessary doesn't show that the frameworks are bad, just that the devs are bad. The reality was probably that those "web-boys" have to maintain dozens of applications and so follow a certain workflow for all of those applications. Many frameworks allow for easy and streamlined testing, are more reliable across browsers, allow for easy extensibility, and help you easily track data. In the real world, people can't be expected to maintain dozens of custom tool chains and there aren't a ton of job postings for people who don't know ANY web frameworks/libraries.
  • edejong 10y ago
    Your comments reflect my feelings at the time. Trying to push a round peg into a square hole. Angular had (and still has) some really useful features and so do many other frameworks/libraries. However, it's the combinatorial complexity of having a dozen of them at the same time, each with their own DSL, coding conventions, community (or lack of it), that makes it overkill. By the way, as the nature of these messaging apps is mostly in async messaging, it proved quite hard to unit-test.
    • deadowl 10y ago
      I imagine designing thorough unit tests for 2000 lines of code could take a few weeks, and continue to have sparse edge cases crop up over the course of years. They're nice to have for mature software components. If you're prototyping, they're a waste of time.
• gjolund 10y ago
  Honestly, it just sounds like you are bad at managing your own software projects and trying to blame it on the web team. If your code had been as easy to understand as you say it is there would have been no need to re-write it. Also, your acknowledgement that it was difficult to maintain makes my point for me.
  • edejong 10y ago
    It wasn't written to be easily maintainable, as it was a PoC. So no comments, relatively short naming. However, it had good SoC and simple logic to update views. Minimal, but understandable. I wanted it to be rewritten before I wrote the first line of code. My trust went to someone who does full-time web development (I'm alround, full-stack).
    • gjolund 10y ago
      What is the argument here? You wrote a POC of unmaintainable code, and then some junior web devs butchered your project because it was undocumented and "understandable" to you only. Get off your high horse. If I was your boss I would be asking why you didn't speak up earlier, and why you didn't document your work better.
      • edejong 10y ago
        The (beta) protocol was pretty well documented at the time and it took relatively little time to implement the iOS client. 2000 lines of code is relatively easy to understand, even without someone explaining what's going on. The project wasn't a failure at all. Currently being used in a production setting for communication in and between hospitals and medical labs.
      • sgift 10y ago
        > You wrote a POC of unmaintainable code Going from "not written to be easily maintainable" to "unmaintainable" is exactly the problem you see very often. Instead of investing a bit of time to learn things and make them incrementally better people cry foul when it's not perfectly to their liking (i.e. if they haven't written it themself) and tell you later when you ask them if that monstrosity they've written was really necessary - which probably doesn't work and/or has bugs which had been already fixed in the original codebase - that it was "unmaintanable" and so they "had" to rewrite it.
• jlg23 10y ago
  I can relate to your experience but you, just as me, seem not to be a typical front-end developer - the "web-boys" (a term which probably got you the down-votes) on the other hand are. If one asks them why they do things the way they do them, they usually have a coherent answer and are happy to explain it. As someone else pointed out in this thread, a great advantage of established frameworks is that they provide a coding standard for a team. People who do this stuff every day can easily follow the standard, understand the flow and be very productive. They did invest lots of time to learn about all those tools and libraries and probably had an overall productivity gain compared to writing native JS. If you don't really enjoy front-end development, and your comment reads like you don't, get on your high horse and join me for a ride while the "web-boys" make our hacked UIs usable for end-users and maintainable for the next "web-boys" who have to hack on it. When we get back we'll probably be very grateful for a great UI(X). ;)
  • exodust 10y ago
    > "They did invest lots of time to learn about all those tools and libraries" Unfortunately that claim doesn't hold up to what I suspect is happening most of the time. At least in my experience at work I've seen tech leads or someone similar introduce frameworks without so much as "apparently it's quite good, so let's use it". One case in particular, Angular was chosen and turned out not to be suitable - it ran very slowly with the tasks it was chosen to do in the browser on a particularly busy web page. Learning the limitations of Angular would have gone a long way to avoiding the poor result. Not enough learning, too much embracing shiny new things.
    • jlg23 10y ago
      > introduce frameworks without so much as "apparently it's quite good, so let's use it" And if they all want to use it - let them use it. The productivity gained by agreeing on a framework usually outweighs the performance loss over the "best" solution. Yes, my native JS implementation of a gallery app is much faster than the React version (reviewed by an experienced React-dev and judged "good") but if that project goes public and other people have to work on it I'll be damned if I make them learn my way of doing things. I'd expect these devs to implement a feature quickly and that means they use the framework they are most comfortable with. If it is good enough, it is good enough. Aiming for perfection killed way too many projects, accepting that the productive path is not always the nicest or cleanest (according to some arbitrary metric) is what makes projects succeed. e.g.: Writing perl code is definitely not the best thing to do, performance wise (when counting clock cycles), but it does (did) allow some folks to be incredibly successful. See this awesome essay of this very site's founder: http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
• dwg 10y ago
  Why was it rewritten, because it was difficult to maintain? It sounds like whomsoever rewrote it failed to make it more maintainable, then I would say that is a failure on the part of the person than on the concept of a framework.
  • ak39 10y ago
    Aren't frameworks supposed to prevent this type of thing exactly? If there's no guarantee, how do we ensure that we don't create an even bigger nightmare code structure when using frameworks? This risk has to be understood before framework choices are made.
    • dwg 10y ago
      > Aren't frameworks supposed to prevent this type of thing exactly? I'm generalizing, but frameworks reduce program complexity when applied in a thoughtful way to a suitable problem space. If you adopt a framework that isn't suitable to your particular problem, or adopt one that is suitable but fail to learn to use it properly, you will probably increase complexity. When I said that it was a failure on the part of the person, I meant that there is a possibility that the people responsible for rewriting probably did a bad job at choosing a framework for their problem (perhaps it was too big and complicated?), or maybe they chose a suitable framework but didn't do a good job of implementing it (perhaps they tried to code in their old style?). > If there's no guarantee, how do we ensure that we don't create an even bigger nightmare code structure when using frameworks? This risk has to be understood before framework choices are made. This is obvious and I don't believe I made any argument to the contrary. Just like choosing any tool, one must understand it first to make good use of it.
• userbinator 10y ago
  There's a very suitable verb for describing this process: "enterprisify" This trend toward "frameworkfulness" probably started with OOP and Java in the mid 90s, and spread from there. Fortunately they seem to be realising the ridiculousness and gradually getting out of that mindset, but unfortunately other developer cultures like JS are now headed in that direction.
  • cname 10y ago
    Using a JS framework like jQuery or Angular or React isn't even remotely similar to Enterprise Java Beans and all that nonsense. You must be joking.
    • jonathankoren 10y ago
      Oh that's only because there's a new framework every 6 months.
    • ak39 10y ago
      What's the difference between platforms, frameworks and libraries? Here's my attempt ... jQuery: library. (Others: D3, knockout). Salient feature: does not impose code structure or organization of code modules. Angular and React: frameworks. Salient feature: expects adherence to module separation and code structure protocol. Like other MVC frameworks. EJB: platform. Salient feature: provides entire terra firma and attendant oxygen for the entire solution. Frameworks and libraries are used on platforms.
      • veidelis 10y ago
        I find this answer helpful - http://stackoverflow.com/questions/148747/what-is-the-difference-between-a-framework-and-a-library#answer-15600924 http://stackoverflow.com/questions/148747/what-is-the-differ...
        • ak39 10y ago
          Thanks. It's true that the word framework is buzzwordy. If you look at the general interpretation or the most common usage of that term, you'll see that it does refer to some type of "boundary setting" type of thinking. To work within the confines of a frame. So, IMO frameworks necessarily impose parameters within which to maneavure.
• cname 10y ago
  I can't think of anything that's particularly constructive to say, but I find your comment... irritating. It's likely that you are simply wrong. It sounds like you are personally upset that your creation was modified by other developers who may have more experience. If you haven't had the experience of maintaining multiple projects with some kind of consistency between them, then adding "complexity" (unit tests? really?) may seem unnecessary. I've had similar discussions/arguments with (junior) developers (or non-developers) and it's just a waste of time. If you don't have the long view, the whole discussion is moot. Now, if those other developers created an unmaintainable monster, that's orthogonal; you can do that with any framework or no framework. You will always end up either A) creating a one-off framework anyway or B) creating a nightmare of inconsistency. Edit: Also, I think it's somewhat amusing that you include jQuery right alongside vanilla JS without irony while denigrating more-modern frameworks.
  • exodust 10y ago
    > "I can't think of anything that's particularly constructive to say..." I stopped reading after that, just sayin.
    • lojack 10y ago
      It's unfortunate, because the rest of his comment was relatively constructive.
• yandrypozo 10y ago
  Thanks a lot for your comment, after all I'm not crazy at all, I wish find more people like you
• philliphaydon 10y ago
  Hmmm I still use a framework. Riot.js because it's all I need. No jQuery, no other frameworks. Just riot.js. I feel like all I write is small little web components. I could do it without riot but this just makes things more consistent for me. For example I wanted the ability to report content on a page. So I created report.tag, 40 lines of html, 30 lines of Javascript. Done. Then a button which mounts the component when needed. I like this way than using giant frameworks like react and angular.
  • renke1 10y ago
    I wouldn't exactly call React giant framework. It's API is pretty small actually.
• untog 10y ago
  > The web-boys however, didn't understand asynchronous messaging, cryptography and eventual consistency very well Would it be fair to say you didn't understand the web frameworks very well? I'm not sure that lines of code is a great measure here. What about test coverage? Maintainability? NPM is a package manager - anyone would advocate using that over manual dependency management, no matter what environment you're programming in. It sounds like you had an expansion of the web team. It only makes sense that you'd standardise things when that happens. It just happens they weren't standards you are familiar with. There's a perception among "server boys" (or are you "server men" looking over the "web boys"?) that the web doesn't deserve 15,000 lines of code. It's a lot more complex than you give it credit for - or would you be happy to write all your backend code in C and C only?
  • rimantas 10y ago
    Lines of code can be a very good measure. You can have an app that is small and easy to fit into the mental model. Or you can wrap it up in huges framework and get lost between the abstractions. We have a saying to shoot sparrows from the cannon, and often using web frameworks looks like doing exactly this: you take trivial case and make it complex just because it is implied that frameworks are necessarey. Doing that you also kill accessibility (remember it? was a thing several years back), load times, etc.
    • untog 10y ago
      > Doing that you also kill accessibility ?! What web frameworks kill accessibility, exactly?
  • Silhouette 10y ago
    NPM is a package manager - anyone would advocate using that over manual dependency management, no matter what environment you're programming in. This is precisely the kind of generalisation that many experienced developers will rightly object to. There is absolutely nothing unreasonable about manually downloading a specific version of a small number of self-contained libraries, and just using them either directly or integrated into some sort of bundling process. This has significant advantages in terms of simplicity, reliability, and transparency compared to the who-knows-what that NPM and its ecosystem will generate only to achieve the same end result. You only really need to use NPM if you're working with lots of small packages and/or packages that have many small dependencies of their own, but either way, now you have two problems.
• seanwilson 10y ago
  > Took around 2000 lines all in all....The line-count went up, of course, easily to 15000 lines. Inexperienced programmers can make bad decisions in any setting so I don't think this has anything to do with frameworks. I would be heavily against any decision that bloats a codebase 7 times its original size unless the pros heavily outweighed the cons. People tend to associate poor coding mostly with spaghetti code and copy/paste everywhere, but poor coding also includes adding useless tests and abstracting too much.
  • Buttons840 10y ago
    I agree. We can make subjective arguments over this or that framework all day. But objectively speaking 15,000 lines is likely to be more difficult to maintain than 2,000.
• quickpost 10y ago
  That sounds very painful.
• ruffrey 10y ago
  I've worked with node/npm/frontendy land for 5 years solid now. At first I used a lot of libraries. I guess with experience, it became clear that relying on as few as possible is much better. Frankly, build systems like grunt and gulp are not necessary for node or frontend development. You can write the same or much less code, with much less domain knowledge, and accomplish the same thing using npm scripts and plain JS files.