Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I see a lot of Javascript frameworks created recently since I've been learning web development (http://www.infoq.com/research/javascript-frameworks-2015). Do you know what kind of knowledge you need to know in order to create a Javascript framework in particular or any framework in general?
Creating a JS (or any other kind of) framework isn't something done easily, but some of the steps include:
Find a niche where no framework exists yet or doesn't cover a specific use-case, and where you have good knowledge of the problem space
Design and implement an easy to use (and, if required, future-proof) API
Publish it, e.g., on GitHub and advocate for it with a website or through blog posts
Maintain it
Hence, you'll need to know how to design good APIs, reasonable JS knowledge to build them and patience.
Note: while the initial fun starts with building out something, releasing and maintaining an actual framework is far more complex and requires time and effort - especially to build a community and once these users start requesting additional features, or your initial design considerations fall short of the new use-cases imposed by real-world usage. You can always build something and publish it to NPM, but be aware that maintaining a project in the open source community involves more than "writing code", and deprecating or deleting a framework/package can yield surprising results.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Recently I started learning web development. I tried to read the HTML and CSS codes of some famous websites in my web browser. But I observed that they intentionally mess everything such as changing the real names of the bootstrap classes, while looking at the design architecture and page layout anyone could guess what kinds of technologies are used.
What would be the possible reasons?
I think it's not about security because any average programmer can still know everything about their front-end technologies if he puts some efforts.
There are multiple reasons.
Some companies, indeed, try to obfuscate some of all of the code to hinder some of the attacks. That is not 100% proof, of course, because a sophisticated actor can still reverse engineer almost any code that's out in the open.
However, most of the times it's simply how modern frontend development is done nowadays. The trend has been moving more and more towards using various build, bundle, code-minification and packaging tools. Like Webpack, for example.
What you see simply is a result of source code being processed packaged for optimal delivery and running in the browser.
The days when we could view web-page source and inspect pure HTML/JS/CSS, as it was written by the original developer, are long gone.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I have experience in games development(C/C++/C#) but recently I started writing automated test and I wanted to learn some backend stuff. I'm writin platform for automated backups, making builds from git repo and testing. I decide to write server in Node.js with PostgreSQL. I have 0 experience in web development. Never ever have I use a database or javascript. I think homemade project like that will be a good starting point. I want to ask two questions. First: Which code design patter will be the best for learning Node.js? Second - Could you please tell me if this pre-alpha database concept is currently good or should I change it?database
No one will be able to answer your questions as you asked them but I'll try to give you few hints. First of all PostgreSQL is a very good relational database so if you need a relational database then it's a good choice but there are other types of databases like graph databases, document databases, key-value stores etc. that you should also consider when designing your architecture. For anything complex it is common to use more than one database.
It's hard to recommend any code design pattern. I can only recommend starting from a good style guide like the one from Airbnb and enforcing it with a linter - see: http://airbnb.io/javascript/ - and following a style guide writing your backend in a style supported and recommended by a given framework that you're going to use. Some examples: Express, Hapi, Restify, LoopBack, Serverless, Seneca, Koa, Sails, etc. Google all of them and read examples to see which one feels best suited for your needs.
Links to more frameworks to consider:
http://nodeframework.com/
https://github.com/sindresorhus/awesome-nodejs
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Meteor was supposed to revolutionize web development on node a few years back, making it easy to write compelling reactive applications. I'm not very familiar with the history of the platform, but I know that since last year most of the development effort has withdrawn and gone to work on other projects. I'm trying to decide on a framework for my next application, so I wonder if Meteor is still a viable choice for the purpose, as opposed to just using plain node+react/angular/etc. These are the pros and cons I've experienced so far:
Pros:
Easy to prototype
Javascript everywhere
Publication/Subscription model is kind of neat
Reactive
Cons:
Performance is hard to get right using pub/sub
Framework updates don't come as often as they used to
Locks you in with no escape
Less people write Meteor packages recently
Adds a lot of overhead
Your question is likely to get closed, so I'll chime in here super quickly:
I've been using Meteor for the past three years or so, and I've finally decided to stop using it in favor of the following stack:
Client-side
React
Apollo
AWS Cognito (for user auth)
Server-side
Express
GraphQL (Apollo implementation)
I'm moving for some of the reasons you list, mostly overhead and adding too much weight to apps that could be a lot more lightweight and simple. I'm even thinking of going serverless and just having my GraphQL endpoint powered by Lambda.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have a question about the design of a web application with JavaScript: Should a web application be designed to work without JavaScript, and then later add JavaScript for users that have it? Or should I design a web application with JavaScript in mind and then add fallback functionality for user that do not have JavaScript.
I hope this question makes sense. Let me know if you need me to clarify something.
Thanks.
The terms, that describe what you are looking for are "Progressive Enhancement" and "Graceful Degradation".
Here is good article describing what you already have in your question in more detail:
A List Apart: Understanding Progressive Enhancement
An article that could help you on your decision:
Dev.Opera: Graceful degradation versus progressive enhancement (The named reasons are still valid, despite the fact that the article is marked as outdated)
I favor progressive enhancement in most cases, since it is more accessible when it comes to different output devices, software and the capabilities of the user using that website.
Answers like "there are so few people with JavaScript disabled" are just one side of the medal. Not relying on JS also could improve your site experience to non-graphical clients like search engine robots (how should they load AJAX content, when that is only accessible via JS?) or screen reader software. In fact there are many more good reasons not to rely on on JS.
At this time of age there are so few people with javascript disabled, that there is no signifcant benefit for creating a static version. Try to imagine who is your visitor and if he/she would even know how to disable it.
I suggest you to design a web application with JavaScript in mind and then add fallback functionality for user that do not have JavaScript.
Now a days everything runs on JS only. You should create some kind of services/API on server side and a separate project for UI, this is the trend being followed these days.
UI project can be based on any JS framework or it can even be a simple MVC/.net project. This approach can decouple stuff, and thereafter you can create 2 UI projects one for JS users and one for the users who do not have JS.
seems a bit of a work but, it will pay in the long run.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I recently included Handlebars.js in a rails project, and a coworker balked at the notion. What are the realistic technical considerations when including an extra javascript library into a rails project?
Does the addition of an extraneous library significantly slow down the site delivery and user experience? Is this an example of engineering drama?
Has this been measured?
Adding additional libraries slows down the site delivery by several hundred milliseconds. It also requires some client time to parse and run its onload()-type functionality. From a human standpoint, it requires a bit of time to get used to using the new library. Depending on the level of complexity, usefulness, and time-saving of the library, this may be an acceptable tradeoff.
Handlebars is a great tool for templating, but you really need everybody on your team to be on board to use it. It's not very nice to simply introduce a brand new way of doing things without really discussing things. Handlebars is a big enough change to warrant at least a discussion, if not a vote.
If you were just wanting to put it there to see if it would work in the future, or maybe just convert over a page or two, then you should do that in a separate branch and do a quick prototype and demo for the team.
Depending on whether there is a valid business case and legitimate usefulness, you and the team can decide whether to convert your application to use it.