551–560 of 688 posts
Earlier quoted context omitted.
You cannot assume that the others with web programming is the same others with application programming. The result of one doesn't have to match the other.
Okay, but then how can an observer uninformed on the composition and dynamics of either group conclude that's the real reason it sucks? Unless they're slandering web developers but didn't make that clear?
I think it's worth noting that back-end web development is an usually pleasant place. In most other types of programming, many technical decisions are made by the platform and working with tons of legacy cruft is the norm, not the exception. For example, where else can you so freely choose the programming language? Linux Driver? Use C. Mobile App? Java or Swift/Objective-C for Android or iPhone, respectively. GUI App…
This is exactly why I've always been puzzled by the urge to move more and more logic to the frontend. In backend development you have a choice of many mature languages, tools and frameworks which are fairly sane. I'll take that environment as the foundation of a web application any day and apply the mania of client-side javascript to it selectively in cases where we need to minimize server roundtrips.
Yes. I feel like we're in the dark ages right now. JavaScript - Dynamically typed, does not scale what so ever. Code written in it becomes 'read only' very quickly. Impossible to refactor. CSS - Also becomes impossible to manage. Who knows if the class you wrote is or isn't being used in HTML or JavaScript somewhere. Same problem, read-only, it only gets bigger and more unmanageable. HTML - At the heart of it, the fo…
If anything, this understates the problem. A modal web application today takes an absolute minimum of five programming languages and three frameworks: * HTML * CSS * JS * A server-side language (eg Python) * SQL And then come the (leaky) abstractions on top of them: * A framework to make JS bearable (eg Angular) * A framework to make server-side bearable (eg Django) * A framework to make CSS bearable (eg Bootstrap) .…
* JavaScript (client and server)
* Redux (state management)
* React (UI Control framework)
* MaterialUI Controls (toolkit, one of many)
* JS Friendly DB
Earlier quoted context omitted.
I think your use of "minimum" is wrong here. If you're using React running on Node and Webpack as your task-runner you just need Javascript and that's it. Node allows you to run isomorphic JavaScript that runs on both your server side and client side (to ensure you don't end up with the Angular-style skeleton pages coming from the server), You can pick a nice ORM (like sequelize) to abstract away SQL, and Webpack all…
I still count three frameworks :) (React, Node, sequelize, I'm not counting webpack but I probably would if it's anything like as much of a pain as Grunt or Gulp or... And as you say, this is the lightweight version.)
Earlier quoted context omitted.
I think you're extremely overselling the complexity of things. Sure, there's a lot of layers and parts involved in making web pages work and in the popular web development ecosystem in general, but they were usually created to solve specific problems, and knowing of them can help you recognize how problems you may run into may be solved. None of them work by magic or are beyond comprehension. The browser speaks the H…
Thanks for a lesson on how the web works, but I'm already quite familiar with it. Your long answer proves my point about its needless complexity and layer upon layer of historical cruft. Can the complexity be buried under various frameworks and toolkits? Sure, to some extent. But not entirely. Browser inconsistencies always manage to sneak through forcing the developer to learn the entire stack.
Earlier quoted context omitted.
Ah I wouldn't count Node as a framework as I'd equate it to the JVM in Java world. But you are right, I'd probably lump webpack in there as it does have a fair bit of depth to it if you want to get the most out of it.
You still need to use Express or something similar on the server side for Javascript, I mean, if we are talking about standard procedures here. Plus with React, you are still doing that Javascript/CSS thingy and HTML of course at some point, so there is no avoiding that, and clearfixes, polyfills, etc, etc.
Sometimes I ask myself the question by doing this thought experiment. If we encountered a more advanced sentient species that writes code, would they say "Yeah, we went through that html/css/js phase of development, and in fact all sentient species do so. We got some good mileage out of it, and it was a total hack for a generation (we refer to that time as the lost generation), but it evolved into our current 'System…
That's too easy. We all know that in the ideal world, platform-independent code would travel through the pipes instead of HTML/JS. That code "plug" into an existing architecture in the client side to provide some service or functionality transparently to the user. Why don't we have that? mostly because of security concerns. That's why we can't have nice things.
This HTML/JS/CSS scenario evolved. It wasn't designed. If you started with a clean slate and designed the front-end, would you have something completely different.
I'll make another claim that I'd be interested in hearing feedback from others. If IBM had allowed CMU to make the Andrew Window Manager FOSS in '88, we never would have gone down the HTML rabbit hole.
Earlier quoted context omitted.
I think your use of "minimum" is wrong here. If you're using React running on Node and Webpack as your task-runner you just need Javascript and that's it. Node allows you to run isomorphic JavaScript that runs on both your server side and client side (to ensure you don't end up with the Angular-style skeleton pages coming from the server), You can pick a nice ORM (like sequelize) to abstract away SQL, and Webpack all…
> You can pick a nice ORM (like sequelize) I'm gonna stop you right there. Node is a helpful tool and I enjoy using it, but Sequelize was nothing but pure pain when I used it. You're much better off running raw SQL, or using a query builder like KnexJS. I would never use Sequelize for more than a 1-table read or update.
const results = await sql.query`
SELECT ...
WHERE foo = ${bar}
`;
if (!results && results.length) return;
await myQueue.add(results);