15 ms·

Making decent UI's went from bicycle science to rocket science. VB-classic was easy to learn and easy to use, and you had coordinate control over where most thi

by tabtab 7y ago

Making decent UI's went from bicycle science to rocket science. VB-classic was easy to learn and easy to use, and you had coordinate control over where most things went on the screen. If your layout engine didn't put it where you had planned, you can just tell the widget to "go right here". You felt in charge of the screen, not some abstract layout layer with an attitude. A manager (person) could draw something on the back of a napkin and you could make it exactly match the napkin because you were in charge of exactly where things went. (Layout engines were optional then.) The newer UI frameworks are round-about and confusing. They make it easy to get 80% of what you want, but that last 20% is bear, requiring long trial-and-error periods, unless you are heavily versed in them. Abstraction is only nice when it does what you want, not when it becomes "abstract art". The price for "responsive" (client-side auto-placement) has been huge. In applications that are primarily for office desktops, their advantage is lost. Mouse and PC's is still where most real work is done. Instead we are using things like Bootstrap, designed for social networks, not real work. Glamour won over logic. It's great job security for UI experts, but expensive for organizations because they need stack specialists whereby before a one-man-band (or 2) could make useful apps for less than half the cost and time without having to spend years with UI-Yoda to master some screwy layout engine. Something is wrong.

jcmontx 7y ago
The dogmatic React crowd is going to jump on your neck
- DevKoala 7y ago
  I am not a fan of React, but there is nothing about it that exacerbated the problems OP is talking out. The web’s layout engine is just a PITA. I also feel much more in control inside a canvas. I can do anything I want inside it. However, DOM manipulation is not a solution to layout issues, so I am not sure the OP’s gripe is that relevant to this tutorial.
- aidos 7y ago
  None of this has anything to do with react.
- warent 7y ago
  Can you please not do this here? Your post is obviously intended to be inflammatory and adds no value to the discussion.
