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.
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)?
Yes. That's part of my job.
I don't know what the requirements of these sites are
Then anything else is just blather. I know more about my systems than you do.
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)?
Yes. For my purposes. Perhaps not for the sites you work with.
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
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.
Still though, auth is just one arbitrary requirement I plucked from many that popular frameworks solve such as request handling, response rendering, database operations, routing, etc.
Yes, you can use a hodgepodge of libraries to solve these requirements but your argument that your codebase will be leaner than a "heavy framework" using codebase gets a bit flimsier in my experience.
Look, I'm not saying you shouldn't use a framework, every project has different needs. I'm saying that frameworks have made people lazy and they try to fit their project into the framework they know when when it's wrong.
What do you think the components in a framework are? They're just libraries, and often can be/are used standalone. I've seen no evidence that there are less bugs in a library not used for frameworks than one used for it.
> If I use the big framework, I'm stuck with it if I ever have to change my data storage method and it's outside of the frameworks normal scope.
There's no reason you can't use a different library within the framework. It's the exact same as writing from scratch, you're just doing it within the patterns of the framework instead of the patterns you've created on your own.
> Look, I'm not saying you shouldn't use a framework, every project has different needs. I'm saying that frameworks have made people lazy and they try to fit their project into the framework they know when when it's wrong.
I'm not advocating for blanket usage of frameworks either but I've yet to see a compelling reason to in this discussion thread not to.
With a framework you not only have to learn how build things in the framework (which takes a lot of time to become truly proficient) I also have to build what I am already supposed to be building.
I find personally that frameworks
* Simple things hard. Hard things simple.
* Anything outside of the happy flow they present to you in the docs is a major PITA.
* I frequently find myself scrabbling around for information when I need to override how the framework works in a particular scenario.
* They nullfy much of your pre-existing knowledge e.g. I am described at a lot of places as a JavaScript guy in the team, because I get JavaScript. When I use Angular or React, most that is irrelevant. It doesn't really help me.
If I am just using well established patterns + my existing knowledge of the programming language and environment. I can normally put something together myself that does just what I need it to do and I use a library for things like date time calculations or Ajax requests or something else that is mundane.
The only thing I'd counter to this with is when I see this approach taken, an informal "framework" of sorts tends to evolve naturally. First you write something that handles the routing, then soon you want to organize the code the route endpoints call, then you layer on the authentication at the top level request handling area, so on and so forth. Over time, as new requirements come in and new people work on the project, more and more patterns, conventions, and library are added to the codebase - pretty soon all that "glue" code meant for interfacing with libraries is reaching or exceeding the complexity of a framework based codebase (except your codebase probably has less documentation for things like conventions and patterns than a framework would).
That said, I don't think it's the wrong approach especially when the scope of the project is limited and/or there are ways to manage feature creep (e.g., frontend only, limited lifespan, internal facing apps, etc)
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.
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.
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.
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.
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.
I used this tool at the State of [redacted] Dept of Taxation to develop the whole system. The database was Oracle (I think) and we would write the backend code as such:
1. Copy the 2019 code function "VERIFY_TAX_RULE_147B_2019()" to "VERIFY_TAX_RULE_147B_2020()"
2. Follow this list of rule changes for this rule to change the function
3. If there are any 2019 functions in this function, make a ticket to copy+paste those in a similar fashion for some other developer
4. Close ticket
5. Get another ticket
The front end for the forward-facing revenue agents would also get updated in a similar fashion, one Power Builder form for each year and window they needed, so if you opened 2020 taxes you would get "WIN_FORM_PAGE_A317_2020" and if you opened 2019 or 2018... you get the idea.
It was a horror from the usual "software engineering practices" standpoint on stuff like code re-use, but it was super easy to do and based on the risk analysis it was the best/easiest/cheapest solution to be able to test, review, and ensure the accuracy of EVERY tax rule we implemented with iron-clad certainty.
Someone in QA would just go to each function, make sure it calculated things correctly based on the requirements, and do a few other checks. We had a big QA department that would do test driven development on each pull request (if it failed, you went back to fix it again, so since we used Visual Source Safe we ENSURED it worked the first time; you know what I mean if you used VSS) and sit down with the developer for each function and go through it in a heavy review. I can't imagine trying something like that in React or whatever, you could never ensure the software would always behave the same way each time with the network latency and huge underlying security concerns for the framework and a bunch of other issues we would have had to overcome to prove it worked correctly every time. Backend frameworks would be even WORSE for our risk profile.
Most importantly: no one cared what the damn UI looked like as long as all the buttons and text boxes were there in the designated configuration. They were all Windows 95-style UI boxes and I doubt that the front desk agents would have been happier to use some Reactified "pretty" stuff.
The story is just to say that I agree with you wholeheartedly that the UI/UX space has exploded with useless garbage you don't need in a simple, boring business tool and 95% of software is just that, simple and boring.
As far as most business software being "simple and boring", I wouldn't necessarily call it "simple", for the domain rules can get intricate. But it doesn't need buzzwords like blockchain web-scale AI or what not.
Desktop GUI's reached a pinnical around the late 90's and web UI's still cannot compete on simplicity and functionality. DOM-based emulators tend to break on browser version updates. We need a dynamic GUI-over-HTTP standard to allow us real GUI's on a browser or browser-like interface. Something like YAML, but more interactive. #MakeGuisGreatAgain!
However this improvement is in spite of using a tool designed for a different medium, rather than because of it, and the years and abstractions its taken to get here express this.
Having said that, cross platform is better going from web to desktop than the other way round.
I suspect we'll need a new web standard that's GUI-friendly. For one, have the option of sending raw coordinates to the browser and have the (optional) layout/flow engine be on the server. That way you only have ONE layout engine instead of a different one for each browser version/brand, which is what we are really dealing with.
A. app -> server layout engine -> coordinates -> client -> screen
B. app -> markup/JS -> client -> DOM -> coordinates -> Screen
Another advantage of A is that you can choose different layout engines not bound to DOM standards and quirks. Or even have none and go WYSIWYG. (Web browsers don't really do WYSIWYG well in practice, partly because font-to-widget-size-ratios are not standardized.)
"A" is more stable. It's better factoring, period.
One of the biggest motivations of these JS frameworks early on was due to the adoption of smartphones becoming the primary computer interactions. The other was the SaaS model, creating far greater demands on what needs to be done in a web form.
I've developed VB and cross-platform stuff like Qt and wxWidgets, and that stuff is no easier than the stuff I'm building with JS every day. HTML templates + automatic reactive bindings via Vue and a Redux/Vuex 'backend' are very simple.
What's more complicated and still shitty with JS frontends is the wider frameworks with Webpack, that come with a hundred packages that break often. That is the most painful thing I have to deal with day-to-day. The learning curve once you add in Babel, PostCSS, the various code optimizers and linters, TypeScript, etc can be quite intimidating.
But that has more to do with the tooling than the general approach being taken in modern frontend development.
And they keep failing because they throw layers at the problem: chicken-wire is used to fix problems caused by the duct-tape on the prior layer, etc.
It's becoming pretty obvious that Yet-More-Layers only exacerbates the problem. It may get "solved" by having fewer browser choices, but then the evil of oligopolies will kick in and we'll be back to the IE-esque problems, one of the most hated browsers.
Re: I've developed VB and cross-platform stuff like Qt and wxWidgets, and that stuff is no easier than the stuff I'm building with JS every day. HTML templates + automatic reactive bindings via Vue and a Redux/Vuex 'backend' are very simple.
My experience is different, and I observe similar bottlenecks at various orgs. Those JS-centric frameworks are harder to trouble-shoot when things go wrong, and different browser brands/versions render them different and/or wrong. With the VB/Delphi-esque tools, things show up exactly on the screen where I tell them to go: there is no if, ands, and buts. They follow my exact commands like dutiful robots. The technology is MY slave instead of the other way around: Thou Shalt Go At X=37 and Y=200. My Will Be Done! (Cue thunder clap.) React/Vue et. al. often go, "Sorry Dave, I cannot do that, but I'll do it my way anyhow." (I recommend GUI's use vectors instead of pixels these days, by the way. They are potentially equivalent when needed.)
Further, the quirks in pre-web GUI tools were getting ironed out over time: they got better with age. The web seems to get messier with age because of the layer-to-fix-layer problem above.
Is this just a matter of there being less ways to interact with the apps back then? Everyone had the same platform, same hardware, same screen resolution... etc. Plus, accessibility was an afterthought. Now, users have bigger and more varied expectations.
jQuery was never a standard any more than it is now. It was popular even driving a bizarre fundamentalist cult of personality worship, but that by no means makes it a standard. In technology a standard requires wholesale adoption opposed to mere frequent consumption, even if not enshrined by a document (de jure). For example there was never a time that jQuery was required in any commercial capacity either to seek employment, perform work, or deliver a finished product. Claiming that I hated jQuery during its prime didn't stop me from closing a job interview, but it did turn a few heads.
* https://en.wikipedia.org/wiki/Technical_standard
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.
Honestly. Where I work we have a few undergrad co-op students who have just finished their first year of school. No previous React experience. They jumped right in and were useful on our React projects after about week. They just read some docs, asked a couple questions and played with our existing code. They're smart people but they're not x10 programmers.
We have other large projects that are a more "traditional" mix of DOM manipulation use jQuery, global CSS, etc. and introducing new hires to that is never as smooth. There are no docs as thorough as React's that explain the patterns established in those codebases (if there are any consistent patterns at all).
One thing to note, we make what I would consider to be web applications (for data management & analysis), not web pages.
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.
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
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?
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).
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.
Not to mention the amount of finicky bugs you will encounter.
Making the same in a declarative way requires tons of options and it is a mess. See CSS flex, CSS grid, CSS @media queries, CSS box-model...
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.
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.
You can get pretty good mileage following industry best practice -- pick React, pick TypeScript, and pick the most popular tools for each.
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.
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.
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
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.
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.
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.
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.
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.
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.
After doing it several times, they will start building their own framework. At that point they should consider using an existing framework. :)
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.
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.
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.
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.