7 ms·

At our company, we have banned React, Angular and other "overengineered" JS frameworks. Our HTML is rendered from a standard boring Groovy server page, with so

• noway421 9y ago
  Thank you. This is true, the frameworks are not only trying to speed up the performance, but first and foremost abstract from the DOM. And for quite a while they've been failing on delivering that performance. Things get better with react server side rendering and the like, but they still need tons of javascript loaded alongside the nicely rendered html which still makes it quite laggy. Recent example of it is gitly.io. It is a beatiful web service which is I believe written in go. I just looked it up and it merely uses 200 lines of vanilla js. When I'm logged in and actually browsing the file tree.
• titobrown 9y ago
  Replies like this are always interesting to me. It seems like you're saying these "overengineered" JS frameworks are useless, but I can't believe thats the case. You must just be saying they don't fit your use case, correct? If so you are not getting that point across very clearly. Otherwise are you honestly saying you can't see the use case for these frameworks? You would rebuild Facebook with static HTML and a sprinkling of js? You believe all these very smart people who created, worked on, and use Angular, React, Vue, etc. are just way off base and should go back to your method?
  • olavgg 9y ago
    There is a story called The Emperor's New Clothes, the morale of that story is that you should question your decisions and not blindly believe what other people say, even if you look up to them. When I saw the "light" about React, me and friend were coding our own e-commerce system each for fun. Him with Ruby and Rails and jQuery, me with Grails and React. When we implemented the shopping cart, I wrote like 200 lines of code in React that would dynamically update that shopping cart. My friend did it with just 5 lines with jQuery. Yeah most of my React code was boiler plate, but still... What I do, is not at Facebook scale, complexity or size. I have no idea about how challenging their issues are technically. What I do know as a user of Facebook though, is that Facebook is annoyingly slow these days, and makes my Macbook pro fan spin at full power.
    • RodericDay 9y ago
      > What I do know as a user of Facebook though, is that Facebook is annoyingly slow these days, and makes my Macbook pro fan spin at full power. i can't echo this sentiment strongly enough
    • vladgur 9y ago
      You are comparing apple to oranges. Why use react or angular or vue with fun hobbyist projects meant for a team of one developer that is going to throw that code out and move on to another hobby. In the real world you're going to have to come up with a homegrown vanilla approach for all the things that a good framework does for you: escaping user input, provide setup and cleanup hooks for your DOM manipulations, maintain state and I'm not even touching routing because you seem to be focused on server-rendered apps although the community does prefer hybrid apps that start out server-rendered and load more data while the user is browsing. I've worked in companies that started out homegrown and it's a bitch to maintain, evolve and for that matter teach to new hires. Consistency matters on teams
• wavefunction 9y ago
  Angular/Angular4 is a joy to develop with, so that's too bad you're limiting yourselves artificially. We have groovy in my stack at work and everyone despises it. Fortunately that's a legacy we're moving away from.
  • bollockitis 9y ago
    Out of curiosity, what does everyone despise about Groovy?
    • virmundi 9y ago
      It's not the new hotness anymore. Scala came along. The author of Groovey says Scalia is better. It's also semidynamic. So if you don't like that, you won't like that (tautology of the day). Updated for Scalia to Scala.
      • bobwaycott 9y ago
        Do you mean Scala? I got a good a chuckle imagining the late Justice Scalia here. :)
      • vorg 9y ago
        > The author of Groovey says Scalia is better. You mean James Strachan? That was 8 years ago. In November last year he said "I still love groovy (jenkins pipelines are so groovy!), java, go, typescript and kotlin. I don't use Scala anymore." [1] Sounds like he uses Kotlin instead of Scala, and only uses Apache Groovy in Jenkins pipelines. And given that the Groovy collections methods are disabled so they don't actually work in Jenkins, I imagine he uses Java 8 or Kotlin for that purpose. [1] https://twitter.com/jstrachan/status/784333918078169088 https://twitter.com/jstrachan/status/784333918078169088
  • thaiphanvevo 9y ago
    I have never heard anybody say that Angular 2+ is a joy to work with before. What about it do you like?
  • 9y ago
• amnah 9y ago
  Just curious, how do you handle the vanilla-JS stuff? 1) inline with your view files 2) write them in separate js files and include them depending on the page 3) concat them into one big js file which gets included on every page 4) something else?
  • olavgg 9y ago
    Yes, we do a lot of inlining at the end of a view. In every case when the javascript is only usable for that view we find this very clean, every developer can immediately see what javascript is running on that particular view. We have our own small library for the more common operations, for small things like more effecient navigating of the DOM three or more complex "components" that for example convert a select element to a nicer selectbox with built in full text search. That library is included for every view. This library weight around 50kb gzipped.
    • noway421 9y ago
      Some companies go for that 'disciplined javascript' style. It's a nice paradigm to follow, but every time you'd want to make it slightly more advanced (as the app grows) you'd have to implement tooling on your own.
• BjoernKW 9y ago
  Might I ask what kind of applications you're developing? While I generally like the idea of doing web applications the old-fashioned way depending on the requirements manipulating the DOM using vanilla JavaScript can quickly get out of hand.
  • olavgg 9y ago
    We are creating a data management framework for AI-trainers, which are people creating data and analyzing data for our chatbot.
  • deleted 9y ago
    [deleted]
