The state and future of web dev: your vision, wishes and celebrations

Phoenix Forum Chat / Discussions
,
1

Curious to know about your ideas about (1) where web development should be headed to and why, (2) the shortcoming of the current state of web development and (3) what the most important recent developments are.

4 Likes
2

One thing I have noticed is that the web dev community is very actively creating new technologies (e.g. frameworks and libraries) on the one hand but also many developers are frustrated on the other hand.

I could have given many examples, so this here is a somewhat random pick, but to illustrate the frustration:

Answer on Quora to: Why do many programmers hate web development? by Forrest Barnes https://www.quora.com/Why-do-many-programmers-hate-web-development/answer/Forrest-Barnes-1?ch=15&oid=106440654&share=b1ab3284&srid=hIGOck&target_type=answer.

This by no means necessarily represents all or even a majority of developers, but I wonder what can and will be done to improve the mentioned concerns. Security, cross platform support and dependency on JavaScript, were mentioned, for example.

I’m excited about web dev but I find myself often having to be very careful with what I do and do not put my time into learning and using. What are the must-haves? What are the nice-to-haves. What is just hype. This process does bring me a lot of knowledge, but I do wish there was a bit more of solid ground to stand on. Not even sure what that ‘solid ground’ could be. Maybe better fundamental web standards (browser APIs, e.g.) with great cross browser support? Or maybe tooling that ticks all developers’ boxes, so they can focus on design regardless of the app that needs to be made more: channels, state syncing, offline support, presence, page transitions, performance, etc. The former seems too good to come true, the latter I have not found yet – but from what I understand plenty web devs have eventually found some set of tools they are sufficiently happy with and that they can use for pretty much any design problem.

3 Likes
3

I personally hate javascript with passion. For me it is a very poorly designed programming language that outgrew its capabilities long ago.

I hate its garbage ecosystem where 95% of the public libraries are either a few lines of code, spinoff of existing libraries, libraries that try to reinvent the wheel, frameworks that have no place in this ecosystem and don’t get me started on the security issues with all of those libraries, people tried to push this language into everything they do, for no apparent reason.

In addition to this, I hate most of its community, a lot of poor questions and answers tagged this worked for me or try this with pieces of code whacked together in a hurry.

7 Likes
4

This happens everywhere and also in disciplines outside of programming. You will always have people not taking the time to learn things properly but still wanting an answer “now!”.

5

I hope the world will turn away from JS and its all packages which make Chrome consuming 99% of resources giving almost nothing in revenge.

6

The trend seems the opposite. JavaScript becoming more and more prevalent. I guess partly because it can by used to build servers now also.

1 Like
7

Looking forward to see where this will be heading


3 Likes
8

The fact that it can does not mean that it should, and many JS devs are waking up that reality as well by begrudgingly adoping TypeScript. I say “begrudgingly” because I hear the experience is far from ideal but still provides more visibility on the development process with typing akin to what we have with Dialyzer in the BEAM ecosystem.

People are attracted to being able to “build a service in 15 minutes” and will ignore any and all future issues with that cobbled-together code if it means they can skip a few steps before. I’ve come to accept this is a baseline Homo Sapiens trait: we want the reward now and screw any and all consequences (and they always arrive at one point).

This is very closely matching my long experience as a commercial programmer as well: people just quickly mash something together, and 6 months later they are no longer employed in the company and now it’s somebody else’s problem. I’d boldly claim that 95% of commercial programming everywhere, in all areas, in all languages is like that.

That something is popular and widespread (JS / Python) speaks almost nothing of its quality. It speaks more about the subconscious appeal of the thing. You’d gasp if you heard the insane contractor prices of the Python consultants I knew. They were hired to make a huge codebase workable and extensible by future devs and we’re talking anywhere from 2000 to 3000 EUR a day. Now please tell me how “empowering” JS / Python are. :003:

They “empower” students (or amateur devs) to make the lives of professional programmers much harder down the road. That’s their “power”. :person_shrugging:

8 Likes
9

New JavaScript frameworks feel like EV motor vehicles to me.

In India, companies are launching EV bikes and scooters, left and right, to get early movers advantage.

However the fact that our climate causes the lithium battery to catch fire, or early to market means build quality of materials and ergonomics take a hit, is overlooked.

It’s like they have skipped all the existing design paradigms, like using Trellis or Twin Down Tubular frame, straight to a cobbled together frame, just because they think they have winning formula by just slapping together a motor onto the wheel and calling it a day.

Tesla cars seem to have the same problem, sure it can drive to you from a parked position, but will it survive a crash in Global NCAP, will it last as long as another vehicle like Japanese Machines.

Expectations:

  1. I want web dev to have tools, that is as precise as Japanese Precision Machining.
  2. I want to be able to build sites that are as durable as Nokia phone.
  3. And something that can outlast our life span, like a Japanese built motorcycle or a Japanese person. :sweat_smile:

What we get!!

New meta framework for every framework. :sweat_smile:

And this gem:

1 Like
10

A lot of hating on JavaScript in this thread, and I partially share the sentiment, but it is not going to change the fact that it’s a runtime available on virtually all devices in people’s pockets, and all PCs/Macs via browsers, allowing for our code to run on these devices without the need to install anything. Just visit a URL and the code runs.