deleted 7y ago
[deleted]
jackewiehose 7y ago
These fixed-size GUIs have already been shit in the 90s (remember the windows-dialog where you disable hiding of file-extensions? I think it's still there as of today and still annoying as always). Now I have a big high-res monitor but can't read bad written applications like Steam because they don't honor my DPI settings. No, we need flexible layouts. We always did.
- amelius 7y ago
  Let's be clear: we don't need flexible layouts, but it's nice when we have them.
peterhunt 7y ago
VB classic didn't have a layout engine, so you had to do everything yourself. Making the window resizable required a huge amount of error-prone code that you had to change every time you updated the UI, and it often didn't work well. A classic VB6 bug was to resize the window larger, and then shrink it back down to the same size, and the layout would not be consistent despite the window returning back to the same size it once was. The browser today lets you opt out automatic layout and instead specify fixed x/y/width/height coords with `position: fixed`. It seems to me that your problem isn't the technology itself but perhaps the culture around it?
- rkagerer 7y ago
  I never found it error-prone. Perhaps meticulous. You had one event where you simply go through all your "dynamic" controls and set their position and size. I did it for all my applications, both simple and sophisticated. Worked like a charm. The built in tooling got more flexible in .Net (eg. You could effectively "bind edges"), but I actually found setting all that up more time consuming in practice that just arranging everything myself in straightforward code (which also gave me more control over exceptions and edge cases).
  - peterhunt 7y ago
    It became really error prone when elements had intrinsic size. A great example is when you have to lay out elements based on how text wraps. Designs back then didn't need this as often, but most designs today do need to take it into account (especially if internationalization is a requirement). To do this correctly you need to do two passes for layout and at that point you've basically implemented a rudimentary layout engine. I think we overestimate the complexity of apps we built back then and don't have an appreciation of how complex our apps are today.
    - jfkebwjsbx 7y ago
      If your layout depends on text wrapping, text length and i18n, then your design is wrong, your UX will be bad and your users will hate you for trying to be too clever. Not to mention the amount of finicky bugs you will encounter.
dmix 7y ago
I'm confused, are you saying using React/Vue is not practical for a small 1-2 person shop? As compared to what? If frontend was bicycle science then I must have missed that in my 10+yrs writing frontends with JS+CSS... > They make it easy to get 80% of what you want, but that last 20% is bear JQuery was the standard before JS frameworks took off and it was a nightmare for anything besides smallish websites. It was good for 25-50% of what you wanted at most - everything else was completely different every project you looked at. Trying to manage a large application that any serious modern web-based SaaS company uses was incredibly difficult. I started using Backbone.js before Ember/Angular was even a thing yet and it was the first serious attempt at building large JS-driven apps for browser and mobile. That was simpler because it mimicked Railsy REST/MVC set ups, plenty of analogies for backend people to learn from, but that turned out to be a poor way to create UIs and React/Vue/etc + Redux offered a thinner view layer with a very clean way to manage state and bind data to the UI. JS frameworks stopped pretending they were traditional web server app/database in the browser. But rather one that reflected the reactive interactions which we are trying to model in real-life spread across various individual components... more like desktop interfaces, not recreating web apps backends in the frontend. Vanilla javascript has improved quite a bit to lessen the need for JQuery, but even then managing state and mutations reliably, modelling data, coordinating async operations, only loading the JS you need on a particular page, code organization/modules, etc have all been made way easier with the new Webpack-driven frameworks. But you can still use simple vanilla/JQuery if you only have a small project. There's still plenty of Jquery libraries being developed and simpler UI libraries like Bootstrap... Unless you mean pure-HTML forms, which are extremely limited in terms of interactivity. But again they haven't gone away either if it fits your needs.
- godot 7y ago
  The GP was saying VB-classic, implying that he's talking about windows desktop apps. I think that's what he's saying about layout engine stuff; layout engine is only a thing on web apps. Everything you're talking about is re: web apps, just older style web apps with JS+CSS in the past 10 years. For old school windows desktop apps you don't have to worry about client rendering, client's browser size, responsive (mobile vs desktop), etc. I believe GP is making an argument that most of these business-use web apps could've been windows desktop apps where the frontend takes half the time and team to build.
reaperducer 7y ago
I currently maintain nine web sites, internal and customer-facing. For the last two years I've been migrating them off of the framework-go-round into plain old PHP→HTML + CSS + minimal JS where there is no other option. Because I'm in healthcare, the web sites have gone crazy in the last four months, and there are updates upon additions upon updates of the additional content over and over and over. Think 14-hour days. The sites that have been migrated out of the framework jungle can be updated in minutes to hours. The sites that are still stuck in framework hell can take hours to days. When things happen (for example, when another state locks down), the framework sites get slow. The non-framework sites keep zipping along, which was my main reason for moving them in the first place. The next time you're looking at a government or healthcare web site that doesn't have the latest COVID-19 information on it, look at the source code and try to figure out what it's been generated with.
- debaserab2 7y ago
  So you profiled the sites enough to understand that the actual bottleneck for these sites was the framework CPU/memory overhead? I don't know what the requirements of these sites are, but throwing out all the things you get with a framework such as a battle-hardened authentication system for "plain old PHP" hardly seems like a pragmatic decision. Was a full rewrite in a base language only really an easier/superior decision then finding more simply caching solutions (which many frameworks support out of the box)?
  - benbenolson 7y ago
    These are the kinds of what-if questions that scare people into using the most popular framework-- well, what if security isn't as good? What if it's not properly cached? What if the rewrite is hard? What a load of bologna.
    - debaserab2 7y ago
      No, it's not a load of bologna. Rolling your own auth system is very likely not going to produce an auth system as battle hardened/tested as <popular framework>. Rewriting an entire site from scratch is rarely the correct choice and is one of the most common engineering fallacy. https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect Caching is a problem you need to solve regardless of whether you're using a framework or not. These problems don't magically go away when you decide to rewrite these components yourself. You probably aren't going to write code as well as a community of coders that have contributed to a years-old codebase. Especially not on your first pass. These are all pretty legitimate "what-if" questions to ask.
edko 7y ago
There is nothing wrong. Before, you only had to care about your app running on a VGA monitor. Now, you have the possibility to make it run on devices of all sizes, resolutions and shapes.
- tabtab 7y ago
  Not really. Most productivity software still runs on desktops. We sacrifice too much to the Resize Gods without actually using them. It's like costly shrubbery insurance. (YAGNI.) Desktop GUI's were both easier to specify and were more productive to use. The "responsive" designs waste screen real-estate and require more steps to do the same thing, on average. The labor math usually says "no". There may be a subset of features that phone users need, but one can make a separate sub-app for those rather than poison the whole thing with mobile-oriented drawbacks.
ng12 7y ago
> It's great job security for UI experts, but expensive for organizations because they need stack specialists whereby before a one-man-band (or 2) could make useful apps for less than half the cost and time without having to spend years with UI-Yoda to master some screwy layout engine. My company has a very, very small number of UI experts who are tasked with making sure non-UI folks can build front-ends. It's been a rousing success. We own some documentation and a few tools to make starting projects easy. We teach an hour long workshop that covers everything (React, the npm ecosystem, TypeScript, best practices, etc) and then we let them have at it. It's been a rousing success and nobody has seriously suggested moving back to jQuery or any of the WISYWIG tools. Sure there is a cost -- you need to hire at least one person with enough knowledge to cut through the bullshit and build the right tech stack. But once you've paid that cost once the payoff is massive.
- ranit 7y ago
  >> very small number of UI experts who are tasked with making sure non-UI folks can build front-ends This looks an excellent approach. >> you need to hire at least one person with enough knowledge to cut through the bullshit and build the right tech stack. How do you ensure that this person will "build the right tech stack"? There are myriad of possibilities to go astray.
  - ng12 7y ago
    Sure, but that's a problem for everything. You'll struggle to build a modern cloud architecture without at least a few people with extensive experience with the cloud. You can get pretty good mileage following industry best practice -- pick React, pick TypeScript, and pick the most popular tools for each.
- nsomaru 7y ago
  How does this work? Has your company shared or consulted any resources regarding this?
  - ng12 7y ago
    Some but mostly we relied on my expertise and a few others who've been thinking hard about these problems for a long time. We've been thinking about sharing some of our insights but haven't yet.
gbuk2013 7y ago
Every developer should definitely build a few dynamic applications using only DOM APIs. After doing it several times, they will start building their own framework. At that point they should consider using an existing framework. :)
- lizardmancan 7y ago
  then when familiar with a few they should go back to static html
