A framework that makes things worse on purpose(postmodernize.telnet.asia)
postmodernize.telnet.asia
A framework that makes things worse on purpose
https://postmodernize.telnet.asia/
59 コメント
It’s all a matter of perspective. When I saw the title I immediately thought Angular JS.
Many, possibly most, UX developers cannot actually do their jobs. Instead they are hired to use some crappy framework to outsource the required competency. For many of these people dependency on some bullshit framework is the expected reality and anything different must then be poor execution... all objective metrics aside.
Many, possibly most, UX developers cannot actually do their jobs. Instead they are hired to use some crappy framework to outsource the required competency. For many of these people dependency on some bullshit framework is the expected reality and anything different must then be poor execution... all objective metrics aside.
Yeah, I see it all the time. Just the other day I found out some coworkers were using this fancy framework called "C" to build their programs. The produced assembly was way overcomplicated and impossible to read. Talk about job security!
Forcing people to perform in ways that are measurably inefficient by several orders of magnitude and punishing people who step out of line is the very nature of imposing job security.
I intentionally stare out of the window letting my life drift away while at the office only because I value my job security. If I wanted to do original innovative work for compensation I wouldn't be a UX developer.
I intentionally stare out of the window letting my life drift away while at the office only because I value my job security. If I wanted to do original innovative work for compensation I wouldn't be a UX developer.
Have you tried http://vanilla-js.com/ ?
It’s a framework with a math library and ajax embedded, 0 bytes minified, 25 bytes compressed as zip.
It’s a framework with a math library and ajax embedded, 0 bytes minified, 25 bytes compressed as zip.
This is really funny, it even lets you download it.
I'm not familiar enough with JavaScript, is this modern or obsolete JS?
I'm not familiar enough with JavaScript, is this modern or obsolete JS?
This parody website is probably close to 10 years old so it’s a bit outdated.
But the premise still stands, just needs more feature checkboxes :)
But the premise still stands, just needs more feature checkboxes :)
What? You mean it's not been maintained and there is no latest version? I've been using this on many of my sites, which I'm sure now is full of security holes and will break in modern (or ancient) browsers. Please someone suggest an alternative.
I personally use http://nojs.io/
All they need now is a Twitter account, a GitHub org, and a mandatory CLA, then it’ll be a real framework.
To their credit, they have the requisite number of emojis to be perceived as relevant. And I applaud that it can be grokked relatively quickly.
To their credit, they have the requisite number of emojis to be perceived as relevant. And I applaud that it can be grokked relatively quickly.
Don’t forget a “code of conduct” and “diversity and inclusion”.
And the footer has to say “Made with (heart emoji) in (hip, expensive city)”
> they have the requisite number of emojis to be perceived as relevant
Say it with me everyone: it is okay to use the right tool for the right job. Sometimes a JS framework is the right tool, and sometimes it’s not. The solution is not destroy all frameworks.
Anyway, I get that this is a joke, but it’s just been done so many tiiiiimmmeeessss
Anyway, I get that this is a joke, but it’s just been done so many tiiiiimmmeeessss
We unfortunately don't have enough power to destroy all frameworks, so you might be saying this to the wrong people. Say that to those who abuse them instead.
[deleted]
I don't need a new framework for that.
The app I'm currently working on clocks in at 75MB of JS before minification.
That's enough for the browser to take seconds to parse the whole thing.
The app I'm currently working on clocks in at 75MB of JS before minification.
That's enough for the browser to take seconds to parse the whole thing.
> I don't need a new framework for that.
Ahhh, you have some of the same front end dev team I have, huh?
Ahhh, you have some of the same front end dev team I have, huh?
Step back and realize that entire operating systems with browsers that can run JS can fit into 1.44 MB.
Oh my. Oh my.
Please tell me there's some dead code elimination step in your pipeline too.
Please tell me there's some dead code elimination step in your pipeline too.
The dead code elimination step just drops the framework?
Here's the kicker: none of this is dead code. Vendor libraries alone take 28MB.
Apparently one of the second order effects of rolling your own components is having enormous bundles because there's no incentive to minimize them.
3rd party libraries on the other hand usually go out of their way to be as small as possible.
I'm doing my best not to be sarcastic about this.
EDIT: we treeshake the bejesus out of it, but it's possible that there's some code duplication going on, because the build pipeline is, ahem, custom made.
Apparently one of the second order effects of rolling your own components is having enormous bundles because there's no incentive to minimize them.
3rd party libraries on the other hand usually go out of their way to be as small as possible.
I'm doing my best not to be sarcastic about this.
EDIT: we treeshake the bejesus out of it, but it's possible that there's some code duplication going on, because the build pipeline is, ahem, custom made.
What tech do you use? Also which kind of app is it? Does it have some special feature that causes the code bloat, or is it just lots of screens?
Just Angular 10 and associated libraries. The app itself is a run-of-the-mill "tables, details and forms" SPA, but there are indeed a lot of screens.
I see no reason why something like this should take so much space, but here we are.
I see no reason why something like this should take so much space, but here we are.
Ah, gotcha! Thanks for answering.
I've seen similar situations before. In my case it was mostly due to having a team that is larger than than necessary. Having multiple UI designers with differing opinions, developers that don't question redundancy in UI (or don't have time to check), managers that don't coordinate, and just communication problems in general.
This led to a lot of reimplementation and duplicate code. In the end they changed the frontend framework a couple times, but the issue started creeping up again.
I've seen similar situations before. In my case it was mostly due to having a team that is larger than than necessary. Having multiple UI designers with differing opinions, developers that don't question redundancy in UI (or don't have time to check), managers that don't coordinate, and just communication problems in general.
This led to a lot of reimplementation and duplicate code. In the end they changed the frontend framework a couple times, but the issue started creeping up again.
That's the joke.
Imagine a C compiler that produced sarcastically formatted assembly
Now I suddenly wonder what sarcastic assembly looks like! XOR swaps instead temporary variables everywhere? Jump tables for simple if/elses? Moving the stack pointer up and down for no reason, just because you can?
Would a framework be every language that complies to another for execution? Genuine question.
Even more true for an assembler. I guess, there's urgent need for a transpiling 6502 tool chain.
Did anyone else look at the embedded .js file? It's clearly just a load of junk cribbed from elsewhere... but this bit made me chuckle:
"__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED"
"__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED"
I thought it was from the React codebase, but it's differently named there: https://github.com/facebook/react/blob/b2ca3349c27b57b1e9462...
window._PLAINTEXT_PASSWORD_UNDERSCORE_MEANS_ITS_PRIVATE
Sometimes I wonder what the point of those web frameworks are. I find them harder to use than plain HTML/CSS/JS.
Frameworks are excessive for documents and presentations. They start to shine in development of apps, where you have to wrangle views, manage data bindings and react to user input in nontrivial ways. It's possible to roll out your own boilerplate and utility methods, but it's almost always counterproductive - this is not a part of task you have at hand and you'll miss on structure and conventions invented by framework team that really had resources to do it.
Part of the downvotes to your comment may be coming from the fact that this framework is (I'm assuming?) a joke.
Otherwise, I completely agree with you. The last few projects I've worked on I used vanilla HTML/CSS/JS and I found it so much better than using any of the popular front-end frameworks. I didn't have megabytes of dependencies before a single line of production code was written. I didn't have to spend time trying to understand any Webpack incantations.
Otherwise, I completely agree with you. The last few projects I've worked on I used vanilla HTML/CSS/JS and I found it so much better than using any of the popular front-end frameworks. I didn't have megabytes of dependencies before a single line of production code was written. I didn't have to spend time trying to understand any Webpack incantations.
Honestly this stuff all just makes me feel really old.
In a past life that wasn't even that far away, I implemented single page sites with smooth transitions and all sorts of fun stuff in a few lines of CSS. There was like 1kB of JS thrown on top to add a bit of "nice to have" functionality.
I implemented an entire clone of Flappy Bird in like 50kB. The bulk of that was a polyfill so it worked on IE8.
I implemented a curling game that would open up a webcam in the background and continuously capture and process images to try and detect shapes you'd drawn on paper. When it detected one it would trace the shape and decompose it into a convex shape as that's all the physics engine supported, then render this on a 65" touchscreen coffee table and let you curl with your custom shaped rock with realistically calculated physics including an appropriate density for your curling rock based on the volume of the same you'd created. It would calculate scoring and use websockets to communicate that to another device which was hooked up to a TV that displayed a leaderboard. This was all in about 500kB, and the bulk of that was the physics engine (what could've been a "computer vision" library was like a kilobyte of vanilla JS). There was no effort made to prune unused code or anything because it was never loaded over the network or required to be optimized for load times and I only had a week to build it.
I honestly cannot even begin to comprehend how we're shipping static websites with 1MB+ of JS. Damn kids, get off my lawn.
In a past life that wasn't even that far away, I implemented single page sites with smooth transitions and all sorts of fun stuff in a few lines of CSS. There was like 1kB of JS thrown on top to add a bit of "nice to have" functionality.
I implemented an entire clone of Flappy Bird in like 50kB. The bulk of that was a polyfill so it worked on IE8.
I implemented a curling game that would open up a webcam in the background and continuously capture and process images to try and detect shapes you'd drawn on paper. When it detected one it would trace the shape and decompose it into a convex shape as that's all the physics engine supported, then render this on a 65" touchscreen coffee table and let you curl with your custom shaped rock with realistically calculated physics including an appropriate density for your curling rock based on the volume of the same you'd created. It would calculate scoring and use websockets to communicate that to another device which was hooked up to a TV that displayed a leaderboard. This was all in about 500kB, and the bulk of that was the physics engine (what could've been a "computer vision" library was like a kilobyte of vanilla JS). There was no effort made to prune unused code or anything because it was never loaded over the network or required to be optimized for load times and I only had a week to build it.
I honestly cannot even begin to comprehend how we're shipping static websites with 1MB+ of JS. Damn kids, get off my lawn.
Good times. I used to replace .jsp with .aspx at the reverse-proxy.
Back in t get late 90ies I wrote my markup in XML and be then used mod_perl to transform it to XHTML using XSLT on the fly. But to be extra 1337, I renamed my index.html file to index.xml,
I contributed to a monstrosity based on Xalan and XSLT at runtime. What a beast. I don't know how we planned to support 5 concurrent users.
Even though this is a joke (made me chuckle), I have a hunch somewhere, someone is going to use this for real, for job protection or to appease that manager who insists that static HTML is sooooo 2009.
It loads too fast for me. It should take at least 10 seconds to fully load on a fast connection. It should also hog the CPU a little bit harder.
But it is a blank page...
I recently tried to make as terrible of an app backend as possible: https://github.com/winrid/terrible-express-app
Challenge: figure out how it starts, and how content is rendered.
(It's not that hard, but a little funny)
Challenge: figure out how it starts, and how content is rendered.
(It's not that hard, but a little funny)
Love the .idea directory in the repository (despite large .gitignore) and how you lie about package-lock.json. PwC, or Accenture would charge 5mln EUR for it and be perfectly self-confident about it.
This is perfect. I can use plain HTML and make anyone think I'm using a late great framework.
What this comparison says about modern web dev I'll leave as an exercise to the reader.