There is also a value of having a single stack, at least doing the rendering on the server and on the client: the same group of web developers are able to work on the “front-end” of the app this way, and it’s often very specialized group of people who understand how the browser works very well, how JS and CSS work but they may not be very into SQL and databases and long running server processes. Also, importantly: the other way around is also true. A lot of hating on browsers/JS comes from not understanding it.

I think the way forward is something like React Server Components, where JS executes on the server, gets fed the initial data, skipping the APIs or not completely (you can just hand over the data from Phoenix), that renders the page, then hands over execution of interactive components to the client seamlessly. I have been playing with Next.js and trying to marry it with Phoenix, and it’s doable. Not full success there yet but it can be done to use it as a “front-end layer” for Phoenix, or, anything else for that matter.

I don’t think we can and will escape JavaScript, even if you look at the fancy LiveView projects they have to use Hooks, and often quite heavy to accomplish their tasks.

4 Likes
11

In one my company’s past project we just used TypeScript without NPM to spice up our server rendered pages. I think most JavaScript problems why people actually hate are package management issues and lack of standard libraries. Language has it’s quirks and other languages do as well but when you put TypeScript top of it’s fine and package management etc. isn’t language’s fault.

I think you are correct that it’s very hard to escape JavaScript because wasn’t doesn’t have same level of access to APIs. Also problem I see with WASM is that it will split the ecosystem into multiple languages. It will be harder to find things and I’m 100% sure after dabbling very little bit with Rust that language won’t be the language UI devs will use for WASM. I think it will take at least another 10 years until WASM it’s even a viable alternative with speed it’s going. Plus you would need UI frameworks for WASM language.

3 Likes
12

Agree on everything. Plus, things like mentioned building phase are not strictly necessary anymore: you can build pages/apps in JavaScript nowadays and rely on native modules support. Of course with TypeScript it’s a bit different as you need to transpile it to JavaScript, but essentially all computers out there that have modern browser out there are ready to use development environment, with debugger, profiler, development tools you need to start dabbling in programming and that’s a value on it’s own!

13

Back then we used .NET and .NET has Microsoft library called Microsoft.TypeScript.MsBuild that supports compiling TypeScript files directly without NPM so it was pretty easy with that.

1 Like
14

I think TypeScript is Microsoft’s creation too, right?

15

Yes same person Anders Hejlsberg who created C#

1 Like
16

I’m glad to see movement in the browser API space. Looking forward to view transitions. GitHub - WICG/view-transitions

New great browser capabilities are a absolute win for web dev, I’d say.

Was a bit surprised it didn’t exist yet, when I first started looking for something like it
 But I appreciate the work being done.

1 Like
17

Yeah. I was about to say to @hubertlepicki: it’s obviously unrealistic to wish that JS just disappeared tomorrow. Most people’s problem with JS is how it’s practiced; its ecosystem is an ever shifting sand. I remember trying super hard to get into JS years ago; the entire project was always just one npm and/or node patch version (e.g. 1.6.10 → 1.6.11) upgrade away from not working or getting a ton of new warnings. Same with webpack; suddenly half your config doesn’t work after the tool got upgraded.

It’s hard to be productive – or even want to work at all – in such conditions.

And before you say “just use X and Y, do packaging using Z, and transpile using ABC”, I am not contesting that there are productive combos of tools. The problem is the community agreeing upon best practices and promoting them – something that the JS community is famously bad at.

And then you get to the best part: analysis paralysis because nowadays there are so many tools that if you’re new you’d need to spend weeks just researching and trying stuff before settling on your own unique blend of JS development process. Which, surprise surprise, you won’t be able to [readily] Google for because you have 5 tools interacting in unique ways.

As a guy who’s paid handsomely to be highly productive this gives me huge anxiety. Surely you can see how 50-70% of the time spent on picking tools and then also pampering them constantly, is a problem. I am OK with going deep and taming my setup but JS never made me feel like my knowledge will have any staying power.

6 Likes
18

I agree with you on all accounts. One thing to add, is that I am seeing the rise of the “JavaScript frameworks” nowadays, that largely - or completely abstract away the building process, and to an extent - package management from the user. Excuse me to give you the same example again, but in things like Next.js/Nuxt.js the user doesn’t see the webpack.config.js, for all I know they could switch to an entirely different build system, and we (optimistically) wouldn’t notice it. It’s similar to Rails or Phoenix this way: the developer has to know the conventions, the usage, but it’s the framework’s job to build the app. This also allows you to avoid the “every developer sets it up differently” problem. It’s something Ruby and Elixir figured out years ago, but JavaScript only now shifts toward, but does indeed nevertheless.

2 Likes
19

Really good to know, thank you. Very nice that JS is finally moving in that direction.

20

Indeed. It’s somewhat a pitty that when you google “JavaScript frameworks” you will get results like Vue.js, Angular.js or React. They’re not really frameworks, they miss the frame altogether that binds it all. In my mind Framework is like Rails, Phoenix, Laravel or Spring, where developer code is the focus of the programmer, and not setting up build system or figuring out a different and original directory structure. React/Angular/Vue etc. these are just libraries, not frameworks at all.

1 Like