• rpedela 9y ago
  React is for complex/dynamic UIs. By using canvas, you kind of admitted that the old-school way isn't good enough for that case. Having said that, if canvas works and is better than React for your case, then great! Use whatever works.
  • olavgg 9y ago
    Its more like that we needed to display A LOT of data, that you also needs to interact with, much more than you can fit in a screen. So we present this with a simple way to navigate this data by using simple pan and zoom operations! Our clients love this!
    • shouldbworking 9y ago
      I had a client request we put an entire 10k+ searchable and sortable product table on a single page (with thumbnails for every product). After much reservation and trying to convince them otherwise, we just did it. After a few seconds of the browser creaking the page renders fine and runs great. This is a page with over 10000 images on it. I highly doubt your canvas approach is needed.
• jasim 9y ago
  If your web-app has even a modicum of complexity on the client side, the vanilla DOM based solution is going to get unwieldy real fast. Consider a simple list of elements to which you can add or delete items. With vanilla DOM, you’ll have to write handlers that will `$.find` the particular element, and then run a `$.remove` to remove it. To insert something, you’ll have to do a manual `$.appendHTML`. And when you have to send the data over to the server, you have to iterate over the elements, collect it into an array and send it across. But if you used something that had an explicit notion of the application state, and allowed you to express your view as a simple function of your state, all you would have to write is an `array.push` and another `_.remove(array)`. The view will update automatically because we’ve already told the 'over-engineered' framework what to render for any given state. But you could avoid framework and still not fall prey to spaghetti DOM manipulation. All you need is to keep an explicit state variable and have a single `render` function to deal with the DOM. This method will be invoked everytime you change your state, and it'll recreates the necessary DOM from scratch. It is a simple straight-forward implementation, but now you're going to lose cursor position, and with large enough DOM trees, the lag will be noticeable. To fix this, you can add a virtual-dom implementation that'll maintain the DOM tree in memory and avoid re-rendering things that haven't changed.. and then you can have some sort of immutability checker to skip even the virtual-dom rendering part. And by now you have a home-brewed over-engineered React-like framework, but without any of its documentation or robustness or community. We definitely need to be conservative in our choice of tools, but React today is a conservative choice to build rich front-end web applications. More than a framework, it is an approach to user interfaces, and it is a damn good one too.
  • DenisM 9y ago
    To be fair diffing virtual dom is not the only way - you could also be diffing the model and only update the parts which need it. Knowing the model well allows you write an efficient diff. The problem of course is that dom diff is universal while model diff is specific to application.
    • lukaszkups 9y ago
      or operate on document fragments
• jhedwards 9y ago
  But how do you handle the encapsulation of views? If I am working on a React app and I want to add a new interface, say a simple view that displays a record and has some controls on the left side, I might write something like this: <Panel> <Left> <ControlPanel record={record} /> </Left> <Right> <RecordView record={record} /> </Right> </Panel> This view would be injected into the frame of the app that already has a navbar and footer, the layout would be pre-built via my panel components Left and Right, and if I want to change the control-panel I can go to that file and make any changes I want so long as the API stays the same. Similarly, if the schema changes and we need to update the way we display records, I would go to the RecordView component and change it because it is a decoupled module. I just don't see how you can accomplish this with vanilla HTML and JS.
• xmatos 9y ago
  I've said it before here, but the best web app I've built was basically Django, with bare minimum js to handle in-page effects. I've been working on a project which is being ported to React for no reason, just because it's shiny, and it's been worst than expected. Bundling the entire website into a huge js file doesn't make any sense. In practice, every time you make the slightest change, like adding a div, or changing a class name, your users have to re-download the entire thing. Webpack takes 1GB of memory and 90 seconds to build it. Firefox Dev Tools eats all my ram if I try to reload the page with it open. And Redux is just bad. So much boilerplate for a dynamic language, with constants and if clauses to decide which action to dispatch. Apparently, it's ok to have presentation logic in a component, but god forbid internal state! I do believe the reason front-end devs praise it so much is because it allows them to work solely in js, despite the end product being slow and heavy. I always compare reddit's mobile site, written in react, with Hacker News. The first takes around 7 seconds to load on my cel phone, while the latter loads instantly. No one but frontend devs care about js. The web hasn't become js centric and I bet it never will. It has become mobile first and all you need for 90% of that is css. I don't know why fb and google spend money building these frameworks, but maybe because of this: https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ https://www.joelonsoftware.com/2002/01/06/fire-and-motion/ "But the end result is just cover fire. The competition has no choice but to spend all their time porting and keeping up, time that they can’t spend writing new features. Look closely at the software landscape. The companies that do well are the ones who rely least on big companies and don’t have to spend all their cycles catching up and reimplementing and fixing bugs that crop up only on Windows XP. The companies who stumble are the ones who spend too much time reading tea leaves to figure out the future direction of Microsoft. People get worried about .NET and decide to rewrite their whole architecture for .NET because they think they have to. Microsoft is shooting at you, and it’s just cover fire so that they can move forward and you can’t..." Replace Microsoft with Google or Facebook...
  • ng12 9y ago
    If you can build your application without a framework, do it. It's the right call every time. Not every web project calls for React, but for the ones that do it's a god-send. The alternative to me is not a minimal Django app -- it's nigh-unmaintainable jQuery spaghetti.