parhamn 7y ago
> Making decent UI's went from bicycle science to rocket science. But UIs are better than ever. How many Google Docs, Webflows, SquareSpaces, existed in VB-classic? Let's give the space some credit. All this complexity wasn't for nothing.
qwertox 7y ago
Minutes ago I was reading this Stack Overflow question: https://stackoverflow.com/questions/60997602/event-handler-gets-called-before-handler-is-set https://stackoverflow.com/questions/60997602/event-handler-g... I was reading through the code, and was astonished at how this doesn't look like code anymore but a mashup of different languages and patterns in one single block of code. The only framework I'm willing to tolerate at this point is Vue.js, which, with the help of http-vue-loader, is capable of nicely using components in a compiler-free workflow. React may be excellent for teams, where there's a clear distinction between font- and backend development, but sometimes you just need to hack together a server with a minimalistic frontend which should just be editable via sftp, when you're building tools for internal use only. Vue.js is great for that, but I'm worrying that it will turn into the same thing Angular has turned into.
icedchai 7y ago
We're using a document delivery system for application UI. That's what's wrong. This could've been fixed in the 90's, but it's too late now.
protonimitate 7y ago
This argument is typical hackernews upvote bait. You can't honestly compare VB UI's to modern day web UI with a straight face. Following your analogy, making decent UIs is closer to rocket science because web apps are closer to rockets than bicycles these days. I would love to see a drag-n-drop approach to web UI building that is responsive and fast. But I highly suspect the reason this doesn't exist isn't "great job security". There's really nothing complex or difficult enough in React, Vue, or any other UI framework that can't be picked up by a competent dev quickly. >Something is wrong Yeah, the hivemind that loves to hate anything JS/front-end related and things "purity" is the only bar by which to measure things.
- deleted 7y ago
  [deleted]
- lizardmancan 7y ago
  I started the "hating" when pc promised everything would work on every computer. this just seemed impossible bordering idiotic. before this every screen had the same resolution. UI was horrifically easy! The c64 had characters in the font set that allowed drawing boxes. You can imagine but it was 10 times easier. The problem with many layers of abstraction is that it borders the imposible if the layer abstacted to poorly suports something. Take physical screen size and simple scaling to fit? Is it a tiny 1024px laptop or a giant tv? there is no solution I can think of
- noahtallen 7y ago
  I agree with a lot of your points here. For example, I’d love to have a nice constraint system like you can have making an iOS. or even windows app. The problem is we have to work with HTML and the DOM, which aren’t nearly as nice to use out of the box as OS APIs. HTML/CSS/JS wasn’t designed for applications, it was built for basic document manipulation. But the pure accessibility and compatibility of the web is a better trade off for most products because it’s easier for people to find and use something on the web than downloading an app. So we’re forced to use worse tools. I also don’t get the JS hate here. :) you certainly should not use react for your static resume site or blog. But react is a brilliant and necessary tool for web applications. If you don’t use it, you’ll end up making your own, probably worse abstraction for managing state and reactive updates.
D_Guidi 7y ago
> Something is wrong. Even worse. We're stuck with html/js also for "desktop" apps, via the electon and similar. Basically, UI development is dead (Windows WPF is in maintenance mode) and if you want, as example, build some graphs you need to manipulate js in a webpage. A
- unlinked_dll 7y ago
  I'd offer a different take. Users want to run your software on their system. You don't want to write software for their system, you want to write it for all systems. The output impedance of the developer and input impedance of the users is a function of how easy it is to write the app for all users and use it by any individual user. Optimal power delivery is achieved when I/O impedances are matches low. Efficiency is achieved at lower impedances. JS/HTML/CSS is currently the optimal solution in that context. UI isn't dead, it's more alive than ever. But since what works is what can get my product to the most people the fastest is on a web stack, that's the thing that's going to be used. And since the web stack is high impedance to begin with, anything I can do to lower that in terms of framework is going to be in demand, hence all the diversity we see.
