6 ms·

>If frontend was bicycle science then I must have missed that in my 10+yrs writing frontends with JS+CSS. What you've said directly proves OPs point - you've m

by arc619 7y ago

>If frontend was bicycle science then I must have missed that in my 10+yrs writing frontends with JS+CSS. What you've said directly proves OPs point - you've missed the central message: UIs used to be bicycle science before everyone started using JS to make them. They mentioned VB as in visual basic. GUIs with VB/Delphi are a case of dragging controls to where you want, pixel perfect every time on every desktop. Web technologies are not designed for desktops but for building on top of HTML, so everything is an abstraction to get back to something that used to be possible with zero experience and sometimes even zero programming. For example, a simple notepad clone can be made in Delphi without a single line of code. Now you need to 'full stack' to even know what's going on under all the layers just to place a control at an x,y and even then it can't be guaranteed because of all the different browsers, css edge cases, and other caveats.

dmix 7y ago
> For example, a simple notepad clone can be made in Delphi without a single line of code. Sure then I agree, making simple toy apps with VBasic and similar tools was easier. It was also easier to make websites in Dreamweaver back in the day than really learning HTML+CSS. That doesn't really solve any serious problems, nor the reasons why we've adopted such extensive frameworks. What I disagree with is that it's getting harder or messier or worse to build frontends. I've seen significant improvements in the last few years and I've told many people that I'm actually liking making JS-driven apps for the first time in my career (Typescript has played a big role in this as well, not just React/Vue). I'm no longer scared of deploying large-scale browser apps since it became clean component/redux driven stuff instead of a tangle of JQuery + other crap shoot combinations. I'm sure the pace of change to outsiders can make it seem like a long series of failures and flailing about, but to those who have been following it there has been a relatively consistent evolution of ideas. One that more recently has gotten us the closest to desktop quality software than ever before - even though 'desktop widgets' was a dirty word in the frontend world for a long time - IMO largely because early attempts were too bold and complicated for the capability of the browsers at the time.
- core-questions 7y ago
  > That doesn't really solve any serious problems Yes it does. It meant that less-experienced developers could make nice programs that near-zero-experience users could immediately take advantage of, with the same look and feel as every other program they already used. It went far past "simple toy apps"; maybe not suitable for making a distributed network app, but for making something useful for an accountant or an administrative professional, it was perfect. > I'm sure the pace of change to outsiders can make it seem like a long series of failures and flailing about, but to those who have been following it there has been a relatively consistent evolution of ideas. I've been following this since the 90s and it went from "a nice way to publish documents to everyone" to "a bastard environment with a shitty language that is inconsistently implemented" to "overburdened with frameworks to paper over the fact that this system was never designed for this at all". Great, 20 years later we have some huge massive framework that takes ages to learn even for someone who used to know JS competently, just to draw some basic widgets and data tables that we used to be able to drag-and-drop into place in the 90s. > What I disagree with is that it's getting harder or messier or worse to build frontends. Maybe it's slowly improving in the browser now, but until we have things on the level of Flash as far as interactive design for non-developers goes, it's still massive steps backwards for no real gain besides the self-gratification of JS devs.
  - tabtab 7y ago
    Re: [That doesn't really solve any serious problems] "Yes it does. It meant that less-experienced developers could make nice programs that near-zero-experience users could immediately take advantage of, with the same look and feel as every other program they already used." Let me clarify. I am or used to be what's now called a "full stack developer". I am not really an intense "coding wizard", but can do ALL parts of the development cycle reasonably well, including talking to the customer to understand what they need and why they need it. Those good with code details tend not to be so good at the analyst and communication side of things. There are exceptions, but I'd say this is about 85% true. These tools made full-stack-developers possible and relatively cheap. This also means each department (group within an org) can have its own programmer/analyst who can focus on and learn the domain, now it has to be more centralized in order to have specialists. Tools like VB-classic, Delphi, PowerBuilder etc. meant I didn't have to micromanage a lot of UI details that either take a lot of time or require hiring UI coding specialists now. I could do both the analyst/people side and the technical side at a good clip. Current web stacks mostly killed all that, requiring either layer specialists or spending a lot of trial-and-error time fiddling with browser UI's trying to get the friggen UI to match the sketch. Before if the customer asked, "can you move that button to the right just half an inch", it was 5 minute job. Now such can take 2 days if it goes against the grain of the UI framework. It's ridiculous. Sure, an expert at the UI framework may instantly know the magic CSS trick, but it's only obvious to a UI framework expert, NOT to generalists like me. It now often requires rocket science or a manual genetic algorithm (mass trial & error) to move that damned button half an inch on the customer's screen.

by arc619 7y ago

dmix 7y ago

> For example, a simple notepad clone can be made in Delphi without a single line of code. Sure then I agree, making simple toy apps with VBasic and similar tools was easier. It was also easier to make websites in Dreamweaver back in the day than really learning HTML+CSS. That doesn't really solve any serious problems, nor the reasons why we've adopted such extensive frameworks. What I disagree with is that it's getting harder or messier or worse to build frontends. I've seen significant improvements in the last few years and I've told many people that I'm actually liking making JS-driven apps for the first time in my career (Typescript has played a big role in this as well, not just React/Vue). I'm no longer scared of deploying large-scale browser apps since it became clean component/redux driven stuff instead of a tangle of JQuery + other crap shoot combinations. I'm sure the pace of change to outsiders can make it seem like a long series of failures and flailing about, but to those who have been following it there has been a relatively consistent evolution of ideas. One that more recently has gotten us the closest to desktop quality software than ever before - even though 'desktop widgets' was a dirty word in the frontend world for a long time - IMO largely because early attempts were too bold and complicated for the capability of the browsers at the time.

core-questions 7y ago
> That doesn't really solve any serious problems Yes it does. It meant that less-experienced developers could make nice programs that near-zero-experience users could immediately take advantage of, with the same look and feel as every other program they already used. It went far past "simple toy apps"; maybe not suitable for making a distributed network app, but for making something useful for an accountant or an administrative professional, it was perfect. > I'm sure the pace of change to outsiders can make it seem like a long series of failures and flailing about, but to those who have been following it there has been a relatively consistent evolution of ideas. I've been following this since the 90s and it went from "a nice way to publish documents to everyone" to "a bastard environment with a shitty language that is inconsistently implemented" to "overburdened with frameworks to paper over the fact that this system was never designed for this at all". Great, 20 years later we have some huge massive framework that takes ages to learn even for someone who used to know JS competently, just to draw some basic widgets and data tables that we used to be able to drag-and-drop into place in the 90s. > What I disagree with is that it's getting harder or messier or worse to build frontends. Maybe it's slowly improving in the browser now, but until we have things on the level of Flash as far as interactive design for non-developers goes, it's still massive steps backwards for no real gain besides the self-gratification of JS devs.
- tabtab 7y ago
  Re: [That doesn't really solve any serious problems] "Yes it does. It meant that less-experienced developers could make nice programs that near-zero-experience users could immediately take advantage of, with the same look and feel as every other program they already used." Let me clarify. I am or used to be what's now called a "full stack developer". I am not really an intense "coding wizard", but can do ALL parts of the development cycle reasonably well, including talking to the customer to understand what they need and why they need it. Those good with code details tend not to be so good at the analyst and communication side of things. There are exceptions, but I'd say this is about 85% true. These tools made full-stack-developers possible and relatively cheap. This also means each department (group within an org) can have its own programmer/analyst who can focus on and learn the domain, now it has to be more centralized in order to have specialists. Tools like VB-classic, Delphi, PowerBuilder etc. meant I didn't have to micromanage a lot of UI details that either take a lot of time or require hiring UI coding specialists now. I could do both the analyst/people side and the technical side at a good clip. Current web stacks mostly killed all that, requiring either layer specialists or spending a lot of trial-and-error time fiddling with browser UI's trying to get the friggen UI to match the sketch. Before if the customer asked, "can you move that button to the right just half an inch", it was 5 minute job. Now such can take 2 days if it goes against the grain of the UI framework. It's ridiculous. Sure, an expert at the UI framework may instantly know the magic CSS trick, but it's only obvious to a UI framework expert, NOT to generalists like me. It now often requires rocket science or a manual genetic algorithm (mass trial & error) to move that damned button half an inch on the customer's screen.