411–420 of 731 posts
Earlier quoted context omitted.
What would you recommend instead of those?
PostgreSQL is my database choice under practically all circumstances. I'd replace PHP with practically anything written by grownups. (Django, Rails, etc.)
It doesn't have to be complicated, if you get support from above. A few weeks ago I launched a new web site for a health care company. HTML, PHP, CSS, and MySQL. No frameworks. No javascript. No garbage. It replaced a site that was a mess of javascript libraries on top of frameworks on top of a half dozen jquery version and on and on and on. The company administrators, doctors, practitioners, etc... are so happy with…
I take a similar approach for 9/10 of the enterprise web apps I build, but use ASP.NET Core MVC instead of PHP, and I also favour SASS. Point is that SSR (Server-Side Rendering), with a sprinkling of simple JavaScript and XHR calls as required, is enough for almost everything I do, and it means build are really simple. Doubly so with a strongly typed language like C#. I've worked on Angular and Vue projects, and the…
A frontend framework is great if you are a company that really needs to slim down bandwidth and can hire expensive devs to maintain it. But for a simple no nonsense business application it’ll just slow you down and will gravitate towards being a mess.
Earlier quoted context omitted.
So using your summary at which step did the engineer make the wrong choice?
At the point that they chose to use all this kit and write "beautiful ES6". Write ES5, use a few polyfill functions, include the already minified mithril/vue/react js IF you actually are going to need dynamic DOM elements. An XHR sweetener is included in mithril at least, but if not, it's only a few lines easily memorized, as you will do them constantly, it's also a good candidate for that library you should have mad…
So are you saying that most projects that use JS should avoid the use of ES6?
Was it the inflow of too many mediocre graduates that needed help preventing themselves from writing buggy programs? The social credits that people added to their CV for making yet another uber-popular javascript thingy that got a lot of github stars? Or was it bored engineers in the major web companies who have nothing to do because their advertising money cow is already being milked, so they decided to build toys to sabotage everyone else?
well, programming is hard. It has always been hard. regardless of the field. classic web development is complicated as well.
hey what's your timezone? no, i don't mean getTimezoneOffset(); https://www.iana.org/time-zones LOL
Because it had to play catch up to native apps feature wise due to demand, while building upon a base that wasn't intended for that, while serving the same app to literally thousands of different environments and expecting it to work perfectly. Thus, growing pains and overly complicated frameworks/plugins/other bits slapped together to address the core issues which ballooned the complexity. But we all knew that. What…
> Webcomponents once Chrome 77 drops and Firefox matches parity will finally be production worthy, and they're actually quite easy to build. What's changing in Chrome 77? A caniuse search for "web components" does not turn up anything that's not old news.
Once form registration is in place you'll be able to create component libraries that should truly work no matter the environment or libraries being used alongside them (as long as you have an up to date browser).
It doesn't have to be complicated, if you get support from above. A few weeks ago I launched a new web site for a health care company. HTML, PHP, CSS, and MySQL. No frameworks. No javascript. No garbage. It replaced a site that was a mess of javascript libraries on top of frameworks on top of a half dozen jquery version and on and on and on. The company administrators, doctors, practitioners, etc... are so happy with…
Damn, you broke into my top-secret consulting role ;) I completely agree with all of this. There is probably a billion-dollar market out there for rewriting garbage business apps that were developed using the hipster tech flavor of the week.
I’m not sure ActiveX, ASP, and SQL server were ever hipster. You’d be doing the world a favour by re-writing these apps.
Literally doing a favour: there’s never any budget for it.
In 2012 you were building sites and even applications with a stagnant language (JavaScript) that lacked any module/bundling support while having to support multiple browsers with differing standards. Routing, state management, dependency resolution, etc. were handled on an ad hoc basis if at all. The current complexity is a result of addressing these issues and doing so at a rapid pace.
Earlier quoted context omitted.
> Your manager or project owner or whoever says "we want a webapp" are you gonna stick your neck out and argue against it? The question is: what are you going to argue for instead? Not using the web at all is a non-starter, especially in the retail space where you'd get killed by a web-based competitor. I don't know what your experience is, but historically my bosses haven't given half of a damn what tech stack I use…
I mean SPAs and near-SPAs. "Web apps". Web sites as in mostly server-rendered sites with HTML, CSS, and some JS sugar on top could sub in for an awful lot of "web apps" and improve UX, performance, maintainability, and development cost. [EDIT] incidentally I notice you keep arguing against things I've not actually written.
> ...improve UX, performance, maintainability, and development cost.
I don't buy it at all. As mentioned, I've done both professionally and there are reasons I keep picking React (or a hybrid ala Next) that don't involve a bigger paycheck or "peacocking".
This could be rephrased, "Why is kernel development so complicated?" or "Why is FPGA development so hard?" In any given technical environment that has sufficient time to mature there will be more information to process, more choices, and more surface area. It's just the principle of intellectual entropy. Stuff tends to get larger and more complicated and specialized because it is. If you want something simple, why no…