jandrese 7y ago
For CSS I have long suspected that this is intentional. The point was to let clients do what works best for them, and the page designers weren't supposed to be lining things up perfectly in nice squares. Unfortunately the real world and the perfect world the CSS designers envisioned were two totally different things and as a result people have been fighting with CSS layout for years.
chrismarlow9 7y ago
Nothing is wrong. Things got more complex and segmented and specialized in. That's just how an industry grows. I mean look at how many jobs, companies, and careers were created just around the invention of the "smart phone". In 1999 none of those really existed. Sure you could play the snake game on your phone, but I think the app store is a little more complex. Anyway, software pushes hardware to its limits, and then hardware pushes software to its limits, and the cycle goes around and around. With the invention of the smart phone, you got to see hardware push software to its limits, creating all these extra layers of coding that most of us old schoolers arent fond of. And now (in my opinion), the AI and Cryptocurrency GPU/ASIC movements are pushing hardware limits. So I'd expect to see lots of innovation in that arena and also lots of greybeards claiming "We dont need all these fancy different processors, back in my day we used a CPU farm and it worked just fine and why do we need all this". On the other hand I know what you mean because I cut my teeth on coding VB6 and Delphi (Borland anyone?) applications in middle school (where are my Yahoo!, ICQ, AIM app masters at?). It was fun, and easier than todays craziness. And people wrote more client software instead of making everything a web service. We also had zone alarm and people got hacked left and right and windows BSOD and all the fun of the 90's and repeated unknown socket errors on winsocks. I also felt like the programming world had more curiosity and self-sufficient people, as opposed to being so heavily money, convert, social, latest tech driven. It feels like everything now is a rinse, repeat, sell to FAANG cycle.
- axismundi 7y ago
  That. I remember Borland C++ Builder. It was a pleasure to build compelling user interfaces with it, but it's best value was simplicity, the meticulously crafted library and great help system. That's how I got into programming. The big difference today are devices, especially screen sizes. We want to make apps now. Small, focused tools. Sadly often we have simple apps bloated beyond recognition for profit. That's partly why every gizmo in an app is not only pixels, no sir, it has to jump and blink and shout for attention. More layout engines won't make your app better. Keeping it simple and focused will.
harrygeez 7y ago
HN likes to downplay frameworks like React, Vue, etc., but people who work on modern web apps everyday know how insanely difficult/unmaintainable it is to write the same thing in plain JavaScript. And before you start saying "but I can build a simple HTML site and sprinkle with some JavaScript", the market has spoken – general web users like high fidelity web apps. Whether you like inaccessible websites when you disable JavaScript is one thing, but don't dismiss useful tools that don't suit to your tastes. If you don't need to build a web app nobody's forcing you to.
- lhorie 7y ago
  GP is not talking about JS frameworks, though. They're talking about layout constraint systems (the argument goes that CSS is harder to reason about because "width" might not mean physical width, since it could affected by margin, etc). The counter-argument, of course, is that there are many more types of devices now (e.g. using "desktop" experiences in an ipad, multiple screen resolutions, etc just to give a few counter-arguments to the notion that desktop is "simple") As for frameworks: the market has indeed spoken, but not in the way you think. Consumers of websites rarely pay for the majority of websites they use. Employers, however, pay developers and the buzzword-chasing in resume building/interviewing cycles is real.
