Or shrink to mobile size or use your browser's Reader View.
Horizontal scrolling multi-column was a weird aesthetic choice based on personal preference (despite bad and growing worse browser support, sigh), but it's a personal blog and as "a 90s web kid" I strongly believe weird aesthetic choices are what makes blogs personal and not just another walled garden like most of social media (or Medium).
Unfortunately it makes them inaccessible in this case, I wouldn't even know how to scroll sideways unless you actually expect a user to click and drag a scrollbar. Even if the site was usable the the text is still illegible.
Yeah, I wish I had scroll wheel support again. The CSS for that was never standardized and the browsers that supported it no longer exist and most of the JS-based solutions are a bit more lacking than I would prefer.
I intend the following as friendly feedback. Personal is fine but that doesn't have to imply impossible to use.
The main problem is that it's not discoverable, at least on MacOS where there are no scrollbars. I found the horizontal scrolling by chance after trying every key on the keyboard. In the meanwhile I had already scanned the article using the Reader mode in Safari.
Personally, I think that a UX bug on Apple's side that they lost scrollbars and any hint of "more to see". As an iOS and iPadOS user I get so frustrated every time I discover a thing scrolls that wasn't obvious. I have observed that almost every iOS/iPadOS user (mostly subconsciously) "twitches" constantly over apps trying to find things that scroll. I wish Apple would provide at least something of a better user experience here.
This is also one of the things where I'm disappointed that browser support for multi-column has only grown worse over time rather than better: I tried to intentionally set it so that there would be at least some next column "bleed through" horizontally in CSS and that (mostly) worked when I built the CSS theme but WebKit, Blink, and Firefox all moved to implementations that always balance columns evenly in viewport space rather than what the CSS specifically asks for. (And Edge Classic died, the one browser that really cared about good multi-column experiences.)
I get this issue on Android Chrome when using the "Desktop Site" version.
Personally, I believe the UX problem is with the website. You seem to be aware of the problem and yet decided to keep a broken version. That's a UX decision made by you.
The web is top-to-bottom, every user has this expectation. The usual mouse has a top-to-bottom scroll wheel, not a left-to-right one. Maybe it's not what you want, but it is what it is. You can either accept that fact and use a top-bottom layout, or accept the fact that you made a deliberate decision to create a confusing UX.
I stated several comments up directly in this chain that a confusing UX on my personal blog was a deliberate decision. I stand by that.
I also point out that I tried to add affordances to make it easier to use and was stymied by bad browser support getting worse. I haven't updated this CSS in a while, because I haven't felt like I needed to, but the way the browsers display it in 2021 is actively worse than when I wrote it and I'm sorry about that.
I can also at the same time believe that Apple removing scrollbars altogether and not replacing them with some sort of affordance is also a UX crime, whether or not my own decisions that make are worsened because of it were deliberate.
Well, it's good to see that you accept its your own decision, given the circumstances, that made it what it is.
If you're set on that, maybe you could try adding a really unmistakable indicator such as a "Scroll right for more ->" text. I'm not sure if that's good as I'm not a UX/UI designer, but probably better than nothing. Still, as a user, a would prefer something that I'm used to, such as top-down text.
When I wrote this CSS the columns themselves were supposed to do that and supposed to "peek" across the edges. Browsers decided to take a different, worse layout approach to multi-column and broke my intended CSS affordances. There wasn't intended to be "nothing". Just time and tech debt.
Multi-column plays poorly with mobile user agent UX, because the swipe motion made (often with just a thumb) is inaccurate. Works alright if you can reduce it to just the y-axis, but you ask a lot of your end-user on a mobile UA to scroll horizontally also. Flipbook or vertical scroll are the two metaphors that work here.
That having been said, you should be able to tune your stylesheets to vend one that gets users single-column text on mobile devices with some elbow grease. Up to you whether it's worth it.
That's absolutely what this CSS already does and why a suggestion above is to shrink the browser tab width to a "mobile" media breakpoint for vertical scrolling if that is preferred even on wider screens.
The 90's web was broken with bad assumptions about the viewport for what was supposed to be a flexible layout engine. This is no different that hardcoding for 640x480 and making everyone else suffer.
I see your point and that's up to you. But I do think factoring in the end user's experience is important here if you want them to listen to your argument.
You're trying to sell someone that your idea is right, but having the desktop experience be a bit difficult (and putting it on the end user to deal with it) doesn't really help you in communicating your points. It also makes it harder for them to digest your content, therefore people might just skip over it.
But again, it's a personal blog so all these decisions are up to you and your liking!
I appreciate that and tried to compensate for some of the trade-offs with the CSS available at the time. CSS that the browsers seem intent on not supporting and maybe dropping. I do find upsetting that I end up having to apologize a lot for trying to do some things that I thought were fun/unique/unusual/personal touches and the browsers just getting worse about it with passing years rather than better.
It is interesting how many of these comments have fallen into style of substance fallacy over the contents of the arguments themselves, and I am listening to all of this feedback. This current CSS was designed to make 90s kid me happy, primarily on "Edge Classic". It's not aged as well as I would have liked, and I don't know if/when I'll revisit it, but I am listening.
You know what? Keep it. It's weird but I think that makes it cool.
Don't get demoralized. Everyone is boring today. If this was a business or something I'd say ditch it and make your website have Bootstrap or whatever least common denominator thing. It's not, it's your place to express yourself, so don't let wet blankets ruin your site for you.
Here's two other weird sites just to keep up your morale.
> I strongly believe weird aesthetic choices are what makes blogs personal and not just another walled garden like most of social media (or Medium).
Sure, but in this case the choice also strongly sacrifices usability. Even on non-MacOS desktop firefox I didn't know there was more to the article before reading the parent comment.
If you want people to read more of the article then perhaps make it easier to find out that there is more of it.
Admittedly I like the column-based layout. Just the scrolling should work via mouse wheel and stop at whole columns. Not sure if I would want this on every website I visit, but it's a nice change. At least it doesn't scream "materialize!" or "bootstrap!" :)
I still think it is a shame that Microsoft's proposed scroll-translation CSS still hasn't made it into the CSS multi-column standard (and also didn't survive Edge Classic to Chromium Edge shift either).
If you make your window small enough to hit the tablet/mobile breakpoint, it collapses into a vertical layout, which is much more pleasant. I honestly cannot fathom what would possess a person to make horizontally scrollable columns like this, since it's both difficult to use and introduces novel typographical defects such as widows and orphans.
While the horizontal scroll isn't immediately obvious I found it easy and enjoyable to use as I can just start reading at the top of the next page instead of concentrating on not losing my place during a vertical scroll.
Also, if a typographical defect has a name (widows and orphans) can it truly be novel?
There is a JS library script tag on the site to try to correct the worst widows/orphans and some other typographic defects. It's after body load so as not to slow time to first paint and I don't think all browsers correctly readjust multi-column layout after its corrections/adjustment.
The caniuse statistics for CSS native support for widows/orphans correction is much better today than when I last worked on this CSS file: https://caniuse.com/css-widows-orphans
Novel to web pages, is what I meant. Software such as TeX and MS Word have a considerable array of (sometimes quite complicated!) tools for dealing with such things, and the absence of such concerns from web development was something that I had never really thought specifically about until seeing a heading appear right before a column break on this article, followed by an orphan in the next one.
If the author is out there: Add scroll snap to the text box! Without it, you're constantly misaligned, making it hard to read. Scroll snap is one of those great new CSS properties that makes thing that used to be hard easy.
I've considered that, but I feel scroll snap is actually the opposite of the intended affordance for what I was going for. I don't want the scroll to be exact. I want columns to peek out just a little bit in either direction in a "more to see" way. (I had that for a while with this CSS but browsers dropped some support for it.)
There's not a bit of paragraph peaking in, there's a bit of the paragraph off screen, so to get everything in the paragraph I have to scroll right and then left whenever I get to the end of a line.
Sorry, but I have to correct this every time I see it on here: TypeScript is accommodating to C# developers, but it's equally accommodating to developers who don't want to touch classes with a ten-foot pole (and to everyone in-between). React benefits from it just as much as Angular does, etc.
Most devs from India that I talk to are learning react but know angular. They would like to continue with angular but it is not something that is excepted to companies we sell to anymore.
I did a quick search on Indeed and compared the number of results found. It's not scientifically rigorous or anything, but it should give us a rough idea of where Angular and React stand compared to each other. The search terms where "Angular JavaScript" and "React JavaScript" and similar without the quotation marks.
Angular, Anywhere in US: 25,248
React, Anywhere in US: 29,197
Vue, Anywhere in US: 8,032
Angular, California: 2,658
React, California: 4,643
Vue, California: 1,134
It seems like Angular and React are both very popular, but Angular is a bit less popular in California than elsewhere in the US. Vue is less popular than both, but it is a bit more popular in California than the rest of the US.
In 2020 I searched for employees and 90% were Angular, 10% React. Now it is the 30-70 (because the skills market is delayed compared to things people are currently learning).
This website is so hard to read from contrast to the scrolling. Can someone copy the text here?
*EDIT*: I did it here (and for the most part I mainly agree with the sentiment behind this article):
# Angular is Rotten to the Core
I find Angular an impressive front-end framework for just how badly it is designed, top to bottom, and yet how large of a cult-ish following it has. There exists a weird “everyone knows it” mentality that in practice seems to be entirely an illusion. There is the strange “no one got fired for picking Google” echo of ancient ibm mistakes exacerbated by Google barely dogfooding Angular (and arguably never successfully). There is the awful internal politics of Google that have produced many horror stories from former Angular developers, former open source community contributors, and combinations in between, and an impression that the rabbit hole goes only deeper if you could dig beneath Google NDAs and secrecy.
## Why does anyone use Angular in production?
I’ll start with the sociopolitical weirdness and save the real meaty technical stuff for the end. Let’s think of it like one of those long, mostly useless food blog narratives to air some grievances before the technical equivalent of a recipe.
## “Everyone Knows It”
When we started a greenfield project at my employer (opinions here are mostly mine and not that of my employer and other usual disclaimers apply, of course) I suggested React, as I was comfortable and happy with React in other projects, and even did some prototypes in early testing in React. I was brought on to the project to be “the backend expert”, so I was overruled because “no one knows React” and “everyone knew Angular”. I didn’t know Angular at the time, other than gut instincts from skimming tutorials that it was “Enterprise” and “Bloated” in all of the worst senses of both words, and some hesitation/general “sense of doom” from reading the blogs of Rob Eisenberg (because I had used Durandal successfully in previous lives and Aurelia semi-successfully in more recent projects; I’ll come back to all of this later in this post).
As soon as we started digging into real world usage of the application it became very apparent to me that everyone that claimed they “knew” Angular, simply didn’t. Out of frustration with application performance and modularization needs and so many little problems, I found myself increasingly having to become an expert on Angular, and the more of an Angular expert I’ve become the angrier I’ve become for using Angular at all.
I think there are two big lies that add up to an illusion that “everyone” knows Angular: the Angular template language uses an `.html` file extension, and Angular Dependency Injection at first glance looks “Enterprise” and familiar to Java developers especially. (Sometimes C# developers too.)
The first I think is the biggest illusion and the one that causes so much trouble. React’s jsx/tsx looks “weird” at first, and “no one knows it” without at least some learning curve. Vue and Svelte aren’t liars either and people realize there is a learning curve to learn their `.vue` and `.svelte` templates. Like the much mocked Jurassic Park lines “it’s a Unix system, I know this”, despite the many variations of Unix and the weird ui shown on the screens that wouldn’t have been familiar to anyone, “it’s an html file, I know this” is an amazing misdirection of Angular’s. Angular’s template language is no less a complicated template system like `.vue` or `.svelte` or `.jsx`, but that first impression from junior developers that they know enough html it will be “easy” and they already know it is amazing (and wrong).
Also, I realize that Angular themselves refuse to call it a “template language” and go out of their way to call it a “view engine”. They seem to insist that you could ship the template language’s html to a browser (as Knockout used to do, using only html compatible custom attributes, back in the day...
HN has been slowly becoming Twitter. It's hot takes, dunkings, and outrages. It started with and mostly limited to Google bashing (as the current aricle is). Unfortunately it's going to spread. HN is on its path to become another toxic internet forum or social media.
Back before everyone was a bag of sad cats; a toxic internet forum was just called a forum and the people were amazing. Still are. I use IRC and message boards still and it's just fine. I don't use freenode anymore, duck that guy to quack.
React is fun and simple, makes juniors look senior for a bit, until apps get complex. Sr react devs build even further complex abstractions due to the nature.
Angular development is reliable. You know what you're getting and what comes with senior development.
(Ive moved 2 prototype projects that needed to scale from React to Angular).
> Angular development is reliable. You know what you're getting
You get a product built on top of a framework which does 200+ things you never asked for, can’t disable, and whose the complexity of is reliably causing your simple code to crash in ways which are impossible to analyse, debug and explain.
I’ve been burnt a few times on this, and months down the line, my simple CRUD angular apps still have unexplainable, unfixable issues which is destabilising some of our backend systems.
And we can’t fix it. Because nobody has any fucking idea what goes on with Angular internals when shit blows up like that.
And yes, you can rely on that.
I’ll literally take anything not Angular over Angular at this point. At least I should be able to reason about what I’m shipping and fix bugs once reported.
You'll get there eventually but a quick level up: it's only that way because you don't know how it works at it's base level and nobody will be able to fix it until they do. You have to spend the time digging in and if you don't then don't be surprised if it doesn't work, that's going to be every system you work on though. Not everyone has the time to put in when a new better framework comes out every 6 months. So I use old shit :D it still works and it's still fast and I know it backwards and forwards. Html and Javascript with a backend that generates all the shit so I don't need to make backend calls add socket io for loading stuff after the page is loaded. No framework except the server side, and that depends on the language.
If you want to get really frustrated but level up super fast on multiple languages and frameworks? Install JHipster, and then change something. It's amazing how easy it is to break and what a giant pita it is to fix, but i do it all the time because you really gotta get in there and poke and prod until you figure out the problem.
I have none of these problems and I've built a ton of Angular apps. Angular does have a steeper learning curve for new developers but once you get past it, it is much easier to maintain a large application. React is the opposite-- it is very easy to get started but a general lack of opinionation and guard rails means that a project mostly built by junior devs will start to show cracks sooner.
For me, the worst parts of Angular are all about it elaborately reimplementing things that already exist in Javascript. I think the most obvious example is its template expressions and pipes. Instead of being able to have Just Javascript, there's an entirely new syntax they want you to learn and to write special handlers for, and the extra overhead that comes with its parsing behavior.
Angular is used heavily at my work and we manage to please thousands of users every day, developing in it isn't bad either.
I use it for my personal projects too, and yeah so far no problems and I manage to crank out stuff in a pretty decent rate.
Yeah it's all about what you know and who you know.
I used to think ruby devs were clowns as a Drupal dev, it was dumb, I have since used ruby a bunch just fine, same with X language vs Y language, it's just humans being humans.
If you want to know where racism comes from talk to a tabs guy about spaces (but only if he uses a Mac and says he does all his development in a text editor). Or a Mac guy vs a windows guy etc.. I used to fall for that junk but I just grew out of it. Give a dev enough time and he'll realize it's all the same just different words and delimiters, and then you can think about bigger things.
I know this site is old and stuff, but if you're looking at this website and thinking wow what a great idea horizontal scro... no, don't, it's a bad idea in every way possible.
And don’t get me started on silently hijacking my clean ES-promises and turning them into Angular’s own ZoneAwarePromise, managed by its own terrible, undebuggable microqueue.
It’s literally impossible to write clean code which compiles to clean code with Angular.
Zone.js is very useful. You can observe the life time of a chain of asynchronous operations without requiring that they return promises or use callbacks. This makes it very useful for providing "no code" SSR of an otherwise frontend framework. You can reliably know when the page has completed rendering, because the zone has become "stable", that is to say it no longer has any way to run any handlers for future events.
Zone locals also allow you to maintain "task-specific" state, for instance allowing you to access the current request being processed without it being passed around. Another use case is having your logger show context information- Frameworks like RoR have done this forever- they show the request ID on each log message that results from processing that request. I don't think there's any good way short of passing the logger around everywhere to pull that off in Javascript short of using Zones.
What it does to Promise and other parts is definitely an annoyance, but the benefits you get for it are a lot. If Zones were a standard part of the JS runtime none of that "patch the world" would be needed, as the JS runtime would support it out the gate. Zone.js was always meant to be a polyfill of the Zone concept on the way to standardization. It is unfortunate that standardization has failed because I think it's a very useful idea and there isn't any real alternative to achieve the same goals.
This is dramatic. A lot of developers put a lot of time and effort into trying to make something that improves developer experience, and trashing them is shitty.
Is there things wrong with Angular? Yes. Is it my choice of frameworks? No.
But Angular came out years ago, back when jQuery was the defacto standard. And much like how jQuery (and Flash before that) isn't in vogue now (nor should they be), Angular presented a lot of unique ideas about how we could be thinking about building for the web, and for that I'm appreciative.
IIRC, Angular.js was originally built as a prototyping tool for designers. It got popular, and the creators did their best to make it work. It didn't. But it's a lot easier to write negative articles such as "Angular is rotten to the core" than it is to create a javascript framework.
That was my initial thought as well, but if you read the rest of the article there actually is quite a lot of technical details. It's not just trashing developers. I think the title could probably be changed to be less inflammatory.
Also known as Angular 1 and Angular 2+ for those confused by the (very confusing) branding. Angular 2 was a ground-up rewrite in a very different style.
ADDENDUM: The original title on HN was "Angular is Rotten to the Core". My defense was about the "core" aspect... since the core was, in my opinion, a noble attempt at making the web a better place.
(Additionally, I feel like if you're going to criticize Angular for being by Google, you can't really be recommending React. Also, not the point, but I think the “No One Got Fired For Picking Google” subheader is a weird take on the original IBM version of the quote.)
In this case the phrase "to the Core" is much more directly aimed at from Angular's core outward in that Angular literally has a key library named `@angular/core` and that my technical complaints originate there and I do try to draw the line from those decisions made in `@angular/core` and the ripple effect they have on other major libraries and the ecosystem as whole.
That the phrase "to the Core" serves as double entendre here questioning their intent/philosophy behind the existence of the framework was certainly intended to be clickbait, but I thought it clickbait that HN would appreciate because it is technically correct (and as we all know that is the best kind of correct). I appreciate that it was not well received by some and I may have been too clever with it.
Maybe Angular is a poison pill invented at Google to slow the competition?
I had to work with Angular and I hated it, especially the compilation times and the fact it is very opinionated. But I hate everything front-end that is not Javascript + jQuery. I suspect I would hate React, too. Thanks God I no longer have to touch front-end at work!
It's interesting how different "bubbles" of software development can be.
For me, as an engineer whose worked across FAANG and YC startups in San Francisco, Angular has had absolutely zero mindshare for at least the past 6-7 years. Every company I know uses React and every engineer I know knows React. So it's interesting and somewhat alien to hear it being treated as the default option.
I used to hear that about ruby from devs from other companies, it's just the groups you roll with that define a lot of your choices, including frameworks.
Angular has its fair share of problems. For example, issues can be left open for a very long time and the way Google requires the Angular team to ensure that the many, many, internal projects that use Angular do not break creates a lot of development overhead and slows the pace of development.
I actually had a great conversation with a core Angular dev just today where he outlined the whys of some of the issues.
The Angular development team, not including managers, developer relations, etc was described to me as “about half a dozen people”. It’s a very small team with a big task.
I think that Angular+RxJs+NgRx is a great way to build apps. Once you really get the hang of it there’s nothing like structuring your app using DI+directives+Observables. I recently created a drop dead simple, performant, and insanely reusable, intersection observer directive constellation that’s easier to use than any other IO library I’ve seen to date. It was maybe a hundred lines in total.
I submitted my first PR over the weekend. It’s easy to complain about Angular, but, I’d like to see more people who use it show up to help out. Yes, the corporate side of things slowing the community down is annoying.. But with enough external devs the process could evolve into something more decentralized. Maybe? Who knows unless you try.
I vetoed NgRx in my projects because I didn't think it was a good RxJS citizen either. I've used redux-observable a bunch in React and also in pure Node projects and NgRx on the surface feels like a relative to redux-observable but digging into it below the surface I wasn't happy with it at all.
I love RxJS and so many of my problems with Angular come directly from how it and its ecosystem don't use RxJS well and don't set up developers, especially junior developers, to use RxJS well.
interesting article! some feedback: it looks like you host your blog on github pages .Please add an SSL certificate, it is free and would eliminated the annoying browser warning.
LCARS CSS is nice and original, perhaps you can change the font/contrast to achieve something more readable (just in case here are some ideas https://www.thelcars.com/themes/ )
Thanks for the suggestions. I hadn't realized Github Pages supported SSL today for custom domains, missed a Let's Encrypt at some point I suppose. Trying to get that activated. I'll have to look into the mixed content warnings later.
Might also play with some of those newer color theme ideas, the Lower Decks inspired ones spark joy for me. (I used a different theme site for some of the colors that was at lcarsdeveloper.com and seems maybe done now. This one seems similar and I'm wondering if they just had to change domain names at some point.)
you are welcome! enabling SSL should just be a click on github and is very convenient. I appreciate that your site is different and not like everything out there. Probably just adjusting the font color would go a long way in terms of readability but hey...it is your site so if you like it and gives you joy as it is perfectly fine :)
I watch lower decks with my kids instead of bluey now:D it's gggrreat! I do like the color scheme they put together as well, that should be cool, you should name a class boimler :D
I agree. I miss being able to scroll with the mouse wheel. I wish the CSS for that had been standardized. I had been seeking good JS options, but still sadly haven't found a good one that works reliably and smoothly/performably. https://github.com/WorldMaker/lcars-moderne/issues/1
Thanks. I might try that. I seem to recall not liking solutions that easy for some reason, part of that was trying not to interfere with the native CSS behavior in "Edge Classic", though I suppose with "Edge Classic" that's definitely no longer a concern and I hadn't thought to revisit easy solutions I suppose.
It's interesting that articles about the features of JS frameworks and their provenance are an easier read than articles about how to actually use those frameworks.
I wish it was easier to use no framework at all, no angular, vue, react ... but still benefit from npm/yarn package management, development server with hot reload and maybe even a test runner. As someone who only occasionally needs to build relatively simple frontends against existing APIs, using full-blown angular/react/vue just seems so wasteful. But the last time I tried to put such a setup together, I just couldn't make all the parts (yarn, webpack, jest, ...) work together, and lots of the various plain JS "starter" projects out there are broken as well. It's pretty bewildering – shouldn't this sort of thing be easy? Is there some kind of a vue-cli for frameworkless projects, or how do people get started building more lightweight web apps?
It sounds like you were trying to use a bunch of tools without understanding what the tools actually do.
That said, webpack and jest are bloated messes and easy to break. I'd say just stick to esbuild as your lone dev dependency and get to work writing your framework-less project. Otherwise, take a look at the vanilla Vite template: https://vitejs.dev/guide/#scaffolding-your-first-vite-projec...
If you find that you want a framework (which may be inevitable), give Mithril.js a shot. It's very unopinionated.
These days I tend to only use esbuild. For testing, I use my own homerolled test utility and the built-in Node.js assert module, or uvu.
> It sounds like you were trying to use a bunch of tools without understanding what the tools actually do.
That's true, so far I've only interacted with these tools in vue-cli-generated projects and the like.
I'm not sure if "framework-less" is the right term even. I'd like to be able whip up quick UIs with a few libraries where needed without too much unnecessary complexity. I find there's little benefit in forcing simple UIs into Vue components, but juggling libraries without npm/yarn is cumbersome, too.
I'll have a look at Vite and Mithril.js, thanks for the pointers!
I think what you're missing here is that as soon as you start answering the questions necessary to get those tools to work together right (for example: how do you split files? how does your routing work? how does injecting replacement code for hot reload work?), you end up with a framework.
Of course any plain JS app I'd write would end up being a kind of nano-framework; for me, the difference is in the unnecessary complexity this approach would avoid. Vue, React etc. bring a lot to the table; sometimes I'd rather just write that tiny, less-than-ideal nano-framework because it's good enough and pulling in tons of dependencies feels unnecessary and might actually increase my app's attack surface. I'd like to keep the creature comforts of npm/yarn etc. though.
“Feeling wasteful” is not a logical evaluation of the technology. Does it feel wasteful when you used an incredibly powerful computer capable of almost anything to post a text comment to a website in the same way you could have 20 years ago?
VueJS is very lightweight and loads almost instantly. It runs on even very old computers well. Native JS will never be able to compete with frameworks because frameworks have the ability to rapidly innovate and try new things without worrying about having to keep them around forever.
IMO the browser should become something like a CPU where it provides the low level components to do anything and the website provides the framework to make it easy.
It doesn’t “feel wasteful” to use C or Python to print hello world when it could have been done in raw ASM.
>
IMO the browser should become something like a CPU where it provides the low level components to do anything and the website provides the framework to make it easy>
Maybe webassembly is the thing that you are looking for?
WASM is where I think the web should be heading. It's been shown time and time again that designing good high level interfaces is very hard and there will always be a better design out later. Platforms like web browsers are not able to innovate like libraries can.
JS has multiple implementations for date interfaces and they are all flawed in ways. Rust decided that date handling should be the job of 3rd party libraries which have the freedom to drop bad ideas and break compatibility for the goal of a constantly improving implementation.
One thing I really like about the current web is that I can still inspect and dissect almost everything with just the developer tools. I couldn't do that with WASM blobs, which of course the ad industry would absolutely love since then they can just obfuscate their binary blobs and hide anything in there, legal or not, malware or not, and it's no longer feasible to rip it out.
They feel wasteful because what I'm doing really is pretty simple in most cases. I can easily build that in plain JavaScript and it feels wasteful to pull in all those layers of abstraction and write Vue components where plain JS ends up being shorter and easier to reason about.
I've had some success with npm, snowpack, mocha, typescript as that sort of stack for more "vanilla" efforts that feel rather more "modern". I think mocha is easier and cleaner than jest. I like keeping all of my transpilation to just Typescript without needing a massive Babel install/pipeline. snowpack (https://www.snowpack.dev/) right now I think is in a sweet spot of a better "ES Module native" developer experience than webpack and has better defaults when left unconfigured. (So much so that while there are snowpack templates/generators provided by the project I mostly don't use them other than for reference.)
Why can't you use npm modules via a CDN like https://unpkg.com/? Add a JS file that downloads whatever package you need and then use them in that JS file? Have your HTML page load that file via a script tag (you can also have the HTML file load the packages in a script tag) and then you're off to the races.
That's what I did before npm came around, but proper package management, hot reload, test runners etc. are creature comforts I'd hate to do without these days. Keeping dependencies up to date when getting them from a CDN is pretty cumbersome.
147 comments
[ 2.2 ms ] story [ 204 ms ] threadHorizontal scrolling multi-column was a weird aesthetic choice based on personal preference (despite bad and growing worse browser support, sigh), but it's a personal blog and as "a 90s web kid" I strongly believe weird aesthetic choices are what makes blogs personal and not just another walled garden like most of social media (or Medium).
I've been tracking it for a while: https://github.com/WorldMaker/lcars-moderne/issues/1
The main problem is that it's not discoverable, at least on MacOS where there are no scrollbars. I found the horizontal scrolling by chance after trying every key on the keyboard. In the meanwhile I had already scanned the article using the Reader mode in Safari.
This is also one of the things where I'm disappointed that browser support for multi-column has only grown worse over time rather than better: I tried to intentionally set it so that there would be at least some next column "bleed through" horizontally in CSS and that (mostly) worked when I built the CSS theme but WebKit, Blink, and Firefox all moved to implementations that always balance columns evenly in viewport space rather than what the CSS specifically asks for. (And Edge Classic died, the one browser that really cared about good multi-column experiences.)
The web is top-to-bottom, every user has this expectation. The usual mouse has a top-to-bottom scroll wheel, not a left-to-right one. Maybe it's not what you want, but it is what it is. You can either accept that fact and use a top-bottom layout, or accept the fact that you made a deliberate decision to create a confusing UX.
I also point out that I tried to add affordances to make it easier to use and was stymied by bad browser support getting worse. I haven't updated this CSS in a while, because I haven't felt like I needed to, but the way the browsers display it in 2021 is actively worse than when I wrote it and I'm sorry about that.
I can also at the same time believe that Apple removing scrollbars altogether and not replacing them with some sort of affordance is also a UX crime, whether or not my own decisions that make are worsened because of it were deliberate.
If you're set on that, maybe you could try adding a really unmistakable indicator such as a "Scroll right for more ->" text. I'm not sure if that's good as I'm not a UX/UI designer, but probably better than nothing. Still, as a user, a would prefer something that I'm used to, such as top-down text.
But they don't, so its generally our job to work around that and provide sane usability in light of decisions made by larger browsers.
Still doesn't make horizontal scrolling discoverable or a pleasant UX.
That having been said, you should be able to tune your stylesheets to vend one that gets users single-column text on mobile devices with some elbow grease. Up to you whether it's worth it.
No complaints from here about the mobile UX.
Certain browsers make it completely non-obvious that you have to do so to see more content, and it's no longer "intuitive" UX for most users.
You're trying to sell someone that your idea is right, but having the desktop experience be a bit difficult (and putting it on the end user to deal with it) doesn't really help you in communicating your points. It also makes it harder for them to digest your content, therefore people might just skip over it.
But again, it's a personal blog so all these decisions are up to you and your liking!
It is interesting how many of these comments have fallen into style of substance fallacy over the contents of the arguments themselves, and I am listening to all of this feedback. This current CSS was designed to make 90s kid me happy, primarily on "Edge Classic". It's not aged as well as I would have liked, and I don't know if/when I'll revisit it, but I am listening.
Don't get demoralized. Everyone is boring today. If this was a business or something I'd say ditch it and make your website have Bootstrap or whatever least common denominator thing. It's not, it's your place to express yourself, so don't let wet blankets ruin your site for you.
Here's two other weird sites just to keep up your morale.
https://slimedaughter.com/
http://art.teleportacia.org/olia.html
Sure, but in this case the choice also strongly sacrifices usability. Even on non-MacOS desktop firefox I didn't know there was more to the article before reading the parent comment.
If you want people to read more of the article then perhaps make it easier to find out that there is more of it.
It's been on my backlog for a while to find a good JS replacement but haven't been happy with the ones I've tested: https://github.com/WorldMaker/lcars-moderne/issues/1
Also, if a typographical defect has a name (widows and orphans) can it truly be novel?
The caniuse statistics for CSS native support for widows/orphans correction is much better today than when I last worked on this CSS file: https://caniuse.com/css-widows-orphans
Yes Angular is not great and most people know it. I just see almost all new applications using React/Next/vue
In pure front end developer land Angular is quite behind React in popularity.
Sorry, but I have to correct this every time I see it on here: TypeScript is accommodating to C# developers, but it's equally accommodating to developers who don't want to touch classes with a ten-foot pole (and to everyone in-between). React benefits from it just as much as Angular does, etc.
Angular, Anywhere in US: 25,248
React, Anywhere in US: 29,197
Vue, Anywhere in US: 8,032
Angular, California: 2,658
React, California: 4,643
Vue, California: 1,134
It seems like Angular and React are both very popular, but Angular is a bit less popular in California than elsewhere in the US. Vue is less popular than both, but it is a bit more popular in California than the rest of the US.
*EDIT*: I did it here (and for the most part I mainly agree with the sentiment behind this article):
# Angular is Rotten to the Core
I find Angular an impressive front-end framework for just how badly it is designed, top to bottom, and yet how large of a cult-ish following it has. There exists a weird “everyone knows it” mentality that in practice seems to be entirely an illusion. There is the strange “no one got fired for picking Google” echo of ancient ibm mistakes exacerbated by Google barely dogfooding Angular (and arguably never successfully). There is the awful internal politics of Google that have produced many horror stories from former Angular developers, former open source community contributors, and combinations in between, and an impression that the rabbit hole goes only deeper if you could dig beneath Google NDAs and secrecy.
## Why does anyone use Angular in production?
I’ll start with the sociopolitical weirdness and save the real meaty technical stuff for the end. Let’s think of it like one of those long, mostly useless food blog narratives to air some grievances before the technical equivalent of a recipe.
## “Everyone Knows It”
When we started a greenfield project at my employer (opinions here are mostly mine and not that of my employer and other usual disclaimers apply, of course) I suggested React, as I was comfortable and happy with React in other projects, and even did some prototypes in early testing in React. I was brought on to the project to be “the backend expert”, so I was overruled because “no one knows React” and “everyone knew Angular”. I didn’t know Angular at the time, other than gut instincts from skimming tutorials that it was “Enterprise” and “Bloated” in all of the worst senses of both words, and some hesitation/general “sense of doom” from reading the blogs of Rob Eisenberg (because I had used Durandal successfully in previous lives and Aurelia semi-successfully in more recent projects; I’ll come back to all of this later in this post).
As soon as we started digging into real world usage of the application it became very apparent to me that everyone that claimed they “knew” Angular, simply didn’t. Out of frustration with application performance and modularization needs and so many little problems, I found myself increasingly having to become an expert on Angular, and the more of an Angular expert I’ve become the angrier I’ve become for using Angular at all.
I think there are two big lies that add up to an illusion that “everyone” knows Angular: the Angular template language uses an `.html` file extension, and Angular Dependency Injection at first glance looks “Enterprise” and familiar to Java developers especially. (Sometimes C# developers too.)
The first I think is the biggest illusion and the one that causes so much trouble. React’s jsx/tsx looks “weird” at first, and “no one knows it” without at least some learning curve. Vue and Svelte aren’t liars either and people realize there is a learning curve to learn their `.vue` and `.svelte` templates. Like the much mocked Jurassic Park lines “it’s a Unix system, I know this”, despite the many variations of Unix and the weird ui shown on the screens that wouldn’t have been familiar to anyone, “it’s an html file, I know this” is an amazing misdirection of Angular’s. Angular’s template language is no less a complicated template system like `.vue` or `.svelte` or `.jsx`, but that first impression from junior developers that they know enough html it will be “easy” and they already know it is amazing (and wrong).
Also, I realize that Angular themselves refuse to call it a “template language” and go out of their way to call it a “view engine”. They seem to insist that you could ship the template language’s html to a browser (as Knockout used to do, using only html compatible custom attributes, back in the day...
http://worldmaker.net
Using the LCARS style gets geek points for retro sci-fi, but dang that font color is unreadable.
Angular development is reliable. You know what you're getting and what comes with senior development.
(Ive moved 2 prototype projects that needed to scale from React to Angular).
You get a product built on top of a framework which does 200+ things you never asked for, can’t disable, and whose the complexity of is reliably causing your simple code to crash in ways which are impossible to analyse, debug and explain.
I’ve been burnt a few times on this, and months down the line, my simple CRUD angular apps still have unexplainable, unfixable issues which is destabilising some of our backend systems.
And we can’t fix it. Because nobody has any fucking idea what goes on with Angular internals when shit blows up like that.
And yes, you can rely on that.
I’ll literally take anything not Angular over Angular at this point. At least I should be able to reason about what I’m shipping and fix bugs once reported.
May it die in a fire.
Will this ever end?
Angular is used heavily at my work and we manage to please thousands of users every day, developing in it isn't bad either. I use it for my personal projects too, and yeah so far no problems and I manage to crank out stuff in a pretty decent rate.
It’s literally impossible to write clean code which compiles to clean code with Angular.
Zone locals also allow you to maintain "task-specific" state, for instance allowing you to access the current request being processed without it being passed around. Another use case is having your logger show context information- Frameworks like RoR have done this forever- they show the request ID on each log message that results from processing that request. I don't think there's any good way short of passing the logger around everywhere to pull that off in Javascript short of using Zones.
What it does to Promise and other parts is definitely an annoyance, but the benefits you get for it are a lot. If Zones were a standard part of the JS runtime none of that "patch the world" would be needed, as the JS runtime would support it out the gate. Zone.js was always meant to be a polyfill of the Zone concept on the way to standardization. It is unfortunate that standardization has failed because I think it's a very useful idea and there isn't any real alternative to achieve the same goals.
Is there things wrong with Angular? Yes. Is it my choice of frameworks? No.
But Angular came out years ago, back when jQuery was the defacto standard. And much like how jQuery (and Flash before that) isn't in vogue now (nor should they be), Angular presented a lot of unique ideas about how we could be thinking about building for the web, and for that I'm appreciative.
IIRC, Angular.js was originally built as a prototyping tool for designers. It got popular, and the creators did their best to make it work. It didn't. But it's a lot easier to write negative articles such as "Angular is rotten to the core" than it is to create a javascript framework.
You seem to be confusing Angular.js (≤1.8) with Angular (aka Angular.io, ≥2.0). The latter is an incompatible rewrite of the former.
Angular however, is a totally different beast and I wouldn't touch it with a 10 foot pole.
(Additionally, I feel like if you're going to criticize Angular for being by Google, you can't really be recommending React. Also, not the point, but I think the “No One Got Fired For Picking Google” subheader is a weird take on the original IBM version of the quote.)
That the phrase "to the Core" serves as double entendre here questioning their intent/philosophy behind the existence of the framework was certainly intended to be clickbait, but I thought it clickbait that HN would appreciate because it is technically correct (and as we all know that is the best kind of correct). I appreciate that it was not well received by some and I may have been too clever with it.
I had to work with Angular and I hated it, especially the compilation times and the fact it is very opinionated. But I hate everything front-end that is not Javascript + jQuery. I suspect I would hate React, too. Thanks God I no longer have to touch front-end at work!
For me, as an engineer whose worked across FAANG and YC startups in San Francisco, Angular has had absolutely zero mindshare for at least the past 6-7 years. Every company I know uses React and every engineer I know knows React. So it's interesting and somewhat alien to hear it being treated as the default option.
This is completely wrong. Though I wish it was true, I've used it and I wish I didn't have to.
I actually had a great conversation with a core Angular dev just today where he outlined the whys of some of the issues.
The Angular development team, not including managers, developer relations, etc was described to me as “about half a dozen people”. It’s a very small team with a big task.
I think that Angular+RxJs+NgRx is a great way to build apps. Once you really get the hang of it there’s nothing like structuring your app using DI+directives+Observables. I recently created a drop dead simple, performant, and insanely reusable, intersection observer directive constellation that’s easier to use than any other IO library I’ve seen to date. It was maybe a hundred lines in total.
I submitted my first PR over the weekend. It’s easy to complain about Angular, but, I’d like to see more people who use it show up to help out. Yes, the corporate side of things slowing the community down is annoying.. But with enough external devs the process could evolve into something more decentralized. Maybe? Who knows unless you try.
I love RxJS and so many of my problems with Angular come directly from how it and its ecosystem don't use RxJS well and don't set up developers, especially junior developers, to use RxJS well.
LCARS CSS is nice and original, perhaps you can change the font/contrast to achieve something more readable (just in case here are some ideas https://www.thelcars.com/themes/ )
Reading the HN feedback I did make a note to adjust the body font color: https://github.com/WorldMaker/lcars-moderne/issues/4
Might also play with some of those newer color theme ideas, the Lower Decks inspired ones spark joy for me. (I used a different theme site for some of the colors that was at lcarsdeveloper.com and seems maybe done now. This one seems similar and I'm wondering if they just had to change domain names at some point.)
That said, webpack and jest are bloated messes and easy to break. I'd say just stick to esbuild as your lone dev dependency and get to work writing your framework-less project. Otherwise, take a look at the vanilla Vite template: https://vitejs.dev/guide/#scaffolding-your-first-vite-projec...
If you find that you want a framework (which may be inevitable), give Mithril.js a shot. It's very unopinionated.
These days I tend to only use esbuild. For testing, I use my own homerolled test utility and the built-in Node.js assert module, or uvu.
That's true, so far I've only interacted with these tools in vue-cli-generated projects and the like.
I'm not sure if "framework-less" is the right term even. I'd like to be able whip up quick UIs with a few libraries where needed without too much unnecessary complexity. I find there's little benefit in forcing simple UIs into Vue components, but juggling libraries without npm/yarn is cumbersome, too.
I'll have a look at Vite and Mithril.js, thanks for the pointers!
VueJS is very lightweight and loads almost instantly. It runs on even very old computers well. Native JS will never be able to compete with frameworks because frameworks have the ability to rapidly innovate and try new things without worrying about having to keep them around forever.
IMO the browser should become something like a CPU where it provides the low level components to do anything and the website provides the framework to make it easy.
It doesn’t “feel wasteful” to use C or Python to print hello world when it could have been done in raw ASM.
Maybe webassembly is the thing that you are looking for?
JS has multiple implementations for date interfaces and they are all flawed in ways. Rust decided that date handling should be the job of 3rd party libraries which have the freedom to drop bad ideas and break compatibility for the goal of a constantly improving implementation.
It's not ideal but I don't think it'd be too hard. This would require though a build step which is what you seem to want to avoid.
> In just 4.5kb you get a productive environment with preact and preact-router
https://github.com/preactjs/preact-cli
Edit: On second look, it uses Webpack and Babel, and these days newer tools like ESBuild and Vite are faster and probably lighter.
+1 for esbuild and Vite. Personally, I think esbuild alone is enough for most usecases.