Web Development Simplified with Svelte
objectcomputing.com
objectcomputing.com
The webpack build that the Angular CLI uses internally is completely transparent, you don't have to know Webpack at all. Just do ng build --prod and you have your optimized bundles will all the bell and whistles.
Webpack is even going to be replaced by Bazel but we won't even notice it, all we have to do is ng update and live goes on the next day after the release.
The Angular ecosystem with the Angular CLI is just so stable and complete, with hardly any API changes in years, it's just a joy to work with. The CLI even integrates with Sass and other CSS processors.
You can really focus on the application, and forget tooling. I think the take of Angular on batteries-included tooling & their take on incremental upgrades are such a huge advantage over other ecosystems, AFIK nothing else comes even close.
https://trends.google.com/trends/explore?date=today%205-y&q=...
> > That appears unlikely: https://trends.google.com/trends/explore?date=today%205-y&q=....
> I dont care about fashion too much
Do you see the problem here?
- It is stringly typed. All over the place you're globally registering names as strings (or worse, using strings that implicitly resolve to filenames). You'll write `store.createRecord('mymodel')` instead of just importing things using standard ECMAScript imports.[1] This means static analysis is out the window, which makes it labor-intensive to find usages or do even simple refactors like renames.
- It leans on global state and object mutation way too much, instead of using functional state updating. This was the way older frameworks like Backbone, YUI, etc worked. Web development is moving away from this paradigm, and for good reason.
- Static typing support is non-negotiable in 2019 (and 2015 for that matter, but I digress). Support in Ember is just not there, and I don't see much promise for the future either. React and Angular have had good support for Typescript and/or Flow for a good 5 years now.
- One high point for Ember: the in-browser testing beat the pants off any of the other frameworks. We ended up going with React/Jest/Puppeteer, but this meant we (meaning, I) had to write 150 lines of boilerplate that Ember gives you for free.
Overall working in Ember honestly felt like being transported back in time by 10 years. I guess if you're a solo dev it's easy to whip up a quick demo that seems fine, but you'll hit the wall very quickly where the project becomes write-only. I think it's unlikely a brand new build system, no matter how fancy, can make up for these architectural problems.
[1]: https://guides.emberjs.com/release/getting-started/creating-...
EDIT: I regret taking the time to write this. Should have checked submission history first…
This is a big issue.
> - It leans on global state and object mutation
I dont see this as a problem, it's an implementation details. If the software works well (fast enough) and provides a nice API, I dont care much about the internals.
> - Static typing support is non-negotiable in 2019
Agreed, but I'd like to combine this point with the first.
EDIT: thanks for typing your reply. :)
1- controller/service dependency injection(no more with octane).
2- ember data API(store.createRecord(modelNameString) and serializerFor(modelNameString)). I don't mind it results in less imports and API might change in the future.
3- this.owner.lookup('$abstractionName:$fileName') => I like this one. It removes the need for an extra line of import code and import path could have been very verbose for something far away in dependency tree.
Therefore, I don't think it is a serious issue anymore.
Majority of the ember source code and internal packages are in typescript and there is a good typescript support for app development via addons. As a person who wrote an ember-cli alternative, I can say with confidence that you can build ember apps in typescript. Despite all that, the type analysis performance overhead/cost of typescript compiler today isn't worth the type benefits for really big SPAs yet in my opinion. I think instead those frontend teams should optimize their hiring and mentoring practices until we have a very fast typescript compiler.
Addon/package authors can write their code in typescript and make it work with JS or TS ember application code today.
TLDR for the ones who made weak typescript arguments here against ember.js: Don't be a hypester and claim certain things without making a good research.
On one hand, you can yarn install and ng create and you've got a project.
On the other hand, the largest software company on earth uses it.
In the middle is a wasteland. I've worked with it for years and have been waiting for Google to document to the angular compiler (angular/angular not the angular/angular-cli with a million webpack presets). To this day there remains zero documentation other than source code. https://github.com/angular/angular/issues/29623
I don't know about the newest versions but I have to disagree for Angular 1, the framework was so badly designed and overengineered that my team and I had to constantly check the doc to remember how to write x or y or what were the best practices to do z.
React does less than Angular but it's way more intuitive and straightforward. The doc is a one-time read.
> forget tooling [...] The webpack build that the Angular CLI uses internally is completely transparent [...] nothing else comes even close
React has create-react-app. Vue probably has something similar. Same for Ember. Last time I had to setup a build pipeline myself was like 3 years ago.
Also, you still configure webpack for your React app right?
A much more useful question is whether or not a framework makes it easier (or faster, or better, or something) to write a complex app. In the case of Svelte, all the hard stuff (eg state management, sync'ing data from APIs, etc) is outside of the scope framework. That make Svelte much smaller and simpler, but it makes writing a complex app harder (because you need to glue some other libraries together yourself; the framework isn't doing it for you).
The point is it ain't just a view library, and once you have your own compiler you can get more done.
https://svelte.dev/tutorial/writable-stores
It only took me a few hours to fully appreciate what a tidy solution Svelte's store implementation was.
As far as syncing data from APIs: I am pretty sure that it should be out of scope for _any_ view layer. APIs vary widely, and it wouldn't be appropriate for a view tool (Svelte, React, Vue, etc) to have an opinion. It's really up to the developer, and for the most part (and I may have a controversial opinion here?) should be a pretty simple set of wrappers around `fetch`). Where's Vue or React's API consumption tooling?
Another aspect I have really appreciated is that I have substantially fewer dependencies, since there is more included in Svelte than in React. I tend to only use d3 utility functions (format, scales, etc.) & immer (which I pair with svelte stores to get something kind of Redux-y, which is great for other devs jumping into Svelte from React-land). Fewer dependencies means I'm less likely to encounter awful dependency hell.
Generally, I feel like every time I see a Svelte thread here, there's a lot of random noise, but it's good to listen to the folks who actually use it. There are situations where it makes sense, and situations where it probably doesn't. The main reason why I might not use it is ecosystem friction – a lot of devs I know would prefer to just use what they know, even if it is painful relative to Svelte & friends.
I have been working with svelte for quite some time now, and honestly I can not think of a time where it did not make sense to use it. At its most basic form, its compiles down to vanilla javascript with a small footprint and offers a tidy workspace when working with html/css/es6.
But I have a serious question: Why the web dev is still a relevant thing? Don't get me wrong, I won't argue that the web is dead and all should move into AI or VR or something but I am under the impression that most of the problems that can be solved through a Web UI are mostly solved. Sure people come up with interesting business ideas all the time but they usually don't require innovative Web UI tech and can be built just fine with 10-year-old frameworks.
How is the web world doing? Why would anyone keep creating cool new frameworks?
In fact reactjs found an even simpler programming model and is leading with this new approach ... it is called hooks.
Vuejs is copying the same concept and in fact wanted to dump it’s old way to fully embrace react hooks style programming but that angered the vuejs community.
I know some people have a thing for arcane programming (for a lack of better word), but in my opinion it just makes code harder to write, understand, and even statically analyse.
Not to mention, the official lining for hooks leaves a lot to be desired for, especially because some internal React return values are treated magically by the linter (useState, useReducer to name a few) when it comes to hook dependency management.
https://stackoverflow.com/questions/53332321/react-hook-warn...
I love React and my first experience with hooks has been mostly positive, but how is it that something as simple as data fetching is not completely sorted out by now?
It sounds abhorrent!
I think the current best answer is https://github.com/n1ru4l/use-async-effect
But as noted by your SO question, Suspense for data fetching is what we're waiting for. It was originally scheduled to be released the middle of this year but was delayed. https://reactjs.org/blog/2019/08/08/react-v16.9.0.html#an-up...
While there was some backlash to the initial Hooks-inspired style in Vue, they went back to the drawing board and came up with a better way to explain it to the community that has gotten a much better response. I also find Vue's API for "hooks" much more intuitive/readable than React hooks, because it maps pretty well to the old style of writing code.
I don't have anything against hooks except the API. There is no way for someone who isn't intimate with the ecosystem to understand the difference between these:
useEffect(() => {
document.title = foo;
}, [foo]);
useEffect(() => {
document.title = foo;
});
useEffect(() => {
document.title = foo;
}, []);
That’s a weird question because the answer is so obvious. There’s massive innovation in front end development because billlions of users are using ever more sophisticated applications created by millions of programmers backed by virtually infinite money. Of course people keep looking for and finding better ways to do things. Do you think that process has come to an end?
You must be trolling.
For people not expert or completely current in web development - especially in the context of a field not unknown for jumping on every shiny new magic bullet - it's quite reasonable to ask what major problems are arising that need a new framework learning every week.
The answer is simple: someone read a new chapter in the Gang of Four's book.
That said, this is 15 years of time and the innovations came as browsers got better, IE died off but all these JS frameworks were always about making the codebase nicer.
Is there anything new for the users here? If not, why keep spawning new frameworks? Do these frameworks make anything better for the developers? In my experience, the JS world is a giant mess mostly because of the excess of frameworks that do the same things essentially.
That's why I felt burned out of web dev. I found out that all these frameworks that are supposed to make something easier to do are only making problems infinitely complex.
There's nothing new that you couldn't have done with 10 years old frameworks but now you need specialized knowledge on tons of tools.
People doing a lot of web development wanted to make their lives easier but found the way other frameworks are doing it to be really convoluted. So they created their own framework which makes perfect sense to them.
As a developer getting into this, just pick any well-maintained framework and you should be able to get your job done.
There's no real innovation on the web. As another commenter pointed out, all the "innovation" is around tools. And even those innovations are meh at best.
Web has been busy reinventing things that desktop programming has had probably for decades, and what mobile development has had for years. And that's when we consider tools only.
On the app/client side the situation is even more bleak and dire. We get a 100th store implementation. A 1000th drag and drop implementation. A 10000th file upload manager. A 100000th state manager. A...
The "ever more sophisticated" applications can barely scratch the surface of native apps. And the actual more sophisticated apps like Figma are busy re-inventing and re-building the past 20 years of desktop UIs from scratch [1].
It's not innovation. It's a hamster wheel race.
[1] https://www.figma.com/blog/building-a-professional-design-to...
--- quote ---
Pulling this off was really hard; we’ve basically ended up building a browser inside a browser.
The reason this is hard is because the web wasn’t designed as a general-purpose computing platform.
--- end quote ---
That depends on your definition of 'just fine'. I can develop a lot faster with fewer bugs today using React than I did using jQuery a decade ago. That means the apps I build cost less (or more commonly my clients get more functionality for their money). They seem think that's a really big improvement.
Slower, bundling sizes, hard to maintain, doesn't manage state, complexity is messy but never few bugs or slower to work with or different to understand.
I didn't say jQuery created more bugs. I said I write jQuery code that has more bugs. It's not jQuery's fault at all. What it means is that the way I work is better suited to writing things with React because React is closer to the way I think.
If jQuery were just as fast to work with and had the same bug count, it wouldn't be harder to maintain. It takes time to work out what jQuery code is doing which means it takes longer to modify the code. That difference in readability also leads to a higher chance of bugs due to misunderstanding something.
The one case where this does not hold true is when your site only needs a few click handlers or something else that is simple (and in those cases, you should probably be using jQuery -- or just the normal DOM now that compatibility is less of an issue). But that is not what modern JS app devs deal with.
The entire reason for using Handlebars on top of jQuery was to move toward declarative programming in order to reduce bugs and speed up development time. React was more declarative, functional, and native (use JS builtins instead of embedding a turing-complete DSL) along with also being massively faster. React was marketed more on performance than anything else at first, but that was mostly because Handlebars and backbone had already solved the worst parts of jQuery in large codebases -- procedural UI and holding state in the DOM.
If you're a very smart dev at one of the biggest tech companies in the world, getting paid a quarter of a million dollars per year working on a niche team that handles a small section of a single product, you will probably get bored pretty quickly and start focusing on the how. It's a shame really; some of the greatest minds of our generation are being put into rooms to work on animations for buttons on virtual DVD cases and Photo Books.
The silver lining is all these tools are given away for free. The tools so great and their corporate creators so cool that you can just have them! A cynical reading is that they are only given away because the competition can derive no value from them... In fact, forcing your competitors to retrain every 6 months when you release another major version that breaks all existing projects will only slow them down and fill your coffers! The new whatsapp will never get off the ground, because the devs were too busy rewriting babel files and the money ran out... you just saved a cool $18bn.
If these frameworks were really the key to anyone's successful business you would not know that they exist.
I have no idea how you go from "knowing what you're doing" to "unsatisfying"
https://www.joelonsoftware.com/2002/01/06/fire-and-motion/
As a sort of side note, amusingly, Microsoft is rarely included in the FANG-style acronyms. There's a reason for that, Microsoft is the granddaddy of FANGs, from a strategy perspective :-)
I propose a new law: "Every technical discussion in Hacker News is exhausted when stock market or cryptocurrencies are mentioned".
why thank you sir!
WebAssembly looks amazing. Much faster web applications. Then you have stuff like Hudini which will let you create custom DOM elements and allow open source web frameworks to provide really sane DOM element offerings.
WebAssembly has the largest potential. Just look at Microsofts Blazor project. If you do any .NET Blazor looks even more amazing! Then Microsoft also has React Native for Windows.
If it's for performance, the community as a whole seems to have failed entirely. Svelte looks like an exception, sure, but websites generally use more CPU time, more RAM, more bandwidth than they did 10 years ago even when they don't do anything significantly different, functionally.
The person you responded to didn't say "Vue isn't marginally popular", they said
> I doubt its uptake got anywhere near ReactJS...
and it didn't. You can read about that here -
https://hackernoon.com/angular-vs-react-vs-vue-which-is-the-...
Don't stop reading at the stack overflow opinion poll graph though because Google Trends and NPM trends tell a significantly different story.
As long as we've thought enough about the design (db schema, service responsibility boundaries, etc etc) we can get a working microservice up in hours to a few days.
The web world is the wild west (and I kinda like it) but I don't think we're even close to React being surpassed by Vue.
There was a lot of talk about stars on github for Vue but I'm not sure people star what they work with every day, or at least that it means much relative to other projects.
Is it though?
- react weekly downloads 5,672,972
- vue weekly downloads 1,090,292
Now, I know how opinionated we all are and how the best thing is what we already know, but after working with Vue and React extensively (the company I currently work for uses Vue/TS for a huge app, think over 1000+ .vue files) the particularity about svelte is that you hardly notice that you are using it!
Vue has the Vue way and React has prophet Abramov to light the way, but svelte is completely out of your way. You wanna follow MVC? go ahead, DDD? why not?
I have learned more HTML5 and CSS3 using svelte than any of the other frameworks because it encourages you to use it, because the wheel has been invented already.
Again, everybody has their opinion but for me svelte is the framework that has the least magic of all, the you can set it up without a incredibly complicated webpack config or obscure 'create-react-app' that makes it very easy to start a project but you don't really know what's happening underneath.
And it just HTML and probably 5 or 6 extra JS things like $: and a different use for export in a component.
If you are already religious about your framework, good for you, but if you are open to ideas, take a look a svelte!
The older I get as a developer the more I realize that simple is not easy to accomplish. That's probably why I like svelte :)
1. components (creating re-usable UI parts (i.e. components) that combine data and their rendering)
2. reactivity - re-rendering UI when data changes.
Web Components only solve one of those problems. And arguably not as well.
This really doesn't make any sense. Not learning how to effectively use HTML and CSS doesn't have anything to do with what frontend framework you're using.
But if svelte can do both, eliminate the boilerplate and at the same time minimize the cognitive burden of having to work with DOM, then im interested. But i rarely have noticed that React makes me angry the way it used to. So do i want to switch, like the stereotypical frontend hipster, to another hype framework and code the next customer app with it? I'll need a lot more convincing first
If you're going to go this far, why not use Marko.js and get SSR streaming built in?
Under the "Why Consider Svelte?" it only mentions bundle size and performance.
Small projects / websites = use the DOM
SPAs = use React
Why would you use Svelte for small websites when it requires JS?
All of my "websites" are made w/ pure HTML/CSS/JS and the JS is optional.
All of my "apps" are made w/ React (Web, Electron) & React Native (Windows, iOS, Android)
I'm working on a stack that sets all this up for you so you can get started on deploying for every platform. I already use it in production.
Don't cheat yourself, use React and take advantage of the progress and ecosystem. If you don't need that, then use vanilla.
Though, perhaps you mean the larger React ecosystem. But still, what patterns are you talking about? TEA/Redux? There's no reason why you can't use the same patterns with Svelte.
Svelte gives you the exact same tools. I've been building React-based applications for years now and have been using Svelte for some projects on the side and in my opinion both are decent tools. Some of the Svelte "sugar" is easily replicated in React, it's just that React doesn't provide those out of the box; on the other hand, Svelte has some "gotchas" that don't appear in React.
I hear that this is something they are looking into adding support for
If your most pressing issue is removing bugs from managing state, you will pass it by.
Where I think Svelte falls a bit short (given its flavor of comprehensiveness) is that while it concerns itself with strictly client-side things like in-memory state and animations, it offers nothing for sorta-server-related things like data fetching or routing, and you're left to find libraries to fill the gaps (similar to how you would in React). I feel like the bigger frameworks are up to something DX-wise, with providing more integrated/idiomatic ways of interfacing between subsystems (e.g. getting a data fetching API to talk to a state store, or making routing aware of them). Gluing subsystems from different libraries adds weight to application space code (see e.g. react-redux vs Vue) and at some point this starts mattering (usually during maintenance phase). Maybe Svelte's middle ground is your cup of tea, but obviously YMMV a lot.
For me personally, it has one other showstopper (its file naming convention is not compatible w/ Bazel)
Something that most frameworks struggle with, IMHO, is that they don't consider how coupled network is to the system and when you need to do something like bundle-specific translations in an SSR context, it's very hard to do it in a generic way without touching half a dozen unrelated parts of an app (meaning librarizing concerns that cross-cut across network boundaries is difficult).
Do you think mithril will solve these issues or is a good alternative?
Mithril solves all those issues well except animations, where it's just OK.
Interestingly, even though the Mithril community seems to be a home to people who dislike JSX, Mithril supports it better than React does. You can copy and paste HTML into JSX with Mithril; all the attributes line up. Also Mithril doesn't try to improve elements like <select> and <textarea>; it's all standard.
In personal projects I use Mithril. For medium to large organizations I recommend React. That's because Mithril does everything better than React except for maintaining backward compatibility and attracting large numbers of job candidates.
Mithril fits in a similar camp as Svelte, and it does offer APIs for HTTP requests and routing out of the box. I've worked on projects before where I literally only had Mithril as a sole dependency (and this was with supporting IE10).
Fusion.js solves a lot of complexity-at-scale problems but it does so at a trade-off of not being nearly as geared towards standards tracking as systems like Svelte and Mithril.
The obvious advantage of not including these kinds of things in the library is that it makes less assumptions about the data and communication model. Maybe my data source is a Websocket, a REST API, a GraphQL API, or some Electron IPC messages. Ideally, in my view, the rendering library doesn't care. It shouldn't have to understand all these things to render my view, and it definitely shouldn't assume any single one or two of them.
Svelte has more often "magic" stuff, but the good thing is the magic is simple, and it easy to understand (especially since you can easily look at the compiled output, if you want to double check)
One of the primary directives in Svelte is that it all has to be valid HTML so that the tooling can simply treat Svelte like HTML for syntax highlighting. Some of the repurposing is explicitly because of that directive.
So I googled, found the Svelte homepage, and I'm still none the wiser as to why it might be an easy intro to web development.
Honestly, if Svelte is as easy as you suggest to get your head around, somebody needs to work on the presentation of that.
- smaller (it compiles your app, and doesn't include itself in the results)
- faster (no virtual DOM, the data to elements are mapped at compile time)
- simpler - `age = 30` no boring state management.
You're right about the web page - I wanted them to drop 'Cybernetically enhanced web apps' for 'smaller faster simpler' - there was a GitHub issue for it: https://github.com/sveltejs/svelte/issues/3269
If I was hiring a JS dev, and someone _only_ had svelte on their CV, I'd be a bit reluctant to hire them, only because the svelte compiler hides a lot of JS warts (which I think people should be aware of).
My experience thus far is that if you don't have at least a base-level understanding of JS you really can't use Svelte to its fullest. I can back up that intuition by having observed the svelte support channel on discord, where many of the questions really wind up being questions about javascript rather than Svelte.
What do you feel Svelte is doing that hides "warts"?
Hacky stuff tends to turn me off from a tech. (I consider all my Vue work to be instant tech debt, because I know I will be replacing it down the road...)
> Is there a router?
> You can use any router lib you want. A lot of people use page.js. There's also navaid, which is very similar. If you prefer a declarative HTML approach, there's svero and svelte-routing.
> If you need hash-based routing on the client side, check out svelte-spa-router, or abstract-state-router, a mature router for business software.
> For an official solution, there's nothing that's simply a routing library. There is, however, the official Sapper framework, a Next.js-style application framework built on Svelte, which includes its own filesystem-based routing.
I don't like handling of "undefined" and "null" values in properties[1]. It would also be nice to have optional properties so that warnings wouldn't get emitted to JS console. Also, someone should investigate iOS bugs[2]. It would be bad if someone made complex site in Svelte+Sapper and only later discovered it lags on iOS.
Overall performance is okay, but it's visible to a naked eye that Svelte parts render later than the rest of the website.
All in all, I would recommend giving Svelte devs few more months before moving to it. But definitely keep an eye on it, it has great ergonomics (maybe except for styling subcomponents, but some say it's a code smell anyway).
[0] assuming you set output { format: "iife", name: "App" } in rollup.config.js, imported bundle.js in the original file, and put export { Foo } in main.js
[1] https://svelte.dev/repl/f1f2bf4c50cf4a75ba6ea38c3390af5b?ver...
[0] https://svelte.dev/docs#1_export_creates_a_component_prop
1. If you want to bind a property it needs to be declared. This is the method of least surprise.
2. I've been running three Svelte sites in production for more than a year now, and 80% of our traffic is iOS. The sites work fine, it's the tutorials specifically, probably because of the embedded REPLs which have an iOS issue.
3. You claim that the Svelte code runs later than the server-generated HTML. This makes sense, since the DOM from Svelte components is built using Javascript. If you wanted to generate Svelte code on the server-side so that it renders at the same time, you would use { ssr: true } in your rollup config and generate code for both server and client side.
4. Not sure what the notion of lag is or where it comes from, Svelte outperforms everything else (when I last checked benchmarks), and is likely to, since it has the immediate advantage of not requiring a client-side runtime to download before it starts execution.
1. I just missed the part of documentation that talks about optional properties. And with undefined and null issue, it's a bit surprising that two-way bindings behave differently that 1-way. Passing null or undefined is convenient when an API gives you such values and they represent empty there.
2. Ok. What I feared is that the tutorial would turn out not to be bugged, and Svelte would be a bad choice for CPU-intensive SPAs. Thanks for reassuring me that's not the case. I'd still love to see the fix for the tutorial bug (because at the first glance, there isn't anything that screams "wrong!" in its code).
3. Yup. I just wanted to point out it's noticeable if you look for it. I will look into SSR later.
4. Same as in point 2.
BTW I just wasted 2 hours fighting with bind:group[0][1]. This issue is an example of what I meant by saying that people may want to wait before jumping on Svelte.
[0] https://github.com/sveltejs/svelte/issues/2308
[1] https://svelte.dev/repl/efbe52272558468397b66e46fa906561?ver...
https://github.com/sveltejs/svelte/issues/1639
Still I'm curious.
Typescript and RxJS (or MobX) with Svelte as the afterthought (https://michel.codes/blogs/ui-as-an-afterthought) would be a nice combo.
Obviously Svelte is a JS to JS transformative compiler - you need to make a TS to JS transformative compiler.
I'm hacking on my next app using TypeScript on the backend (particularly around the data layer) and JS/Svelte on the frontend. I would like TS on Svelte, but the rest of Svelte is compelling enough I'd still use it over older tech like React.
Internally Svelte uses TS though, the author claims to love TS also! It just does not mix very well with Svelte.
Stencil.js and lit-element are better picks in this regard IIRC.
GraphQL sucks too. Good luck setting up caching. For instance, hey we forgot caching is important, now that the architecture doesn't allow for it since it uses a single api endpoint... the talked about solution is to use localStorage or sessionStorage. JS is a huge noobfest and those that think React is the answer to everything, probably haven't been in this game long enough.
I have no doubt there is tons of awful react code out there written by noobs but the same can be said for practically any software engineering endeavor.
I'll concede that it takes time + effort to understand how to best use react but it's merely a tool and you need experience and insight to understand how best to use your tools. I try to use as little state as possible and use functional components everywhere I can. Hooks have been a big help.
I agree about having reservations with GraphQL, it doesn't seem ready for primetime to me although I'm keeping a close eye on it because I like the underlying concept.
JS is a "huge noobfest" imo because webdev is so accessible and prevalent. But today's noobs are tomorrow's professionals ;) Typescript has been a very welcome development to encourage better dev practices.
I'm with you mostly. When I started React close to 5 years ago it was PAINFUL. Coming from mostly jQuery (single library and I'm on my way) to trying to figure out gulp, bower, webpack, babel, etc. The tooling has much improved with the release of `create-react-app`. I can't exactly say the tooling has become better as much as it has been hidden away and the defaults are mostly ideal. Yesterday I had a huge headache trying to figure out why my treeshaking wasn't working (it was bundling 1.5mb of icons into my app). Turns out I was using an old version of `react-scripts` and with it an older webpack which I may have noticed sooner had I hand-built the tooling like the old days of React.
It has become impressively complex with all of the moving parts that are required for a React app these days. Webpack alone is not for the faint of heart with all of the configuration and babel-hell that code (and other files) has to flow through. Without `create-react-app`, I would probably have left React long ago, which would be disappointing because I enjoy the syntax, hooks, readability. I've tried Angular and absolutely hated it, perhaps Svelte would be interesting to me.
Svelte provides runtime warnings for accessibility issues. For example, <img> elements that have no alt attribute are flagged.
But hey, that Svelte is providing these warning is great for accessibility!
I'm asking because it's not easy convincing a client that alt="" is ok. They've read so many times "also have a value for alt-=. This is especially true of clients who are SEO-centric. It seems to me there should be an easy and obvious way have a decorative image with a non-blank alt=.
I guess the question is if SEO crawlers still read alt text for images marked as aria-hidden="true" or not. I have no idea on this one, but I'm very curious about it.
I've been pushing the folks I work with to consider SEO as a second-class citizen within alt text. If you can reasonably use a keyword in a natural, useful way, definitely use it. Otherwise, from what I can tell, an image's alt text doesn't seem to have any greater SEO value than the rest of the content on the page. Write better on-page content with better keyword use, with alt text being informative extra content.
And clarification on when alt text is needed: 1) if the image contains informative content that adds to the surrounding content, but also 2) a linked image where the image is the ONLY thing within the link, in which case the alt text should describe the destination of the link, not the contents of the image. I just recently learned this, but it makes sense when you think about it.
Yeah. Good stuff. Thx.
p.s. Best I can tell most images are decorative. That is, they are there for the visual appeal, to create "white space", etc. It's fairly rarely they actually contain content. Of course, there are exceptions, but in general.
It can be frustrating to sit in meetings where people go back and forth about this stuff. But at the end of it all, any meeting where people are constructively discussing accessibility is a win for me.
The nice thing about Svelte isn't necessarily the syntax. It's the fact that out of the box it builds without me having to learn how to build it. That and the small bundle sizes and single file components sealed the deal for me.