- grey-area 7y ago
  HN likes to downplay frameworks like React, Vue, etc., but people who work on modern web apps everyday Whenever I read the word 'modern' in this context now, I know the writer means javascript, and in particular one of the 'modern' javascript frameworks. I'm not sure quite how or when it acquired that meaning, but it seems to be used that way on HN frequently. I wonder how this word came to mean built with Javascript to some people? Do you genuinely see modern as synonymous with built in React, Vue, etc. or would you allow other approaches into the modern canon? The similarities with the burn the old world then rebuild it anew attitude of early 20c Modernism are striking, so I suppose it fits, but it should not be used in the place of built with javascript, as the implication is nothing else is truly Modern. Also what does high fidelity mean in the context of websites? Is this like high fidelity vinyl records with a warm sound? Do your frameworks have gold cables? I think you'll find people here casting doubt on the requirement for web frameworks because there are many other ways of building websites (server side for example, the way this website you're using right now is built), there is no one 'modern' way. People build contemporary websites with a variety of tools, Javascript is not objectively better than other solutions IMO (in many ways it is obviously worse), and client side is not obviously better than server side, it's a pattern which has seen its popularity wax and wane and will do so again.
sireat 7y ago
What's wrong is we are trying to fit a round peg(general desktop apps) into a square hole(flowable document delivery model as envisioned originally by Berners-Lee). It is easier to make UIs with Winforms, Qt, WPF, heck even with Actionscript it was more managable than with DOM. The problem is that there is no unifying standard, no single vision. There are competing frameworks but they leak abstractions all over. For example I am making UIs with ipywidgets which is basically JS on the front end and it at least a couple of abstractions too deep to fully understand it. To emphasize how stupid making UIs using web is, let's take something simple like dropdown. There is no such thing in the web standards, we use ul, ol etc and then we fake it/add another abstraction with a library or framework In an ideal world dropdown would be a web component that could be imported, then be styled and events would be bound.
- trog 7y ago
  Uh, isn't a plain old HTML <select> dropdown as standard as you can get?

by tabtab 7y ago

jcmontx 7y ago

The dogmatic React crowd is going to jump on your neck

DevKoala 7y ago
I am not a fan of React, but there is nothing about it that exacerbated the problems OP is talking out. The web’s layout engine is just a PITA. I also feel much more in control inside a canvas. I can do anything I want inside it. However, DOM manipulation is not a solution to layout issues, so I am not sure the OP’s gripe is that relevant to this tutorial.
aidos 7y ago
None of this has anything to do with react.
warent 7y ago
Can you please not do this here? Your post is obviously intended to be inflammatory and adds no value to the discussion.

deleted 7y ago

[deleted]

jackewiehose 7y ago

These fixed-size GUIs have already been shit in the 90s (remember the windows-dialog where you disable hiding of file-extensions? I think it's still there as of today and still annoying as always). Now I have a big high-res monitor but can't read bad written applications like Steam because they don't honor my DPI settings. No, we need flexible layouts. We always did.

amelius 7y ago
Let's be clear: we don't need flexible layouts, but it's nice when we have them.

peterhunt 7y ago

VB classic didn't have a layout engine, so you had to do everything yourself. Making the window resizable required a huge amount of error-prone code that you had to change every time you updated the UI, and it often didn't work well. A classic VB6 bug was to resize the window larger, and then shrink it back down to the same size, and the layout would not be consistent despite the window returning back to the same size it once was. The browser today lets you opt out automatic layout and instead specify fixed x/y/width/height coords with `position: fixed`. It seems to me that your problem isn't the technology itself but perhaps the culture around it?

rkagerer 7y ago
I never found it error-prone. Perhaps meticulous. You had one event where you simply go through all your "dynamic" controls and set their position and size. I did it for all my applications, both simple and sophisticated. Worked like a charm. The built in tooling got more flexible in .Net (eg. You could effectively "bind edges"), but I actually found setting all that up more time consuming in practice that just arranging everything myself in straightforward code (which also gave me more control over exceptions and edge cases).
- peterhunt 7y ago
  It became really error prone when elements had intrinsic size. A great example is when you have to lay out elements based on how text wraps. Designs back then didn't need this as often, but most designs today do need to take it into account (especially if internationalization is a requirement). To do this correctly you need to do two passes for layout and at that point you've basically implemented a rudimentary layout engine. I think we overestimate the complexity of apps we built back then and don't have an appreciation of how complex our apps are today.
  - jfkebwjsbx 7y ago
    If your layout depends on text wrapping, text length and i18n, then your design is wrong, your UX will be bad and your users will hate you for trying to be too clever. Not to mention the amount of finicky bugs you will encounter.

dmix 7y ago

I'm confused, are you saying using React/Vue is not practical for a small 1-2 person shop? As compared to what? If frontend was bicycle science then I must have missed that in my 10+yrs writing frontends with JS+CSS... > They make it easy to get 80% of what you want, but that last 20% is bear JQuery was the standard before JS frameworks took off and it was a nightmare for anything besides smallish websites. It was good for 25-50% of what you wanted at most - everything else was completely different every project you looked at. Trying to manage a large application that any serious modern web-based SaaS company uses was incredibly difficult. I started using Backbone.js before Ember/Angular was even a thing yet and it was the first serious attempt at building large JS-driven apps for browser and mobile. That was simpler because it mimicked Railsy REST/MVC set ups, plenty of analogies for backend people to learn from, but that turned out to be a poor way to create UIs and React/Vue/etc + Redux offered a thinner view layer with a very clean way to manage state and bind data to the UI. JS frameworks stopped pretending they were traditional web server app/database in the browser. But rather one that reflected the reactive interactions which we are trying to model in real-life spread across various individual components... more like desktop interfaces, not recreating web apps backends in the frontend. Vanilla javascript has improved quite a bit to lessen the need for JQuery, but even then managing state and mutations reliably, modelling data, coordinating async operations, only loading the JS you need on a particular page, code organization/modules, etc have all been made way easier with the new Webpack-driven frameworks. But you can still use simple vanilla/JQuery if you only have a small project. There's still plenty of Jquery libraries being developed and simpler UI libraries like Bootstrap... Unless you mean pure-HTML forms, which are extremely limited in terms of interactivity. But again they haven't gone away either if it fits your needs.

godot 7y ago
The GP was saying VB-classic, implying that he's talking about windows desktop apps. I think that's what he's saying about layout engine stuff; layout engine is only a thing on web apps. Everything you're talking about is re: web apps, just older style web apps with JS+CSS in the past 10 years. For old school windows desktop apps you don't have to worry about client rendering, client's browser size, responsive (mobile vs desktop), etc. I believe GP is making an argument that most of these business-use web apps could've been windows desktop apps where the frontend takes half the time and team to build.

reaperducer 7y ago

I currently maintain nine web sites, internal and customer-facing. For the last two years I've been migrating them off of the framework-go-round into plain old PHP→HTML + CSS + minimal JS where there is no other option. Because I'm in healthcare, the web sites have gone crazy in the last four months, and there are updates upon additions upon updates of the additional content over and over and over. Think 14-hour days. The sites that have been migrated out of the framework jungle can be updated in minutes to hours. The sites that are still stuck in framework hell can take hours to days. When things happen (for example, when another state locks down), the framework sites get slow. The non-framework sites keep zipping along, which was my main reason for moving them in the first place. The next time you're looking at a government or healthcare web site that doesn't have the latest COVID-19 information on it, look at the source code and try to figure out what it's been generated with.

debaserab2 7y ago
So you profiled the sites enough to understand that the actual bottleneck for these sites was the framework CPU/memory overhead? I don't know what the requirements of these sites are, but throwing out all the things you get with a framework such as a battle-hardened authentication system for "plain old PHP" hardly seems like a pragmatic decision. Was a full rewrite in a base language only really an easier/superior decision then finding more simply caching solutions (which many frameworks support out of the box)?
- benbenolson 7y ago
  These are the kinds of what-if questions that scare people into using the most popular framework-- well, what if security isn't as good? What if it's not properly cached? What if the rewrite is hard? What a load of bologna.
  - debaserab2 7y ago
    No, it's not a load of bologna. Rolling your own auth system is very likely not going to produce an auth system as battle hardened/tested as <popular framework>. Rewriting an entire site from scratch is rarely the correct choice and is one of the most common engineering fallacy. https://en.wikipedia.org/wiki/Second-system_effect https://en.wikipedia.org/wiki/Second-system_effect Caching is a problem you need to solve regardless of whether you're using a framework or not. These problems don't magically go away when you decide to rewrite these components yourself. You probably aren't going to write code as well as a community of coders that have contributed to a years-old codebase. Especially not on your first pass. These are all pretty legitimate "what-if" questions to ask.

edko 7y ago

There is nothing wrong. Before, you only had to care about your app running on a VGA monitor. Now, you have the possibility to make it run on devices of all sizes, resolutions and shapes.

tabtab 7y ago
Not really. Most productivity software still runs on desktops. We sacrifice too much to the Resize Gods without actually using them. It's like costly shrubbery insurance. (YAGNI.) Desktop GUI's were both easier to specify and were more productive to use. The "responsive" designs waste screen real-estate and require more steps to do the same thing, on average. The labor math usually says "no". There may be a subset of features that phone users need, but one can make a separate sub-app for those rather than poison the whole thing with mobile-oriented drawbacks.

ng12 7y ago

> It's great job security for UI experts, but expensive for organizations because they need stack specialists whereby before a one-man-band (or 2) could make useful apps for less than half the cost and time without having to spend years with UI-Yoda to master some screwy layout engine. My company has a very, very small number of UI experts who are tasked with making sure non-UI folks can build front-ends. It's been a rousing success. We own some documentation and a few tools to make starting projects easy. We teach an hour long workshop that covers everything (React, the npm ecosystem, TypeScript, best practices, etc) and then we let them have at it. It's been a rousing success and nobody has seriously suggested moving back to jQuery or any of the WISYWIG tools. Sure there is a cost -- you need to hire at least one person with enough knowledge to cut through the bullshit and build the right tech stack. But once you've paid that cost once the payoff is massive.

ranit 7y ago
>> very small number of UI experts who are tasked with making sure non-UI folks can build front-ends This looks an excellent approach. >> you need to hire at least one person with enough knowledge to cut through the bullshit and build the right tech stack. How do you ensure that this person will "build the right tech stack"? There are myriad of possibilities to go astray.
- ng12 7y ago
  Sure, but that's a problem for everything. You'll struggle to build a modern cloud architecture without at least a few people with extensive experience with the cloud. You can get pretty good mileage following industry best practice -- pick React, pick TypeScript, and pick the most popular tools for each.
nsomaru 7y ago
How does this work? Has your company shared or consulted any resources regarding this?
- ng12 7y ago
  Some but mostly we relied on my expertise and a few others who've been thinking hard about these problems for a long time. We've been thinking about sharing some of our insights but haven't yet.

gbuk2013 7y ago

Every developer should definitely build a few dynamic applications using only DOM APIs. After doing it several times, they will start building their own framework. At that point they should consider using an existing framework. :)

lizardmancan 7y ago
then when familiar with a few they should go back to static html

parhamn 7y ago

> Making decent UI's went from bicycle science to rocket science. But UIs are better than ever. How many Google Docs, Webflows, SquareSpaces, existed in VB-classic? Let's give the space some credit. All this complexity wasn't for nothing.

qwertox 7y ago

Minutes ago I was reading this Stack Overflow question: https://stackoverflow.com/questions/60997602/event-handler-gets-called-before-handler-is-set https://stackoverflow.com/questions/60997602/event-handler-g... I was reading through the code, and was astonished at how this doesn't look like code anymore but a mashup of different languages and patterns in one single block of code. The only framework I'm willing to tolerate at this point is Vue.js, which, with the help of http-vue-loader, is capable of nicely using components in a compiler-free workflow. React may be excellent for teams, where there's a clear distinction between font- and backend development, but sometimes you just need to hack together a server with a minimalistic frontend which should just be editable via sftp, when you're building tools for internal use only. Vue.js is great for that, but I'm worrying that it will turn into the same thing Angular has turned into.

icedchai 7y ago

We're using a document delivery system for application UI. That's what's wrong. This could've been fixed in the 90's, but it's too late now.

protonimitate 7y ago

This argument is typical hackernews upvote bait. You can't honestly compare VB UI's to modern day web UI with a straight face. Following your analogy, making decent UIs is closer to rocket science because web apps are closer to rockets than bicycles these days. I would love to see a drag-n-drop approach to web UI building that is responsive and fast. But I highly suspect the reason this doesn't exist isn't "great job security". There's really nothing complex or difficult enough in React, Vue, or any other UI framework that can't be picked up by a competent dev quickly. >Something is wrong Yeah, the hivemind that loves to hate anything JS/front-end related and things "purity" is the only bar by which to measure things.

deleted 7y ago
[deleted]
lizardmancan 7y ago
I started the "hating" when pc promised everything would work on every computer. this just seemed impossible bordering idiotic. before this every screen had the same resolution. UI was horrifically easy! The c64 had characters in the font set that allowed drawing boxes. You can imagine but it was 10 times easier. The problem with many layers of abstraction is that it borders the imposible if the layer abstacted to poorly suports something. Take physical screen size and simple scaling to fit? Is it a tiny 1024px laptop or a giant tv? there is no solution I can think of
noahtallen 7y ago
I agree with a lot of your points here. For example, I’d love to have a nice constraint system like you can have making an iOS. or even windows app. The problem is we have to work with HTML and the DOM, which aren’t nearly as nice to use out of the box as OS APIs. HTML/CSS/JS wasn’t designed for applications, it was built for basic document manipulation. But the pure accessibility and compatibility of the web is a better trade off for most products because it’s easier for people to find and use something on the web than downloading an app. So we’re forced to use worse tools. I also don’t get the JS hate here. :) you certainly should not use react for your static resume site or blog. But react is a brilliant and necessary tool for web applications. If you don’t use it, you’ll end up making your own, probably worse abstraction for managing state and reactive updates.

