Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
Search - "webapp is fine"
-
```
Greetings @dfox @trogus, et al,
Here is some feedback with aspirations for the backlog.
I think it would be a good addition in the devRant UI if we could paste in code snippets and have that code display with proper fonts and syntax formatting, and even ideally with highlighting by language.
Currently, if we paste in any code or text for that matter it is translated into a sans-serif font (14px Helvetica Regular on webapp) which is fine for the poetic prose from our fine and noble devRant colleagues, but not ideal for shared monospace snippets of lesser and grand design.
Here are two websites that provide conversion of code snippets into formatted syntax, and HTML. http://hilite.me/ and http://markup.su/highlighter/
Both of these sites provide an API so highlighters can be used as a service.
Mockup attached.
Thank you @jaaku for your post, and welcome.
Cheers
devRant for the win
```13 -
As a pretty solid Angular dev getting thrown a react project over the fence by his PM I can say:
FUCK REACT!
It is nigh impossible to write well structured, readable, well modularized code with it and not twist your mind in recursion from "lift state up" and "rendercycle downwards only"
Try writing a modular modal as a modern function component with interchangeable children (passeable to the component as it should be) that uses portals and returns the result of the passed children components.
Closest I found to it is:
c o d e s a n d b o x.io/s/7w6mq72l2q
(and its a fucking nightmare logic wise and readability wise)
And also I still wouldn't know right of the bat how to get the result from the passed child components with all the oneway binding CLUSTERFUCK.
And even if you manage to there is no chance to do it async as it should be.
You HAVE to write a lot of "HTML" tags in the DOM that practically should not be anywhere but in async functions.
In Angular this is a breeze and works like a charm.
Its not even much gray matter to it...
I can´t comprehend how companies decide to write real big web apps with it.
They must be a MESS to maintain.
For a small "four components that show a counter and fetch user images" - OK.
But fo a big webapp with a big team etc. etc.?
Asking stuff about it on Stackoverflow I got edited unsolicited as fuck and downvoted as fuck in an instant.
Nobody explained anything or even cared to look at my Stackblitz.
Unsolicited edit, downvote, closevote and of they go - no help provided whatsoever.
Its completely fine if you don't have time to help strangers - but then at least do not stomp on beginners like that.
I immediately regretted asking a toxic community like this something that I genuinely seem to not understand. Wasn't SO about helping people?
I deleted my post there and won't be coming back and doing something productive there anytime soon.
Out of respect for my clients budget I'm now doing it the ugly react way and forget about my software architecture standards but as soon as I can I will advise switching to Angular.
If you made it here: WOW
Thank you for giving me a vent to let off some steam :)13 -
WTF with all this full screen popup to promote a mobile app on so many perfectly functional mobile/responsive websites. If I'm the developer of that mobile website and asked to add that kind of popup to my work, I'd be offended.1
-
So, I've had a personal project going for a couple of years now. It's one of those "I think this could be the billion-dollar idea" things. But I suffer from the typical "it's not PERFECT, so let's start again!" mentality, and the "hmm, I'm not sure I like that technology choice, so let's start again!" mentality.
Or, at least, I DID until 3-4 months ago.
I made the decision that I was going to charge ahead with it even if I started having second thoughts along the way. But, at the same time, I made the decision that I was going to rely on as little external technology as possible. Simplicity was going to be the key guiding light and if I couldn't truly justify bringing a given technology into the mix, it'd stay out.
That means that when I built the front end, I would go with plain HTML/CSS/JS... you know, just like I did 20+ years ago... and when I built the back end, I'd minimize the libraries I used as much as possible (though I allowed myself a bit more flexibility on the back end because that seems to be where there's less issues generally). Similarly, any choice I made I wanted to have little to no additional tooling required.
So, given this is a webapp with a Node back-end, I had some decisions to make.
On the back end, I decided to go with Express. Previously, I had written all the server code myself from "first principles", so I effectively built my own version of Express in other words. And you know what? It worked fine! It wasn't particularly hard, the code wasn't especially bad, and it worked. So, I considered re-using that code from the previous iteration, but I ultimately decided that Express brings enough value - more specifically all the middleware available for it - to justify going with it. I also stuck with NeDB for my data storage needs since that was aces all along (though I did switch to nedb-promises instead of writing my own async/await wrapper around it as I had previously done).
What I DIDN'T do though is go with TypeScript. In previous versions, I had. And, hey, it worked fine. TS of course brings some value, but having to have a compile step in it goes against my "as little additional tooling as possible" mantra, and the value it brings I find to be dubious when there's just one developer. As it stands, my "tooling" amounts to a few very simple JS scripts run with NPM. It's very simple, and that was my big goal: simplicity.
On the front end, I of course had to choose a framework first. React is fine, Angular is horrid, Vue, Svelte, others are okay. But I didn't want to bother with any of that because I dislike the level of abstraction they bring. But I also didn't want to be building my own widget library. I've done that before and it takes a lot of time and effort to do it well. So, after looking at many different options, I settled on Webix. I'm a fan of that library because it has a JS-centric approach. There's no JSX-like intermediate format, no build step involved, it's just straight, simple JS, and it's powerful and looks pretty good. Perfect for my needs. For one specific capability I did allow myself to bring in AnimeJS and ThreeJS. That's it though, no other dependencies (well, at first, I was using Axios because it was comfortable, but I've since migrated to plain old fetch). And no Webpack, no bundling at all, in fact. I dynamically load resources, which effectively is code-splitting, and I have some NPM scripts to do minification for a production build, but otherwise the code that runs in the browser is what I actually wrote, unlike using a framework.
So, what's the point of this whole rant?
The point is that I've made more progress in these last few months than I did the previous several years, and the experience has been SO much better!
All the tools and dependencies we tend to use these days, by and large, I think get in the way. Oh, to be sure, they have their own benefits, I'm not denying that... but I'm not at all convinced those benefits outweighs the time lost configuring this tool or that, fixing breakages caused by dependency updates, dealing with obtuse errors spit out by code I didn't write, going from the code in the browser to the actual source code to get anywhere when debugging, parsing crappy documentation, and just generally having the project be so much more complex and difficult to reason about. It's cognitive overload.
I've been doing this professionaly for a LONG time, I've seen so many fads come and go. The one thing I think we've lost along the way is the idea that simplicity leads to the best outcomes, and simplicity doesn't automatically mean you write less code, doesn't mean you cede responsibility for various things to third parties. Those things aren't automatically bad, but they CAN be, and I think more than we realize. We get wrapped up in "what everyone else is doing", we don't stop to question the "best practices", we just blindly follow.
I'm done with that, and my project is better for it! -
!rant
I need to quickly test how my web app works on mobile
PROBLEM: some of my features require https. I can test from my pc on localhost just fine, since localhost works.
From Android, however, those features are blocked, since I reach my webapp with my IP address; it is not localhost so Chrome raises a middle finger when I try to access the camera from an unsecured website -and rightly so.
I really need to get these tests done, how am I supposed to do?
I install an SSL certificate on my pc?!?
I disable Chrome security checks on my Android?!? (is that even possible?)
I install bluestacks real quick and hope everything works fine?!?
Wwyd?4 -
Who else finds HTML/CSS to be just plain bad?
since that's what the web adopted, apparently no matter what you are developing if it involves a GUI then the design method almost always follows in the same path as the web.
that's not the issue though, the real problem is that the web adopted a very horrible way to create a UI, while HTML might have been fine for 90s-style websites I just feel like its a very lousy way to create a modern interactive webapp UI, its just very painfully obvious that it wasn't designed for that purpose. remind me again what HTML stands for? "HyperText Markup Language" yea that sounds about right. and CSS really doesn't help but double down on the flaws of HTML.
on a whim I can come up with a better method:
instead of the weird <body><footer> structure, why not have say "objects that flow in a 2D space", you define the parameters location and dimension of these objects, with something like javascript they interact with each other and just like div in HTML objects contain smaller objects.
this makes a lot more sense than the footer/body design or the obviously duck-taped attempts at controlling the style in CSS, like flow, and absolute-position.
am I alone in this?9