D_Guidi 7y ago

> Something is wrong. Even worse. We're stuck with html/js also for "desktop" apps, via the electon and similar. Basically, UI development is dead (Windows WPF is in maintenance mode) and if you want, as example, build some graphs you need to manipulate js in a webpage. A

unlinked_dll 7y ago
I'd offer a different take. Users want to run your software on their system. You don't want to write software for their system, you want to write it for all systems. The output impedance of the developer and input impedance of the users is a function of how easy it is to write the app for all users and use it by any individual user. Optimal power delivery is achieved when I/O impedances are matches low. Efficiency is achieved at lower impedances. JS/HTML/CSS is currently the optimal solution in that context. UI isn't dead, it's more alive than ever. But since what works is what can get my product to the most people the fastest is on a web stack, that's the thing that's going to be used. And since the web stack is high impedance to begin with, anything I can do to lower that in terms of framework is going to be in demand, hence all the diversity we see.

jandrese 7y ago

For CSS I have long suspected that this is intentional. The point was to let clients do what works best for them, and the page designers weren't supposed to be lining things up perfectly in nice squares. Unfortunately the real world and the perfect world the CSS designers envisioned were two totally different things and as a result people have been fighting with CSS layout for years.

chrismarlow9 7y ago

Nothing is wrong. Things got more complex and segmented and specialized in. That's just how an industry grows. I mean look at how many jobs, companies, and careers were created just around the invention of the "smart phone". In 1999 none of those really existed. Sure you could play the snake game on your phone, but I think the app store is a little more complex. Anyway, software pushes hardware to its limits, and then hardware pushes software to its limits, and the cycle goes around and around. With the invention of the smart phone, you got to see hardware push software to its limits, creating all these extra layers of coding that most of us old schoolers arent fond of. And now (in my opinion), the AI and Cryptocurrency GPU/ASIC movements are pushing hardware limits. So I'd expect to see lots of innovation in that arena and also lots of greybeards claiming "We dont need all these fancy different processors, back in my day we used a CPU farm and it worked just fine and why do we need all this". On the other hand I know what you mean because I cut my teeth on coding VB6 and Delphi (Borland anyone?) applications in middle school (where are my Yahoo!, ICQ, AIM app masters at?). It was fun, and easier than todays craziness. And people wrote more client software instead of making everything a web service. We also had zone alarm and people got hacked left and right and windows BSOD and all the fun of the 90's and repeated unknown socket errors on winsocks. I also felt like the programming world had more curiosity and self-sufficient people, as opposed to being so heavily money, convert, social, latest tech driven. It feels like everything now is a rinse, repeat, sell to FAANG cycle.

axismundi 7y ago
That. I remember Borland C++ Builder. It was a pleasure to build compelling user interfaces with it, but it's best value was simplicity, the meticulously crafted library and great help system. That's how I got into programming. The big difference today are devices, especially screen sizes. We want to make apps now. Small, focused tools. Sadly often we have simple apps bloated beyond recognition for profit. That's partly why every gizmo in an app is not only pixels, no sir, it has to jump and blink and shout for attention. More layout engines won't make your app better. Keeping it simple and focused will.

harrygeez 7y ago

HN likes to downplay frameworks like React, Vue, etc., but people who work on modern web apps everyday know how insanely difficult/unmaintainable it is to write the same thing in plain JavaScript. And before you start saying "but I can build a simple HTML site and sprinkle with some JavaScript", the market has spoken – general web users like high fidelity web apps. Whether you like inaccessible websites when you disable JavaScript is one thing, but don't dismiss useful tools that don't suit to your tastes. If you don't need to build a web app nobody's forcing you to.

lhorie 7y ago
GP is not talking about JS frameworks, though. They're talking about layout constraint systems (the argument goes that CSS is harder to reason about because "width" might not mean physical width, since it could affected by margin, etc). The counter-argument, of course, is that there are many more types of devices now (e.g. using "desktop" experiences in an ipad, multiple screen resolutions, etc just to give a few counter-arguments to the notion that desktop is "simple") As for frameworks: the market has indeed spoken, but not in the way you think. Consumers of websites rarely pay for the majority of websites they use. Employers, however, pay developers and the buzzword-chasing in resume building/interviewing cycles is real.
grey-area 7y ago
HN likes to downplay frameworks like React, Vue, etc., but people who work on modern web apps everyday Whenever I read the word 'modern' in this context now, I know the writer means javascript, and in particular one of the 'modern' javascript frameworks. I'm not sure quite how or when it acquired that meaning, but it seems to be used that way on HN frequently. I wonder how this word came to mean built with Javascript to some people? Do you genuinely see modern as synonymous with built in React, Vue, etc. or would you allow other approaches into the modern canon? The similarities with the burn the old world then rebuild it anew attitude of early 20c Modernism are striking, so I suppose it fits, but it should not be used in the place of built with javascript, as the implication is nothing else is truly Modern. Also what does high fidelity mean in the context of websites? Is this like high fidelity vinyl records with a warm sound? Do your frameworks have gold cables? I think you'll find people here casting doubt on the requirement for web frameworks because there are many other ways of building websites (server side for example, the way this website you're using right now is built), there is no one 'modern' way. People build contemporary websites with a variety of tools, Javascript is not objectively better than other solutions IMO (in many ways it is obviously worse), and client side is not obviously better than server side, it's a pattern which has seen its popularity wax and wane and will do so again.

sireat 7y ago

What's wrong is we are trying to fit a round peg(general desktop apps) into a square hole(flowable document delivery model as envisioned originally by Berners-Lee). It is easier to make UIs with Winforms, Qt, WPF, heck even with Actionscript it was more managable than with DOM. The problem is that there is no unifying standard, no single vision. There are competing frameworks but they leak abstractions all over. For example I am making UIs with ipywidgets which is basically JS on the front end and it at least a couple of abstractions too deep to fully understand it. To emphasize how stupid making UIs using web is, let's take something simple like dropdown. There is no such thing in the web standards, we use ul, ol etc and then we fake it/add another abstraction with a library or framework In an ideal world dropdown would be a web component that could be imported, then be styled and events would be bound.

trog 7y ago
Uh, isn't a plain old HTML <select> dropdown as standard as you can get?